This adds "https://" as a valid website prefix in the ImageMap URL edit
field, in addition to http://.
It also restores the prefix change that 2.10 had when you switched URL
types. It also fixes code formatting in affected areas.
...no image is active.
There are Arbitrary Rotation options under both the Image and Layer
menus. All of those rotation options are disabled without an image open.
To keep consistency, this disables those menu options as well.
The Tools menu Rotation option is left as-is.
Adds a new PSDSupport struct to keep track of what unsupported features
a PSD contains.
It is then used to conditionally display a compatibility notice
via a GUI.
GIMP expects CSS palettes to end with a ";" when importing. However,
GIMP exports CSS lines without ";". This means GIMP can't reopen its
own exported CSS palettes.
The ";" was removed from the regex since CSS2 does not require
the last line to end with a ";". However, CSS3 and above
require ending all lines with a ";", so it is added to the
export script.
When porting IFS-Compose and GFig to GAction, I originally created
all icons as GtkToolButtons. However, the toggle buttons no longer
appeared "pressed in" when selected.
This is fixed by creating those as GtkToggleToolButtons instead.
A lingering UIManager object was removed from IFS Compose as well.
See #9136.
(cherry picked from commit 0cd38a87e1)
Note: when cherry-picking, the tags were fixed as the main dev branch does not
need the underlined tags for localization anymore.
The initial issue was that 3 leaks were detected when running the "DumpCompiler"
during g-ir-scanner phase. The failing command was apparently about running some
temp binary, which looks like would be called the DumpCompiler in g-ir-scanner
code:
> libgimp/tmp-introspectn8jg64to/Gimp-3.0 --introspect-dump=libgimp/tmp-introspectn8jg64to/functions.txt,libgimp/tmp-introspectn8jg64to/dump.xml
My first fix attempt was to try and play with build/link FLAGS so that this temp
binary is built without sanitizer. But the problem when I did this was that
libgimp itself is sanitized, so we are mixing a sanitized lib with a
non-sanitized binary:
> ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
So it looks like I could still solve this with tweaking LD_PRELOAD, cf. this
sanitizer FAQ: https://github.com/google/sanitizers/wiki/AddressSanitizer#faq
Nevertheless it proved complex to do it right while not interfering with other
parts of the build and I found out that I risk encountering more issues down the
road with GIR + sanitizer:
https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/375
So I've decided that I didn't want to waste too much time on this and simply
disable introspection when sanitizing, as I guess what we care the most to
diagnose when sanitizing is core code anyway.
Especially as our code does not actually leak as far as we can see. It looks
like librsvg might not play well with -fsanitize=address (possibly having real
leaks or false positives).
gimp_display_shell_render() writes to a GeglBuffer backed by allocated memory
(shell->profile_data). Unfortunately while converting prevision in
gimp_image_convert_precision(), we change the "precision" property (hence the
source format) first, hence end up trying to write data in a too small buffer.
This crash was hard to find as it was not showing up on my machine (though it
did produce rendering artifacts!), unless I built both GIMP and babl with
`b_sanitize=address`.
Note that an alternate fix was to make sure that the profile_data buffer is big
enough (by calling gimp_display_shell_profile_update() before rendering), but
anyway the image is in an inconsistent state while conversion is in progress:
whereas the `src_format` is the new one, the `src_profile` is still the old one
(and cannot be changed before we finish converting).
Moreover the render happen regularly on progress signals, once after each
converted drawable. So each of these rendering step happens in an inconsistent
state, with the wrong profile set, some of the drawables converted and others
not yet.
We could still render properly if each drawable's buffer used space-aware format
(thus allowing different drawables to use different profiles/spaces), but it
feels over-engineering the problem. It might be much better to ignore rendering
steps while converting the image precision. Moreover it would obviously make a
faster conversion.
See discussions in #9136 for this crash, which didn't have dedicated report
AFAIK.
(cherry picked from commit de25be9210)
Note: on the `master` branch, even with sanitized code, I don't get the crash.
Yet this change seems relevant enough that I'm adding it.
Balázs Meskó