I am adding this note as a consequence of this discussion on Pixls.us:
https://discuss.pixls.us/t/gimp-patterns-and-the-gpl-license/35969
Now we were always very clear that GIMP can be used for whatever use you want
and that the project doesn't intent to claim any rights on produced artworks.
There is even a FAQ entry about the fact we don't intend to put any restriction
on people's work (though this FAQ entry was added in 2015 AFAICS):
https://www.gimp.org/docs/userfaq.html#can-i-use-gimp-commercially
Yet it's better to be as clear as possible. Therefore this new note in the
LICENSE file will serve to make sure any new data is properly licensed CC0 by
the simple fact of contributing it.
This is similar to the fact that people contributing patches to core GIMP (app/)
are implicitly licensing it as GPL. Now people contributing data to data/ are
implicitly licensing it as CC0 as per our LICENSE file.
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).