This ports the main dialogue to use GimpProcedureConfig.
It also adds the GUI-only options to the procedure itself, so that you
can call them via scripts.
Additionally, the layer warning was fixed and
mnemonics were added to the
property titles.
@Wormnest notified me of issues with CMYK profiles overwriting existing
ones, and potentially access a dereferenced profile.
This patch adds an additional condition check, and clears out the
profile in addition to dereferencing it.
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).