Resolves #11897.
The crop tool currently doesn't constrain
to the top-left of the layer when the
"Allow growing" option is turned off and
"Selected layers only" is turned on.
Instead, it always constrains to 0, 0.
When we converted to multi-layer select,
we added a loop to check the boundaries
of all selected layers. In this loop, we use
separate variables to get the offset and
then get the min of it and the current
min_x and min_y. However, those values
are initialized to 0, so they will always be
smaller if the layer is inside the canvas.
To fix this, before the loop we check if
there are any selected layers. If so, we
get the offset of the first layer and set
min_x and min_y to that value rather than
0, 0.
...bump map settings.
Currently, the Lighting Effect's bump map options uses
the RGB values of transparent pixels as part of its map.
As the Bump map filter does not do this, this patch tries
to make it consistent by using associated alpha for the
bump map Babl format to fix this.
Resolves #11892.
The new_unit_dialog () now initializes the default GimpUnit
to NULL instead of GIMP_UNIT_PIXEL. So we need to update the
check to prevent it from running when the user cancels the dialogue.
First of all: sorry to all translators who started working on these new
strings!
We use CamelCase for our titles, and in particular "Plug-In" is
capitalized with 'I'.
Furthermore, let's use understandable titles like "Plug-In Example in C"
and not just "In C", because while the short title works OK in the menu,
it makes for very broken action names in non-contextual parts of the
software, such as the action search.
Note that we in fact have a concept of short label for actions since
commit 89772351c9. I added support for it to GEGL actions (cf. commit
6dc5f6792e), and to a few core actions (e.g. commit ea1205f094).
Unfortunately I don't think I added an API yet for short label in
plug-ins. Maybe I'll add it soon. But for now, if we have to have a
single label, it should be long, so that it works in every situation.
P.S.: not sure if it's useful to keep documentation strings just
repeating the title, but for now, let's leave them.
Resolves #11890.
The Selection Editor's "vectors" group was not renamed
to "paths" during the GimpPath API update. This caused it
to be registered to a non-existent group, thus crashing.
Since it will be distributed in a release.
Only translate the menu item and help.
Not translate dialog labels, they will only be read by plugin authors.
The old menu label was confusing to users.
Remove translatable strings having joke "goat" so translators not confused.
Move the goat plugins to the menu.
The items under the menu should all be example plugins.
The menu is in a release.
Test plugins should not be in this menu.
Test plugins should not ship in a stable release.
!!! Note that 2.10 does not ship with example plugins.
If we don't want 3.0 to ship stable build with example plugins,
then the meson.build for goat-exercises needs to change
and the menu removed entirely in menus/image-menu.ui.in.in.
Adds a checkbox in the Filter tool so that
users can choose to apply a filter
destructively or non-destructively.
Currently only layers can have NDE effects
so it's not shown for masks and other
drawables.
Additionally, filters are moved to the top
or the bottom of the filter stack depending on
the setting (as destructive filters are applied
directly to the layer while NDE filters are
put on the top by default).
This fixes 2 issues:
1. Since gimp_edit_cut() uses gimp_edit_copy(), it had the same error
message when no selected drawables were within the selection.
2. When there was a previously existing clipboard image, gimp_edit_cut()
could return it as though the cut succeded, even when it did not.
While other parts of the commits were fine, this specific change was
clearly me going too fast. This is the format for a printf() call.
Fixes:
> app/widgets/gimpimagepropview.c:461:50: warning: format ‘%a’ expects argument of type ‘double’, but argument 4 has type ‘const gchar *’ {aka ‘const char *’} [-Wformat=]
I had the case on my machine where `lua` was version 5.4.4 and the
lua-lgi test succeeded fine, but then the demo plug-in would fail to run
with the error message from #11876.
Let's parse the output of `lua -v` to detect the version ourselves and
therefore be able to output proper error messages for packagers not to
assume that the Lua interpreter they are using will work fine.
Ported from: 3772514155
Just to note, ALL the previous "Sync with..." commits were tested in flathub
and gnome-nightly flatpaks, and this actual one (and future ones will be) too.
As discussed in #11876, the interp files work fine on Linux (and other
platforms) too, and this allows to properly redirect to the working
interpreter found at configure time, without touching the scripts'
shebang.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/11876
For 3.0 we will support only Lua 5.1, since we need to figure out how
much of the Lua 5.1 API is compatible with newer versions (Lua minor
versions aren't like Python minor versions, there is API breakage so
plug-ins would be completely unreliable, this commit prevent this).
Also, change some files to not force luajit since it isn't mandatory.
As in f9df9805, adds SVG versions of GFig
custom icons and conditionally uses them if
have_vector_icons is enabled. If not, we
fall back to the original PNG icons.
Also resolves #10012 by adding white
outlines around the thin dark lines to
make them more visible in dark mode.
This is the pendant commit to the one I'm going to commit on the beta
branch for RC1. There in fact was a way to always use the
$XDG_CONFIG_HOME folder, unconditionally (and prevent the weird
inconsistencies of having config folder in .var for some flatpak
installations and in XDG folder for others).
See: https://github.com/flathub/org.gimp.GIMP/pull/287
Apparentely `makeappx` tool deletes empty folders and MSIX runs with
system paths read-only. So calling g_file_make_directory_with_parents()
is just not enough.
Therefore when opening font folders recursively for font parsing, let's
just ignore the specific error of non-existing folders.
This patch adds support for loading Sketchbook
TIFF layers.
Alias/Autodesk Sketchbook used metadata tags
to store information about layers. This is a
separate implementation compared to Adobe,
stored in TIFFTAG_ALIAS_LAYER_METADATA.
The first directory contains the image metadata
and the layers are stored in SubIFDs, using the
same metadata tag for layer-specific properties
such as opacity and visibility.
This is a followup of commit f2d47ee53a.
I realized that the window's size was too big for the case when there is
an image as well because the scale factor of 1.0 was hardcoded. We now
use the scale factor from the display the shell is displayed on.
Unlike the other bindings (Lua, JS, Vala) where we only have a demo
plug-in, we actually have a bunch of interesting and useful Python
plug-ins.
Furthermore, we are running several Python scripts through GIMP during
our build (to generate a few images), so pygobject becomes a build
dependency anyway, even if it may not be a run dependency with
-Dpython=disabled.
This all becomes a bit confusing and in fact handling this case (of not
installing Python plug-ins) seems like an annoyance while we lose good
core plug-ins. So let's just make Python plug-ins mandatory. It's not
like Python is very controversial these days, and AFAWK, it is available
on every platform out there.
I was testing with a 2560×1440 display, yet with ×2 scale factor, which
is kinda equivalent with 1280×720 for scaled dimensions code.
And so anyway the default size request for an empty canvas was far too
big (bigger than the work area in fact).
I'm now using small default. As for the 3:1 ratio comment, not sure
about it, since shell_width is in fact changed to -1, so it feels very
specific to someone's setup. But anyway… I left the comment.
As Lloyd Konneker noted, the calc.sflare_list was not being
accessed at the right location when the Edit Dialog preview of
the gradient was updated. The API page for g_list_free_full ()
recommends using g_steal_pointer () to ensure the head element
is not left dangling. This aligns with other usage in the GIMP codebase
and seems to stop the crash. Additional safety checks were
also added.
The GIMP_VIEW_SIZE_ENORMOUS enum setting was missing from
the Preview Size menu. This patch adds it in so that users have a
preview size option between Extra Large and Enormous.
In earlier development, we accidentally
allowed users to save gegl:nop filters.
Since they are valid operations, they were
not triggering our unsupported operations
delete code. This patch adds a second
check to see if the operation is a nop, and
deletes it as well.
This patch also adds a check to make sure
a filter is in the filter stack before reordering
it. This was revealed by the nop bug, so
it makes sense to patch both at once.
Improve the previous commit with a bit more subtlety:
* Try to get the proper monitor (if the the widget's window is already
realized).
* While we try not to display too small an image (quarter of work area),
we also try not to display it too big (third of the work area).
* After the image has been loaded and displayed, the dialog will likely
reallocate to its finale size. When this happens, we should check if
it's not higher than work area. Only then should we try to make the
first page scrollable. Not only this, but we also queue the window for
resize (otherwise it's too late, the window is already too big).
This later point avoid having ugly scrollbars when unneeded (i.e. when
the dialog is perfectly fitting within the work area).
This patch makes the first page of the
Welcome Dialog scrollable vertically.
This should help reduce the screen height
for users with smaller screen sizes.
Rather than trying to implement full i18n plural support, we just remove
this failed attempt from the past. The fact is that to get proper
support, we'd basically need to reimplement a Gettext-like plural
definition syntax within our API, then ask people to write down this
plural definition for their language, then to write every plural form…
all this for custom units which only them will ever see!
Moreover code investigation shows that the singular form was simply
never used, and the plural form was always used (whatever the actual
unit value displayed).
As for the "identifier", this was a text which was never shown anywhere
(except in the unit editor) and for all built-in units, as well as
default unitrc units, it was equivalent to the English plural value.
So we now just have a unique name which is the "long label" to be used
everywhere in the GUI, and abbreviation will be basically the "short
label". That's it. No useless (or worse, not actually usable because it
was not generic internationalization) values anymore!
This makes the bundling script an "extension" of the building script, similar
to what Cmake-based projects does on Windows. By the way, this is inline with
the recent changes which clarified that bundling is just a finalization of the
building process when a bundle is aimed. See: d09a2a6f, 2dc6f411 and 9d86492b
I encountered this one when closing GIMP. Issue #9591 seems to be the
same crash, though when just closing the Colors dockable. I fail to
reproduce willingly now, though it looks like the problem could happen
in some cases when the stored GimpContext is freed before
GimpColorHistory is freed.
Let's increment the reference to make sure the referenced object stays
alive as long the history is alive.
Commit 81a68ae758 added usage of hb_blob_create_from_file_or_fail().
Since Debian bookworm has harfbuzz 6.0.0, this is not a big deal, but
the minimum requirement should still be bumped in our build scripts.
Normally we should avoid touching the Gettext files, but changing a
message context massively broke many strings in all languages. So I am
just reassigning the correct context (not touching any translations), by
running:
> sed 's/msgctxt "vectors-action"/msgctxt "paths-action"/g' -i po/*
Though these are not as user-facing as other strings, the action names
still are somewhat user-facing. Let's rename them consistently with the
GUI and the API.
This commit also handles user config migration so that custom shortcuts
are not lost.
Inspired by Mark Sweeney's work.
This patch allows the icons in the tree
view in Preferences Dialog to scale based
on user icon scale preferences.
Rather than add a GimpGuiConfig to
GimpPrefsBox, we make a call to style_updated ()
from the Preferences Dialog to signal a
change.
Alias fonts don't have a generated name, their alias name is used
instead. But the serialization code assumed that all fonts had a
generated name of the format "gimpfont%d" and this was causing a crash.
check for font validity (whether it is usable by pango), using
harfbuzz instead of relying on file extentions.
We do this in the first place because pango when given a font it can't
support will look for the closest matching supported font, but we
iterate through all fonts, so that would create redundancy.
Compare the font file gotten from the PangoFont object
related to the PangoFontDescription rather than just comparing
font names. This Helps because when pango is given an unsupported
font (Type1 or Bitmap fonts) it choses the closest matching ttf/otf
font, but reports the name of the unsupported font.
Per Jehan, we should remove gimppickbutton-default.[ch] and
move the functions into gimppickbutton.c. Then we can
make the GimpPickButtonPrivate API actually private without
any additional public functions.
This widget is used primarily in plug-ins like GFig and IFS Compose
which have toolbar buttons. This patch explicitly defines the style to
prevent system theme leaks and too dark colors on Middle Gray theme.
The "selected-layers-changed" signal was emitted while there were still
selected channels (which is an inconsistent state). And since
gimp_image_get_selected_drawables() returns selected channels first when
the image has any, vectors_actions_update() was using the previously
selected channel's lock information for deciding which actions to set
sensitive.
Temporarily reverting as the private struct
is shared between various OS versions of
the object and needs to be accessible.
A different approach will be needed to resolve,
and until then, I'd like the Debian pipeline to
work properly.
Move all public attributes of GimpThumbnail
from the header to a private struct in
GimpThumbnail.c. Also replace direct
access of these attributes in app/core and
app/widget with get/set calls.
Legacy plug-ins like Checkerboard (legacy) under Render Patterns lost
their Help button, although using F1 was still working.
Due to changes in how procedures are called, `gimp_dialog_constructed`
was called before the help-id was set.
The simplest way to fix this, is to call
`G_OBJECT_CLASS (parent_class)->constructed (object);`
at a later time in `gimp_procedure_dialog_constructed` after we have
set the help-id there.
Fixes:
> libgimpbase/gimpchoice.c:366: Warning: Gimp: gimp_choice_set_sensitive: invalid return annotation
Introspection step is now fully without any warning! \o/
I thought that such annotations would work and be useful to tell GIR that
a type is nothing more than a NULL-terminated array of a specific type.
But apparently GIR doesn't like these annotations and complain. So let's
just clean these out.
Fixes:
> ./../../../../../../dev/src/gimp/libgimpbase/gimpparamspecs.h:254: Warning: Gimp: unexpected annotation: array
> ../../../../../../../dev/src/gimp/libgimpbase/gimpparamspecs.h:254: Warning: Gimp: unexpected annotation: element-type
Right now, it only tests a few API, such as creating an image, then a
text layer, then inserting it in the image.
This is a test to avoid regression bug after having fixed #9923 in a
previous commit.
Without this, build-time GIMP cannot find the etc/ files unless GIMP is
installed. This becomes even more annoying now as I want to run tests
(for GimpUnit) depending on etc/unitrc contents.
This will also ensure that tests run properly in environments where the
etc/unitrc may have been modified.
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!
Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.
As an aside, this also fixes #10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.
Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.
Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
Adds SVG versions of ImageMap custom
icons and conditionally uses them if
have_vector_icons is enabled. If not, we
fall back to the original PNG icons.
Since ImageMap mixes custom and
stock icons, this keeps the icon size
consistent across the UI.
Per Denis Rangelov, tooltips for the
coordinates and area displays as well
as the shortcut menu were added.
Also, removes a reference to IMAP_ARROW
which no longer applies since that icon
was removed in favor of using the stock
cursor icon.
Despite the good intentions, 4f965557 makes Debian contributors who
follows gimp-web-devel instructions to download more deps than needed
and makes unclear what are the crossroad deps. Let's fix it.
This makes crossroad and msys2 scripts clone without the "_" prefix, which
will improve quality of life of most contributors that just clone them.
Just for consistency, also remove the "_" prefix from other pices of code.
The original script required a specific WinSDK version. Now, it autodetects.
This is useful if we need to move to another runner and welcome locally too.
Also, downloading the arm64 artifact was mandatory to get a x64 msix, which
is silly. Now, packagers are free to package to either arm64 or x64 alone.
This is useful locally but could be useful on CI too when some arch fail(?).
Resolves #11313.
We reference JPEG and TIFF images when
we send them from their loading plug-ins
to the PSD plug-in for PSD formatted
metadata. We should remove this extra
reference when returning the image back
to its original loading plug-in.
Inspired by Mark Sweeney's work.
This patch allows the active image, brush,
pattern, and gradient areas in the toolbox
to scale based on user icon scale
preferences.
Note that if the pattern itself is smaller
than the icon size, it currently won't scale
larger. This is a separate issue in the
renderer.
web-page.c was left as additional font
sizes besides the GUI choices could be set
via a PDB call. The export plug-ins int
combos will be updated in a separate
merge request.
Additionally, the region choice in screenshot.c
was hidden on Windows since it does not
yet implement that option.
This patch converts the image map
plug-in to use a floating point ratio rather
than an integer zoom factor. This allows
us to zoom out past the 1:1 ratio.
Additionally, it fixes the statusbar display
so that it shows 2:1 for zoomed in rather
than 1:2.
It's perfectly reasonable that someone can misunderstand the scripts info in
gimp-web-devel and try to run them not from git root but from their dirs. So,
let's add that possibility as a fallback (a pretty natural one by the way).
Also, change the error message to direct contributors to gimp-web-devel.
Inspired by Mark Sweeney's work.
This patch allows the four buttons on the
sides of the canvas (Zoom, Quick Mask,
Image Menu, and Navigation Image)
to resize based on the user's icon size
preferences.
layer_mask points to the original mask created by xcf_load_layer_mask. We copy
this pointer into channel, and xcf_load_channel_props can overwrite this
pointer and free the original mask. If this happens, layer_mask points to
the now-freed original mask, and should not be used.
Therefore we need to change later parts of xcf_load_layer_mask to use channel
instead of layer_mask. Additionally, we add a block and move layer_mask into
this block to guarantee that layer_mask cannot be used after it has
potentially been freed.
Adjustments by Jacob Boerema:
Follow GIMP's code style regarding variables, comment style and
position of braces
See also ASAN output below:
==5247==ERROR: AddressSanitizer: heap-use-after-free on address 0x615000010fd0 at pc 0x7f4e2dbbf31b bp 0x7ffca8a95cd0 sp 0x7ffca8a95cc8
READ of size 8 at 0x615000010fd0 thread T0
#0 0x7f4e2dbbf31a in g_type_check_instance_cast /home/ahunt/git/glib/_build/../gobject/gtype.c:4117:26
#1 0xb200fe in xcf_load_layer_mask /home/ahunt/git/gimp/app/xcf/xcf-load.c:2305:52
#2 0xb18eea in xcf_load_layer /home/ahunt/git/gimp/app/xcf/xcf-load.c:2133:20
#3 0xb13d91 in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:499:15
#4 0xb11deb in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#5 0x619dfd in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:50:17
#6 0x51d364 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#7 0x506fe2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#8 0x50d350 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9
#9 0x5373a2 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#10 0x7f4e2c84c349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#11 0x4e0779 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
0x615000010fd0 is located 336 bytes inside of 504-byte region [0x615000010e80,0x615000011078)
freed by thread T0 here:
#0 0x5e8562 in free /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:127:3
#1 0x7f4e2d76ce08 in g_free /home/ahunt/git/glib/_build/../glib/gmem.c:199:3
#2 0x7f4e2d797a6b in g_slice_free1 /home/ahunt/git/glib/_build/../glib/gslice.c:1183:7
#3 0x7f4e2dbb7b04 in g_type_free_instance /home/ahunt/git/glib/_build/../gobject/gtype.c:2008:5
#4 0x7f4e2db8fe3a in g_object_unref /home/ahunt/git/glib/_build/../gobject/gobject.c:3604:11
#5 0xb22fff in xcf_load_channel_props /home/ahunt/git/gimp/app/xcf/xcf-load.c:1738:13
#6 0xb20037 in xcf_load_layer_mask /home/ahunt/git/gimp/app/xcf/xcf-load.c:2292:9
#7 0xb18eea in xcf_load_layer /home/ahunt/git/gimp/app/xcf/xcf-load.c:2133:20
#8 0xb13d91 in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:499:15
#9 0xb11deb in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#10 0x619dfd in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:50:17
#11 0x51d364 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#12 0x506fe2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#13 0x50d350 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9
#14 0x5373a2 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#15 0x7f4e2c84c349 in __libc_start_main (/lib64/libc.so.6+0x24349)
previously allocated by thread T0 here:
#0 0x5e87cd in malloc /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
#1 0x7f4e2d76ccf2 in g_malloc /home/ahunt/git/glib/_build/../glib/gmem.c:106:13
#2 0x7f4e2d7972e0 in g_slice_alloc /home/ahunt/git/glib/_build/../glib/gslice.c:1072:11
#3 0x7f4e2d7978ae in g_slice_alloc0 /home/ahunt/git/glib/_build/../glib/gslice.c:1098:18
#4 0x7f4e2dbb6e0a in g_type_create_instance /home/ahunt/git/glib/_build/../gobject/gtype.c:1911:17
#5 0x7f4e2db9215e in g_object_new_internal /home/ahunt/git/glib/_build/../gobject/gobject.c:1945:24
#6 0x7f4e2db91d1f in g_object_new_valist /home/ahunt/git/glib/_build/../gobject/gobject.c:2288:16
#7 0x7f4e2db90e8b in g_object_new /home/ahunt/git/glib/_build/../gobject/gobject.c:1788:12
#8 0xdb69e0 in gimp_item_new /home/ahunt/git/gimp/app/core/gimpitem.c:723:10
#9 0xce11c8 in gimp_drawable_new /home/ahunt/git/gimp/app/core/gimpdrawable.c:1067:14
#10 0xddf5d8 in gimp_layer_mask_new /home/ahunt/git/gimp/app/core/gimplayermask.c:254:5
#11 0xb1ffc5 in xcf_load_layer_mask /home/ahunt/git/gimp/app/xcf/xcf-load.c:2279:31
#12 0xb18eea in xcf_load_layer /home/ahunt/git/gimp/app/xcf/xcf-load.c:2133:20
#13 0xb13d91 in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:499:15
#14 0xb11deb in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#15 0x619dfd in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:50:17
#16 0x51d364 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#17 0x506fe2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#18 0x50d350 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9
#19 0x5373a2 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#20 0x7f4e2c84c349 in __libc_start_main (/lib64/libc.so.6+0x24349)
SUMMARY: AddressSanitizer: heap-use-after-free /home/ahunt/git/glib/_build/../gobject/gtype.c:4117:26 in g_type_check_instance_cast
Shadow bytes around the buggy address:
0x0c2a7fffa1a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa1b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa1c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2a7fffa1d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa1e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c2a7fffa1f0: fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd
0x0c2a7fffa200: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
0x0c2a7fffa210: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2a7fffa220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2a7fffa230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2a7fffa240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==5247==ABORTING
./crash-0507799c3e4291570e060f53332b58b8a96f95e5
Currently if your image history includes an
image with a long name, the Welcome
Dialog will stretch out to match its width.
If the color profile name is long, then the
color scales will also stretch out due to
the profile label.
This patch adds ellipses to the Welcome
Dialog and a scrollwindow to the
ColorScales to prevent this.
Ported from ca5688bf6d
Just to note, we are already not using Assembly code
in 10bit and 12bit libraries. So, no feature dropped.
---
Also, little fixes to some dev docs regarding Clang.
Unlike GIMP, Photoshop does not support indexed images with
multiple layers. We have been silently merging layers down when
exporting to PSD, but this may be confusing to users.
This patch adds a label that notifies the user if they export an
indexed image with more than one layer.
...based on icon size preferences.
Inspired by Mark Sweeney's work.
Since the icon size is based on a formula,
the CSS value determines the maximum
size rather than being used directly.
Needs backport to 2.10
gimp_dock_windows_constructed creates a GimpDockColumns, a child widget,
and keeps a private reference to it at dock_window->p->dock_columns.
Then it connects the signal dock_columns.doc_removed to two callbacks:
gimp_dock_window_dock_removed() and gimp_dock_window_update_title().
gimp_dock_window_dock_removed() callback is called first and can
destroy the GimpDockWindow widget and its child widget GimpDockColumns.
Then gimp_dock_window_update_title is called
and tries to call dock_window->p->dock_columns.get_docks()
but it is already destroyed.
The fix is to nullify the internal pointer to dock_columns when destroyed,
and encapsulate access to dock_columns.get_docks so that it
returns a valid but empty list when dock_columns has already been destroyed.
Alternatively, you might be able to fix it by rearranging the order
of connections to dock-removed signal, but then the title would be wrong.
Another alternative might be to rethink the whole destruction sequence.
The ARTIFACTS_SUFFIX is being dropped on building scripts because:
1) This will make possible to further simplify Installer scripts in other commit
2) There is no script that uses multi-arch _build/_install at same time on CI
However, there are two use cases: to build Debian and flatpak; and, on Win,
to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche.
I suppose that people who build on Debian (or other dev-oriented distro)
willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime)
+ two gimp prefixes (out of sandbox and sandbox) due to huge storage use.
Why someone would want to build with emulation on Win ARM64 I don't know.
Anyway, people that know how to do this stuff probably can change the .sh.
3) When building locally, the contributor doesn't need to know the arch at all.
Indeed, without this suffix, the scripts are inline with gimp-web-devel and
prevent some first-sight confusion when reading them that I've seen on IRC.
4) These arch suffixes can be understood as '_install-*' being distributable
which is not true. So, without this suffix we could make more clear
what is a package (when GitLab fix the glob bug in 'expose_as' someday).
---
Despite .gitlab-ci.yml not being a script, it needed to be touched too
because cross scripts depends on Debian jobs due to gimp-data MR.
If a given layer's properties contain multiple PROP_ACTIVE_LAYER entries, we
could add multiple entries for the same layer in info->selected_layers.
However, xcf_load_layer_props and xcf_load_layer both contain logic that
overwrites the layer pointer - they do take care of updating
info->selected_layers and and info->floating_sel (both of which could contain
or point to the current layer). Crucially, they both assume that
info->selected_layers can only contain this layer once - hence they only
remove it from the list once. This logic also frees the old layer because it
thinks that it's no longer in use.
But if we've added the original layer to selected_layers multiple times,
and then use the logic that overwrites layer, selected_layers will still
contain an invalid pointer to the now-freed original layer. Any later
code that tries to read info->selected_layers will hit a user-after-free.
Therefore we need to check if the current layer is already in the
selected_layers list, and avoid adding it again if it's already there.
(It also seems illogical to say that a layer is selected twice, but I'm
focusing on the code-correctness aspect in my analysis.)
Adjustment by Jacob Boerema: the correct way to test that a value does
not exist in a list is to check for the value being negative. Also add
a message to warn users.
ASAN output:
==21241==ERROR: AddressSanitizer: heap-use-after-free on address 0x615000012150 at pc 0x000000d54dbf bp 0x7ffcf813bb60 sp 0x7ffcf813bb58
READ of size 8 at 0x615000012150 thread T0
#0 0xd54dbe in gimp_image_set_selected_layers /home/ahunt/git/gimp/app/core/gimpimage.c:4743:7
#1 0xb146c6 in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:690:7
#2 0xb1199b in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#3 0x619cad in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:35:17
#4 0x51d2e4 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#5 0x506f62 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#6 0x50d2d0 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9
#7 0x537322 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#8 0x7f064a594349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#9 0x4e06f9 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
0x615000012150 is located 336 bytes inside of 504-byte region [0x615000012000,0x6150000121f8)
freed by thread T0 here:
#0 0x5e84e2 in free /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:127:3
#1 0x7f064b3f81c8 in g_free (/usr/lib64/libglib-2.0.so.0+0x581c8)
#2 0x7f064b41133f in g_slice_free1 (/usr/lib64/libglib-2.0.so.0+0x7133f)
#3 0x7f064b7015c0 in g_type_free_instance /usr/src/debug/glib2-2.62.6-lp152.2.3.1.x86_64/build/../gobject/gtype.c:1946
#4 0xb187d8 in xcf_load_layer /home/ahunt/git/gimp/app/xcf/xcf-load.c:2146:3
#5 0xb13997 in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:504:15
#6 0xb1199b in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#7 0x619cad in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:35:17
#8 0x51d2e4 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#9 0x506f62 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#10 0x50d2d0 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9
#11 0x537322 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#12 0x7f064a594349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#13 0x4e06f9 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
previously allocated by thread T0 here:
#0 0x5e874d in malloc /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
#1 0x7f064b3f80c8 in g_malloc (/usr/lib64/libglib-2.0.so.0+0x580c8)
#2 0x7f064b410da5 in g_slice_alloc (/usr/lib64/libglib-2.0.so.0+0x70da5)
#3 0x7f064b411258 in g_slice_alloc0 (/usr/lib64/libglib-2.0.so.0+0x71258)
#4 0x7f064b7011d5 in g_type_create_instance /usr/src/debug/glib2-2.62.6-lp152.2.3.1.x86_64/build/../gobject/gtype.c:1849
#5 0x7f064b6e164f in g_object_new_internal /usr/src/debug/glib2-2.62.6-lp152.2.3.1.x86_64/build/../gobject/gobject.c:1827
#6 0x7f064b6e354d in g_object_new_valist /usr/src/debug/glib2-2.62.6-lp152.2.3.1.x86_64/build/../gobject/gobject.c:2152
#7 0x7f064b6e38c8 in g_object_new /usr/src/debug/glib2-2.62.6-lp152.2.3.1.x86_64/build/../gobject/gobject.c:1670
#8 0xdb5b90 in gimp_item_new /home/ahunt/git/gimp/app/core/gimpitem.c:723:10
#9 0xce0358 in gimp_drawable_new /home/ahunt/git/gimp/app/core/gimpdrawable.c:1067:14
#10 0xddd8db in gimp_layer_new /home/ahunt/git/gimp/app/core/gimplayer-new.c:65:11
#11 0xb182a6 in xcf_load_layer /home/ahunt/git/gimp/app/xcf/xcf-load.c:2027:11
#12 0xb13997 in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:504:15
#13 0xb1199b in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#14 0x619cad in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:35:17
#15 0x51d2e4 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#16 0x506f62 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#17 0x50d2d0 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9
#18 0x537322 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#19 0x7f064a594349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#20 0x4e06f9 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
SUMMARY: AddressSanitizer: heap-use-after-free /home/ahunt/git/gimp/app/core/gimpimage.c:4743:7 in gimp_image_set_selected_layers
Shadow bytes around the buggy address:
0x0c2a7fffa3d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa3e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa3f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2a7fffa400: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa410: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c2a7fffa420: fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd
0x0c2a7fffa430: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
0x0c2a7fffa440: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2a7fffa450: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa460: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa470: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==21241==ABORTING
( crash-f37f84bd7072e65348ca0e2c920d1e08165356fd )
Inspired by Mark Sweeney's work.
GimpToolPresetEditor has an icon next to its title which does
not react to icon size changes.
GimpToolPresetEditor's parent_instance, GimpEditor, already
has a "button-icon-size" CSS style which can be accessed in
its children. This patch adds signals to listen for icon size
changes and update the icon size accordingly.
Resolves #9105
The XCF compression setting is initially
set to FALSE. It was only updated from the
Save Dialog, so if the user exports then
compression is reset if they save the XCF
again.
This patch adds a condition on export
where we get the image's compression
setting, instead of always defaulting to
FALSE. This allows you to save and export
the same image without having to
re-enable the compression setting each
time.
A follow-up to the previous commits, that address the tga issues from
issue #11822.
On Windows, when using the error console for messages, a huge amount
of error messages, that can be generated with special fuzzed images,
like crash-f65fd5404bff32c1d9d10ee049d9c98d02bbbdc2.tga from
the above mentioned issue, can cause GIMP to crash.
Although this is most likely caused in the error console or its
dependencies, we should not let it cause problems here until that is
fixed. There is also no real need to generate a huge amount of similar
repeated error messages, so let's limit it to 10 per read line of input.
We are trying to copy all bytes in the current row, which is the width times
the number of bytes per pixel (stored in info->bytes), not width times bits
per pixel.
Copying too much data allows certain inputs to induce a heap-buffer-buffer
overflow read, and probably also a write, see ASAN output below:
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61d000008088 at pc 0x00000052be17 bp 0x7ffd8bbe8e20 sp 0x7ffd8bbe85e8
READ of size 16448 at 0x61d000008088 thread T0
#0 0x52be16 in __asan_memcpy /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3
#1 0x5641ca in read_line /home/ahunt/git/gimp/plug-ins/common/file-tga.c:982:7
#2 0x560218 in ReadImage /home/ahunt/git/gimp/plug-ins/common/file-tga.c:1147:15
#3 0x55f526 in load_image /home/ahunt/git/gimp/plug-ins/common/file-tga.c:646:11
#4 0x56519b in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/plug-ins/common/file-tga_fuzzer.c:69:17
#5 0x461624 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#6 0x460b2a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:505:3
#7 0x462ec4 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:814:7
#8 0x4630d9 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:845:3
#9 0x451686 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:906:6
#10 0x47b662 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#11 0x7fdbd277c349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#12 0x424a39 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
0x61d000008088 is located 0 bytes to the right of 2056-byte region [0x61d000007880,0x61d000008088)
allocated by thread T0 here:
#0 0x52ca8d in malloc /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
#1 0x7fdbd37fccf2 in g_malloc /home/ahunt/git/glib/_build/../glib/gmem.c:106:13
#2 0x56009b in ReadImage /home/ahunt/git/gimp/plug-ins/common/file-tga.c:1134:10
#3 0x55f526 in load_image /home/ahunt/git/gimp/plug-ins/common/file-tga.c:646:11
#4 0x56519b in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/plug-ins/common/file-tga_fuzzer.c:69:17
#5 0x461624 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#6 0x460b2a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:505:3
#7 0x462ec4 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:814:7
#8 0x4630d9 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:845:3
#9 0x451686 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:906:6
#10 0x47b662 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#11 0x7fdbd277c349 in __libc_start_main (/lib64/libc.so.6+0x24349)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 in __asan_memcpy
Shadow bytes around the buggy address:
0x0c3a7fff8fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c3a7fff8fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c3a7fff8fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c3a7fff8ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c3a7fff9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c3a7fff9010: 00[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3a7fff9020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3a7fff9030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3a7fff9040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3a7fff9050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3a7fff9060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==26560==ABORTING
crash-4b13aca1db7bb795a815431b86cc20284f3aa6da
A malformed colourmapped tga file could specify color IDs that are not
contained in the colourmap. Therefore we add some bounds checking to
ensure that we only use entries that actually exist.
We could completely give up on such files, but it's just as easy to fall
back to the first colour in the map in this case. However we can only
fall back to the first colour in the map IF the colourmap contains
at least one entry. Therefore we add an up-front check to verify that
colourmapped images actually do contain at least one entry.
Without this bounds-checking, it's possible to induce a heap-buffer-overflow
read in apply-colormap(), see ASAN output below:
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61900002257c at pc 0x000000564f99 bp 0x7ffe65fdb040 sp 0x7ffe65fdb038
READ of size 1 at 0x61900002257c thread T0
#0 0x564f98 in apply_colormap /home/ahunt/git/gimp/plug-ins/common/file-tga.c:901:23
#1 0x56411a in read_line /home/ahunt/git/gimp/plug-ins/common/file-tga.c:975:7
#2 0x560648 in ReadImage /home/ahunt/git/gimp/plug-ins/common/file-tga.c:1202:15
#3 0x55f4ee in load_image /home/ahunt/git/gimp/plug-ins/common/file-tga.c:647:11
#4 0x5653ab in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/plug-ins/common/file-tga_fuzzer.c:69:17
#5 0x461624 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#6 0x460b2a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:505:3
#7 0x462847 in fuzzer::Fuzzer::MutateAndTestOne() /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:745:19
#8 0x4633d5 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:883:5
#9 0x451686 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:906:6
#10 0x47b662 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#11 0x7fe76a5dc349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#12 0x424a39 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
0x61900002257c is located 0 bytes to the right of 1020-byte region [0x619000022180,0x61900002257c)
allocated by thread T0 here:
#0 0x52ca8d in malloc /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
#1 0x7fe76b65ccf2 in g_malloc /home/ahunt/git/glib/_build/../glib/gmem.c:106:13
#2 0x55fdc6 in ReadImage /home/ahunt/git/gimp/plug-ins/common/file-tga.c:1049:26
#3 0x55f4ee in load_image /home/ahunt/git/gimp/plug-ins/common/file-tga.c:647:11
#4 0x5653ab in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/plug-ins/common/file-tga_fuzzer.c:69:17
#5 0x461624 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#6 0x460b2a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:505:3
#7 0x462847 in fuzzer::Fuzzer::MutateAndTestOne() /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:745:19
#8 0x4633d5 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:883:5
#9 0x451686 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:906:6
#10 0x47b662 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#11 0x7fe76a5dc349 in __libc_start_main (/lib64/libc.so.6+0x24349)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ahunt/git/gimp/plug-ins/common/file-tga.c:901:23 in apply_colormap
Shadow bytes around the buggy address:
0x0c327fffc450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fffc460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fffc470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fffc480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fffc490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c327fffc4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[04]
0x0c327fffc4b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fffc4c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fffc4d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fffc4e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fffc4f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==16309==ABORTING
( crash-f70628d4df7a65babc8e57d890425771a1d67e06 )
If the colourmap contains more than 256 items AND has alpha, it should always
be promoted to RGBA. Therefore we move the "if (info->alphaBits)" check into
the first if clause, to avoid accidentally demoting to RGB in this scenario.
Other parts of the tga parser assume that the destination array is RGBA
when alphaBits is not zero. For example, upsample() will always write 4 bytes
per pixel when alpha is set - (even if we only allocated 3 because we thought
we should use RGB). Erronously allocating only 3 bytes makes it easy to induce
a heap-buffer-overflow write, see ASAN output below. (apply_colormap makes the
same assumption and would probably do the same thing, but upsample is the
first location that we'd hit this issue.)
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61700002ae00 at pc 0x000000563d97 bp 0x7ffde8677890 sp 0x7ffde8677888
WRITE of size 1 at 0x61700002ae00 thread T0
#0 0x563d96 in upsample /home/ahunt/git/gimp/plug-ins/common/file-tga.c:830:15
#1 0x560b59 in ReadImage /home/ahunt/git/gimp/plug-ins/common/file-tga.c
#2 0x55f4ee in load_image /home/ahunt/git/gimp/plug-ins/common/file-tga.c:647:11
#3 0x5652ab in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/plug-ins/common/file-tga_fuzzer.c:69:17
#4 0x461624 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#5 0x460b2a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:505:3
#6 0x462847 in fuzzer::Fuzzer::MutateAndTestOne() /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:745:19
#7 0x4633d5 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:883:5
#8 0x451686 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:906:6
#9 0x47b662 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#10 0x7fd894a94349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#11 0x424a39 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
0x61700002ae00 is located 0 bytes to the right of 768-byte region [0x61700002ab00,0x61700002ae00)
allocated by thread T0 here:
#0 0x52ca8d in malloc /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
#1 0x7fd895b14cf2 in g_malloc /home/ahunt/git/glib/_build/../glib/gmem.c:106:13
#2 0x55fce9 in ReadImage /home/ahunt/git/gimp/plug-ins/common/file-tga.c:1039:26
#3 0x55f4ee in load_image /home/ahunt/git/gimp/plug-ins/common/file-tga.c:647:11
#4 0x5652ab in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/plug-ins/common/file-tga_fuzzer.c:69:17
#5 0x461624 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#6 0x460b2a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:505:3
#7 0x462847 in fuzzer::Fuzzer::MutateAndTestOne() /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:745:19
#8 0x4633d5 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:883:5
#9 0x451686 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:906:6
#10 0x47b662 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#11 0x7fd894a94349 in __libc_start_main (/lib64/libc.so.6+0x24349)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ahunt/git/gimp/plug-ins/common/file-tga.c:830:15 in upsample
Shadow bytes around the buggy address:
0x0c2e7fffd570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2e7fffd580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2e7fffd590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2e7fffd5a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2e7fffd5b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c2e7fffd5c0:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2e7fffd5d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2e7fffd5e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2e7fffd5f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2e7fffd600: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2e7fffd610: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==12179==ABORTING
( crash-f65fd5404bff32c1d9d10ee049d9c98d02bbbdc2 )
We allow passing NULL gvalue for an empty GimpObjectArray, for convenience.
For example to plugin sel2path which doesn't use drawables.
But crossing the wire, create an empty GimpObjectArray
having an arbitrary type for elements.
Note that the widgets are still made
with GTK directly. The primary goal of this
initial port is to remove the last usage of
gimp_export_dialog_new (). Future work
will be needed as currently we can not
automatically generate widgets from
array parameters.
The visibility lock icon and help ID was accidentally
left off the PathsTreeView set-up.
The Path Attributes also used the wrong icon to indicate
the paths were locked (compared to the one shown in the
Path Attributes dialogue).
Revise the tests that can't default the args.
Actual args default to the min value formal declared in the PDB.
The declared min value must correspond with declaration in GEGL.
As of fcdddad2, the requirement for layers
to be attached before NDE filters can be
applied has been removed on app/core.
This patch removes the restriction from
the PDB call for filters as well.
* file-sunras, sparkle, and fractal-explorer
were converted to use GimpChoice with
the RadioFrame setting
* Unnecessary store variables were
removed from hot and file-psp
The description promises that we return
NULL if the image is not in indexed mode,
but we didn't actually verify that it was
before continuing with the colormap
code. This patch adds that verification step.
...in non-interactive cases.
gimp_export_image () handles various
tasks like rasterizing NDE filters. It only
runs in interactive cases however, so if the
users calls gimp-file-save the filters are
not exported.
Since Jehan removed the hidden dialogue
in 0dc9ff7c, we can now safely call
gimp_export_image () in all cases to make
image export more consistent. This step is
also preparation for setting up the new
API with GimpExportOptions.
GimpPlugin improperly destroys proxies after each run of a temporary procedure.
A temporary procedure may pass reference to proxy to main procedure.
Proxies should live as long as the main procedure of a plugin,
or for an extension plugin, until only the extension main procedure
is on the procedure stack. More discussion in the issue.
Extract method gimp_plug_in_proc_run.
Call it from two new methods: main_proc_run and temp_proc_run,
which do more e.g. cleanup.
Extract methods for cleanup, main_proc_cleanup and temp_proc_cleanup
Add method is_proc_stack_empty
...from GimpChoice.
0b2d8fed let us display GimpChoice
options as IntRadioFrames. Therefore, we
can convert a number of plug-in parameters
that were being built manually to use
GimpChoice instead. This decreases the
amount of GUI code and makes the
non-interactive inputs more descriptive.
Some languages like Chinese use separate
words for Levels when referring to a color
scale versus a unit of measure. Currently
we group all of them together.
This patch distinguishes between Levels
as Color Scales versus "measurements" for
translation purposes.
vector(s) => path(s)
layer-group => group-layer
Add a few tests.
(script-fu-use-v3) in more tests, code becomes more terse.
Added some aliases in script-fu-compat.c for renamed procedures, for compatibility third party.
Though I am not fond of these macros for our core code (it makes the
code more cumbersome especially for using private data in derivable
types), this definitely makes sense for public API, since it would allow
easier modifications with less chances of messing API/ABI stability.
...to path.
Changes the names of
gimp_vectors_* () API to
gimp_path[s]_* (). Renames related files
to [path] instead of [vectors], along with
relevant enums and functions.
This commit renames the GimpVectors
object to GimpPath in both app/core and
in libgimp. It also renames the files
to gimppath.[ch] and updates the relevant
build and translation files.
There are still outstanding gimp_vectors_* ()
functions on the app side that need to be renamed
in a subsequent commit.
...to paths.
Similar to d0bdbdfd, but covering the
app/core versions of the API instead of
libgimp. Changes the names of
gimp_image_*_vectors () API to
gimp_image_*_path[s] ().
Also renames some related functions such
as gimp_image_pick_path (). The next step
will be to rename the gimp_vectors_* () to
gimp_path_* ().
Inspired by Mark Sweeney's work.
GimpDockbook's dockable tabs update whenever the icon size is
changed. However, the Configure this tab button icon does not,
so it always remains at 12px. This patch adds code to resize it to 75%
of the current tab icon's size, which mirrors the default relationship
of 12px to 16px. This allows the icon to grow when the icon size is
set to Large or Huge.
The numbering is now inline with actual the order of jobs on CI
to make easier to understand what the numbers represent.
To understand why bundling is number 2 see: d09a2a6f and 2dc6f411
The storing of Windows scripts was changed to make easier to
call them, to better convey that they work outside CI and
to be consistent with other build/ subdirectories.
Refactor: extract method gimp_widget_free_native_handle.
This reduces duplication of code and encapsulates Wayland specific code.
Call the new function in more places.
This is expected to fix #11613 but it is hard to be sure
since the exact sequence of events in 11613 was never determined
and only reproduceable in some flatpak builds.
Calling the new function in more places also should eliminate leaks.
But I did not test there was a leak prior to this fix.
In GimpColorSelector setter, don't change the model if perceptually same.
More than just don't emit changed, don't change the model value.
Also, fix leak by freeing old color.
...to paths
Follow-up to d0bdbdfd. Changes all
gimp_vectors_* () PDB to gimp_path_* ()
and renames relevant PDB files from
vectors to path.
The next step will be to rename
GimpVectors in libgimp to GimpPath,
removing the last (public) trace of it.
...to paths
The first step in converting GimpVectors
to GimpPath. The PDB API for any
gimp_image_*_vectors () is now
gimp_image_*_paths ().
This commit only covers libgimp, and
the app/core versions will be renamed in
a following commit.
- Dependencies not present in GNOME runtime are now built in deps stage
This makes easier to follow the progress of the overall pipeline and
to know how much time was spent on each stage
(like crossbuilds, the artifact size is brutal but only lasts 2 hours)
- babl and GEGL build now have output in GitLab runner, unlike others deps
This makes clearer to spot if something goes wrong in these crucial deps
- GIMP is still built in its stage but now alone, like Debian and Windows
This makes possible to retrigger only this job when runner errors occours,
without needing to start monolithically the deps+gimp build from scratch
Also:
- babl, GEGL and GIMP now have meson-log.txt artifact like other builds
- dist job now have all commands self-contained on its script (needs to
be merged to be tested according to my tests)
Functions creating a new GeglBuffer should trigger a warning if the
result if unused, because this is potentially a big memory leak.
Similarly objects created by functions creating new layers should be
handled (usually by adding the layer to the image with
gimp_image_insert_layer()), because they also come with a buffer and
possibly quite some important memory leak.
If the type is not registered, g_type_from_name() is not able to find
the GType from the type name.
Fixes:
> gimp_gp_param_to_value: type name GimpGroupLayer is not registered
Also add a bit more type handling code.
Resolves #11772
While ba79fd00 fixed the number of
arguments in the resource arguments,
setting them to False prevented the GUI
from opening if the gradient wasn't set.
This patch switches the value to True to
fix the problem.
Resolves #10855
Replaces the uchar arguments in
plug_in_exchange () with floats to better
match gegl:color-exchange's arguments.
Since this was the last plug-in that used
uchar, we also remove the datatype from
PDB.
Also:
- renaming gimp_layer_group_new() to gimp_group_layer_new() in order to keep the
same name as in core code (i.e. GimpGroupLayer, not GimpLayerGroup).
- renaming gimp_image_merge_layer_group() to gimp_group_layer_merge()
- new functions: gimp_procedure_add_group_layer_argument(),
gimp_procedure_add_group_layer_aux_argument() and
gimp_procedure_add_group_layer_return_value().
This can be tested, e.g. in Python with these calls:
```py
i = Gimp.get_images()[0]
g = Gimp.GroupLayer.new(i, "hello")
i.insert_layer(g, None, 1)
g2 = Gimp.GroupLayer.new(i, "world")
i.insert_layer(g2, g, 1)
g.merge()
```
This was work started long ago, stored in an old stash which I finally
finish now! :-)
See: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1670#note_2152565
This makes the NIGHTLY flatpak use the local GIMP source. This reduces the
internet usage and makes possible to generate .flatpak from every branch out
there, which turns the flatpak finally really useful to code development.
Of course, this makes impossible to run 'flatpak-builder NIGHTLY_manifest.json'
without cloning or downloading GIMP code, but this is not a regression since:
1) the NIGHTLY manifest is in-source to begin with, so same thing as our other
building methods (except macOS), which runs over the code they are stored
2) the chances of someone downloading partial source code (the NIGHTLY manifest
alone) so being unable to build are low since this file isn't too easy to find
3) even if someone do this and don't like, we are not violating flatpak building
pratices since this option exists to be used (and will be in NIGHTLY only)
In most bindings, they would just result in the same signature as the
_get_ variants (which people have been used to, since the GIMP 2
series). Also I was told that apparently in some bindings where this
would make a different signature, the (skip) annotation could be ignored
anyway.
The original reason to skip these was because the new _list_ API were
introspected basically to a similar function signature, except with a
useless return value, at least in pygobject binding where the list size
was also returned.
Though it seems that in fact, only the docstring was wrong. The real
signature was apparently already the same.
See: https://gitlab.gnome.org/GNOME/pygobject/-/issues/352
Therefore since the _get_ naming is more consistent compared to other
existing function, let's re-integrate the _get_ functions for array of
items or images.
This basically reverts commit 15ec254148.
Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value().
We now have specific public functions for every supported type and it's
in fact much better to use them. The generic functions gave the feeling
that we could use any GParamSpec as procedure argument, whereas we in
fact depend on what the PDB support, and only these subtypes.
Despite we not building gimp nightly on aarch64 we need to sync with beta.
So, this updates to LLVM/Clang 18, which fixes 'gexiv2' and 'poppler'
problems with deps on that arch. 'json-c' and 'luajit' were adjusted too
with the use of proper build options to fix errors.
These were created because of some limitation/bug in pygobject, which is
now much better worked around by having specific functions for every
argument type supported by the PDB.
...when dockable is closed.
Resolves #11748
gimp_color_editor_display_changed () was still connected to
the user context when the Color dockable was closed. This
resulted in either a critical or crash if a new Color dockable
was opened or if the GIMP was closed. This patch should
cause the signal to be disconnected automatically when
the editor is destroyed.
Inspired by Mark Sweeney's work.
GimpColorNotebook has existing code to
update the color selector tab icon sizes
via CSS. However, it was not set up to be
notified of icon size changes from the GUI.
Since GimpColorNotebook is in libgimpwidgets,
we call its style_updated () function from
the style_updated () functions of the two
widgets its created in - GimpColorEditor
and GimpColorDialog.
It seems unnecessary – at least on my system, files with underscores in
their names are shown with two underscores in the recent files list.
This patch fixes that.
The Preference settings for themes and icon themes
are not directly connected to the property due to
the possibility of custom themes. Instead, we create
GtkListBoxes and load all the theme values. As a result,
when the preferences are reset, the row selection is not
updated.
This patch adds signals to the config object that update
the listbox selections when the Reset button is clicked.
The handler IDs are stored in the dialogue so that we
can remove them when the dialogue is closed.
Resolves #11742
gimp_procedure_dialog_get_file_chooser () does not
work with GtkFileChooserAction.SAVE enums yet.
This was incorrectly left in by f5b7f734.
This patch removes the command to fix a crash.
As decided in #10922, 32-bit will be tolerated in 3.0 series because of TWAIN.
So, let's package only the bare minimum files to the 32-bit TWAIN plug-in work.
This reduces the final installation size by approximately 215MB.
It's a common pratice to tell the user what version is being installed
even if this is somewhat obvious (the user opened the installer, he
should know it). Many installers do this and Win MSIX installer too.
However, there is no sign in our Installer about what version is
being installed (the reused splash/intro image doesn't count because
it isn't always different at each micro or revision, and text is small).
---
To accomplish that feature, the Inno langs needed to be patched since
Inno actually forbidden to use that feature when we have a Welcome page.
https://groups.google.com/g/innosetup/c/w0sebw5YAeg
But 'UninstallAppFullTitle' from the following langs couldn't be patched:
- Japanese
- Lativian
I only updated the mask strings to plural in core-enums.c, overlooking
that it is generated from core-enums.h.
So, update the same strings there after "desc".
commands that work on multiple layers:
Raise Layer -> Raise Layers
Layer to Top -> Layers to Top
Lower Layer -> Lower Layers
Layer to Bottom -> Layers to Bottom
Also update the hint strings.
There are two approaches regarding the icon for Windows installers .exe:
1) same icon as the app: this give more identity, but creates confusion if
you saved the installer in the same dir of the installed app shortcut.
This approach is also confusing in the task bar (e.g.: running GIMP
stable while installing GIMP unstable);
2) generic icon (e.g. a box, a cd) provided by the tool: more generic if
you downloaded two installers generated by the same tool (ours is Inno)
I choose a middle ground and created a icon with: the app icon and an
"installer" symbol (a package box), which conveys the best of two words.
This also fixes the Inno inborn bug of the unninstaller with install icon.
Resolves #11018.
Currently, babl formats are saved as strings when
passed as params. However, indexed palettes do not
use a "standard" encoding string but are created from
palettes (with a custom format). This results in an
error when we attempt to recreate the babl format from
the custom string encoding, as it doesn't exist at that
point.
This patch mitigates the problem by converting the indexed
color to RGB/A 8-bit when used in params. In the future when
indexed mode supports different color spaces and higher
precision, we will need to remove the hard coding. For now,
it solves the immediate problem.
After running almost all the py plug-ins, I noticed that few py modules and
pkgs are used to justify the need of a slightly faster build time with .pyc.
In the actual bloated status (with all .pyc), lib/python* is about 260 MB big.
With the bare minimum .pyc after the tests above, python*/ is less than 90.
So, let's purge the .pyc at bundling time (I'm not reinventing the wheel,
Krita do this too), which reduces the .zip bundles (so the Inno and MSIX
installs) in 170MB, the Installer .exe in 45MB and MSIX download in 60MB.
---
Let's also disable any .pyc generation, since GIMP installed with Inno in the
system-wide (aka admin) mode or installed with MSIX both doesn't handle well:
py plug-ins work but have CLI errors, unlike Inno user-mode and .zip bundle.
Actually, the Language dialog is always displayed, which is not too good since:
1) This is inconsistent: the install mode dialog (to choose user or system)
appears before using the system lang automatically. Even if Inno fix this:
2) This is tiring: depending on the context, the user can see up to 5 dialogs:
SmartScreen (1) > Install mode (2) > installer lang (3) > dev warning (4)
> SetupMutex (5): https://groups.google.com/g/innosetup/c/bkRtnHz2ygg
3) This is redundant: even if only 2 and 3 are displayed, why 2? Inno will
auto select the sys lang, which the user understand to search GIMP for PC;
4) This is confusing: even the lang dialog message being clear, some users
genuinely conclude that the selection will carry over to GIMP install like
the old Adobe CS installer (#5515). !1628 makes more clear that not, but
reducing confusion even more is a welcome plus considering points above.
So, let's use 'ShowLanguageDialog=auto'. That option ensures that the dialog
will NOT appear if the sys lang have a translation present in the installer,
which matches what every program does and even installers like Inkscape one.
If the lang isn't included in the installer, the dialog WILL appear so the
user can choose one which he is more fluent, being is a nice middle ground.
In the main menu and layers dialog context menu it is called
`Text to Path`, let's use that same name in the text tool actions
instead of `Path from Text`.
This solves an old bug that makes Inno report GIMP as being almost 1.8GB,
which is not true (it's 1.3GB at most). That was probably caused by the
overuse of components intersections (e.g.: gs + gimp, py + deps), which
Inno does not handle well (sometimes it not even displayed the cmp size).
TWAIN component is still reporting a wrong size since it's a totally
different beast, it will be fixed later.
Not all layer mask menu commands and help texts were updated to reflect
that they work on multiple masks.
Updates
- Apply Layer Mask -> Apply Layer Masks
- Delete Layer Mask -> Delete Layer Masks
- Their text hints and the one for Disable Layer Masks
Updates the undo strings, even though these don't seem to be used
anymore? Looks like undo always picks the menu command now.
It had actually been made unnecessary by 1c81c426.
This will allow for the full removal of GimpCMYK from
the codebase as part of the color space invasion.
Adds code to copy any NDE filters when
importing an .xcf file as layers in an
existing project.
This also requires removing the check
for the layer being attached to an image,
which historically made sense because
filter effects were immediately merged
down. Now that filters can exist separately
the check is no longer required.
GimpSourceTools like Clone and Heal use GimpPaintTool's
code for determining if they can work on a pixel-locked
layer. This means that they can not set a locked layer as a
source even though that would not affect the locked layer's
pixels.
This patch adds an additional condition to GimpPaintTool, to
allow operations if the tool is a GimpSourceTool AND only
Ctrl is held down. This allows the layer to be set as a source
while preventing it from being drawn on.
Note that this isn't enough for F1 to work, but that is a separate
issue.
I think that for now one help-id for all the layer effects is enough,
until we get a more final UI.
lua-lgi now works with Lua 5.3 on Windows:
https://github.com/msys2/MINGW-packages/issues/21171
According to my tests, after installing lua53-lgi MSYS2 package,
lua5.3.exe tries to run the goat exercise (fails since the goat
uses different lua API). Anyway, lua5.1 isn't required per se.
Following c6634d66 and 09d6402a
These files are too small and aren't reused so no point keeping them modular.
Also, with them inside .iss we reduce the clutter in the installer/ folder.
Despite that folder mysteriously not being mandatory on Linux
(the contents are different), on Windows (in PCs without MSYS2)
this is required by a warning. So, partially reverts c808d13b
The gimp.org main page was being used as the updates URL but the
downloads page is more direct, avoiding confusion with news or with
the stable big red button (remember: we also have dev installers).
The OpenEXR plugin was specifically set
to throw an exception if a chroma image
(Y/BY/RY) image was loaded.
This patch removes the exception and loads
the luminance channel only as a grayscale image,
which is how Krita currently handles it.
Future work is needed to properly convert the
chroma channels to import as a RGB(A) image.
Temporarily drops 'cfitsio' which started weeks ago to change its hash.
In my tests, after "fixing" the hash, sometimes it alternates to another,
which breaks the build again. This is too hard to maintain and unsafe(?).
Resolves #11702
In 2.10, the x/y label background on the Curves tool used
GtkStateType enums to get the widget's background color.
These enums were depreciated in GTK3, and during the
port the gdk_cairo_set_source_rgba() command was left
out. This resulted in the current line color being used instead,
making it hard to read the label in some instances.
This patch restores the Cairo color update command, using
the gridline color as an equivalent to the background color
from 2.10.
Resolves #7588
After the port to GTK3, the Filter dialogue's width started
to be affected the length of the image name. If the name
was very long, the filter dialogue would expand to fit it.
This patch encloses the image title label in a GtkScrolledWindow
with polices of EXTERNAL width and NEVER height. This ensures
there will not be a scrollbar, and the label will not influence the
width of the dialogue. A tooltip was added in case the user wants
to hover to see the full name.
Following e93e0f49
This defaults 'Segoe UI' for Installer texts and for license's body. This
font is still used as the default in Windows 11 and even in online docs.
We are also bumping to 9 pt as outlined in the final Win32 guidelines:
https://learn.microsoft.com/en-us/windows/win32/uxguide/vis-fonts
I've done microscopic pixel checks and confirmed that this produces a Win32
compliant design, which renders kerning and spacing equal as 'Win + R' and
UWP Notepad (please note that some "legacier" Win32 apps renders different)
---
Also, change from Lucida Console to 'Consolas' (default console font since
at least Win8). Today it is Cascadia Mono but not included with Win 10.
Resolves #11690
While exporting, the image is duplicated, in turn,
filters are also duplicated. This patch fixes the
duplication by also copying the parent
GimpFilter's properties.
Restores the build log artifact which was lost partly due to my fault.
The log is very useful in the rare cases of breaking the build system.
So, following our experience, let's save it for, at minimum:
- Native Linux
- Native Linux flatpak: will be adressed later in another commit
- Cross Win
- Native Win (aarch64)
If we were in the first days of our CI (so script bugs are common),
the scripts "debug mode" (bash -x) would be crucial, but we are not.
To be fair, running scripts in "debug mode" is pretty harmful today:
1) the produced logs consume our quota more and more (e.x.: adding a
bit more complicated .sh function can double the output size); and
2) the long white logs tends to be specially hard to read by the way.
This makes the output more complete but at the same time less
polluted regarding the bundling scripts (base, deps and sym).
---
Also, packaging scripts (inno and msix) were touched as consequence
of experiments about drop bundling, for saving space (~20MB), of:
- etc/gtk (MSYS2 don't build immodules)
- share/ghostscript (macOS .dmg don't package it)
- share/libthai (macOS .dmg don't package it)
- share/locale (???, decided to kept only gtk and iso-codes to test)
- share/man (installer don't package it, maybe because Windows can't open)
- share/poppler (macOS .dmg don't package it)
- bin/bzip2.exe (???)
- bin/gdk-pixbuf-query-loaders.exe (loaders.cache already bundled)
- bin/gspawn*.exe. (???)
- share/gir-1.0 (installer don't package it)
- share/lua (???)
- share/vala (installer don't package it)
The "???" ones seems to not be used according to my local tests. If
they are, a bug will appear so we will be able to know, comment in
the script (for maximum clarity towards the future) then revert.
With the new API introduced int d1c4457f,
we next need to port all plug-ins using
the argument macros to functions.
This will allow us to remove the macros
as part of the 3.0 API clean-up.
In the process, make the Installer localization process less 'masochist'
(in other words: less manual). The custom '.xml' was the only way since
the iso-codes, Dammed Lies and Inno namings don't match.
Resolves #11687
Previously gimp_drawable_has_filters () was used to check
if a drawable had filters before deleting them. However,
this function actually only checks if there's an active filter -
if filters are attached but set to invisible, this returns false.
This mean that you could not delete filters if they were
invisible.
This patch switches to using gimp_container_have () instead
as it checks if the filter is in the drawable's filter stack.
* colorxhtml.py was converted to use
GimpProcedureDialog. A new aux
argument was added so that a widget
could be created in the GUI. The text
field and the file widgets were made
to be sensitive to the source-file bool to
better indicate to the user which one will
be used.
* palette-sort.py now uses babl instead of
colormath libraries to get CIE LAB and
CIE LCH(ab) values. This means all users
will be able to sort by those options even
if the colormath library isn't installed.
* histogram-export.py's out-format
widget was converted to a radio frame
as it is in 2.10.
Currently when you open the Procedure Browser, part of the
description text is off-screen.
This patch changes the values for the GtkPaned panels so that
the description is completely visible horizontally. It also makes
the vertical scrollbar conditional on the widget height rather
than always showing.
Resolves #11679
The loading code for ASE, ACB, and ACO palettes
set any errors with g_prefix_error (). However, the
error object is NULL at that point for those palettes.
Therefore, a NULL error object is returned to
palette_import_make_palette () which then tries to
access its attributes. This resulted in a crash.
This patch fixes the issue by using g_set_error () for
those three formats instead.
This patch ports the first-party Python plug-ins
to use the new argument API.
This restores the ability to add dropdown menus from
enums and Gimp.Choice parameters, and also allows
defaults to be set for custom datatypes like Gegl.Color.
In order for Python plug-ins to be able
to create custom parameters like
GeglColor and GimpChoice, we need to
create actual functions rather than
using macros. A subsequent commit
will update all plug-ins to use them.
Ports the animation code started in e13cc635
to an independent gimp_widget_animation_enabled()
function. This allows plug-in authors to
also conditionally turn off animations if
the user's system settings say to do so.
The function is applied to the About
Dialogue animation as well as two Easter
Egg animations:
* Wilber's eyes blinking after 23 minutes
on an empty canvas
* Wilber's eyes following the mouse after
a certain sequence of tools is clicked
Resolves #11656
Since e4b1f37e, Filter Tool widgets above the Blend
Mode frame do not expand vertically when the dialogue
is resized.
This especially impacts GeglGraph, as you can no longer
increase the text area to see more graph code.
This patch resolves the issue by adding a GtkExpander
to the GUI so that it allows the inner area to resize
vertically.
While setting a plug-in as transient usually worked, it was failing in
cases the plug-in's progress bar was not initialized (i.e. if
progress_init() was not called before setting the dialog transient).
This commit stores the calling display, core side too (libgimp side, the
plug-in already had the calling display ID information), and we use this
when a GimpProgress has not been created yet.
… native dimensions/ratio display by default.
Also adding gimp_vector_load_procedure_extract_dimensions() public
function allowing plug-ins to query the native size or ratio of a vector
file.
Previous gimp_procedure_run_config() was in fact only good for private usage
inside the various run() methods for the different GimpProcedure subtypes. The
problem with this implementation is that the returned config object is not
complete. For instance, for a GimpLoadProcedure, the "run-mode" and "file"
properties are not part of the config object so you cannot call a
GimpLoadProcedure with any of the gimp_procedure_run*() functions.
Note: we had some working usage, e.g. in file-openraster, but only because it
was running the load procedure as a GimpPDBProcedure whose returned config
object was indeed always complete!
As a consequence, I rename gimp_procedure_run_config() as an internal-only
function _gimp_procedure_create_run_config() and I create a new
gimp_procedure_run_config() which always return a full config with all
arguments.
It was a bad idea to bind width/height with pixel density. These are separate
things. You may want to set specific pixel dimensions while keeping a given
resolution.
Moreover I am now properly storing aspect ratio in the widget, otherwise with
integer computation, we are just losing too much precision and the ratio is in
fact changing constantly as you change dimensions.
The bogus 0×0 default values for width×height properties are only because we
don't know the real native size of the image. Once we have computed it, we can
change the param spec defaults, so that hitting "Reset to Factory Defaults" sets
width, height and resolution to the actual file's default values (if resolution
is not a metadata in the format, which is apparently the case for all vector
formats we currently support, then 300.0 stays the default resolution).
I'm moving the logic of choosing a correct default for width/height by adding an
"extract dimensions" callback in the procedure. The logic is that every vector
format out there should likely have metadata either for pixel dimensions or
physical dimensions, or at the very least for no-unit dimensions (ratio only).
Vector load procedures will have to implement only the extraction of such data
in a callback called by GIMP but not how to act upon them, so that we have a
common logic for all vector images.
I am implementing this callback first in the SVG plug-in, moving all the code
to extract dimensions (and improving it) in this callback.
Also I am deleting "file-svg-load-thumb" procedure. I could simply reimplement
it using the same code, but it looks to me like this is very useless for vector
formats to have a specific thumbnail procedure (unless it were to use very
specific metadata for faster result). This is vector data, just ask it directly
at the proper bounding box size.
This new function allows to set a title with mnemonic.
But also it properly sets the frame label as the mnemonic widget for the
radio buttons, otherwise the mnemonic is mostly bogus and doesn't
actually give focus to the editable widgets (i.e. the radio group).
This includes a new function gimp_prop_choice_radio_frame_new() which
creates GimpIntRadioFrame from GimpChoice properties.
GimpChoice GimpProcedure arguments are still creating a combo box by
default, but it is now possible to override this default behavior to get
a radio frame by calling first:
```C
gimp_procedure_dialog_get_widget (dialog, "arg-name", GIMP_TYPE_INT_RADIO_FRAME);
```
Currently, we can not use Gimp.Choice as a parameter type for
Python plug-ins. This means that we're using a string instead for
the "output-format" parameter, which creates a textbox in the GUI.
This patch manually creates a GimpStringComboBox in the GUI and
syncs it with the "output-format" string parameter. Once Gimp.Choice
can be used in Python, we should be able to swap this out without
impacting plug-in developers (since it would also take in a string)
e13cc635 uses gtk-enable-animation to determine whether
the more dynamic motion animation should be used for the
About Dialog credits. However, gtk-enable-animation does
not take into account the MacOS preferences.
This patch adds a check for this value using NSWorkspace's
accessibilityDisplayShouldReduceMotion boolean. Since the
value is TRUE on MacOS if the user wants animations turned
off, the boolean is inverted.
This reverts commit 085d8a02b5.
For some reason, Windows doesn't allow us to use that feature
(confirmed this after using the version from the Store itself,
not the .msixbundle)
… "Reduce Animation" is checked.
This is an alternate version for commit e13cc63525.
Instead of proposing a simpler animation (fade-in/out instead of wave
animation), let's just completely get rid of the whole thing when
someone enabled an accessibility option saying that long animated
contents are basically disturbing to them, which is how I understand
additional issue #11647.
In fact, reading Mozilla docs about such option:
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion#user_preferences
… they even mention vestibular motion disorders, which seem pretty
serious and would make our About dialog quite uncomfortable.
I tried to experiment with just showing a part of the authors list, then
ending on a link text to the Credits tab after a few second, but it
didn't feel that interesting nor useful. Anyway the whole animated
widget is redundant with said Credits tab, and therefore more on the
"fancy" side of things than on the useful one. Hence let's make simple:
if someone configure their OS saying that animated elements are a
discomfort, let's just get rid of useless ones! Done!
Currently, the additional customization
options are laid out horizontally.
Depending on the translation, this might
cause the dialogue window to become
much wider.
This patch converts those options to
GtkSwitch and puts them in a column.
prefs_switch_add () was modified to also
return the GtkSwitch object, so we could
bind its active property for the icon
override property.
The installer is probably the most complex packaging format so one of the
biggest examples of packaging love over the years into it in our repo.
But the readability of installer scripts... leave a lot to be desired.
Now, the main script is organized following the order of installer pages
with some comments. This will make easier to future contributors work
(but this commit probably isn't perfect since it's a big change to read)
The About Dialog shows authors names using motion effects.
Since this is done with Cairo, it does not respect the
"gtk-enable-animations" setting or OSX's "Reduced Motion"
option.
This patch retrieves the "gtk-enable-animations" value.
If it is set to false, then the simple fade-in effect is used
for author names in place of the motion effects.
We have counter measures to avoid installing while gimp opened at 'prep time',
but until now none for the installer itself. Let's fix it with SetupMutex.
The final UX is just less worse (than today): the user needs first to select a
language, then only after this the dialog about two installer will be prompt.
Seems that Inno devs willn't fix: https://github.com/jrsoftware/issrc/pull/461
As noted by Wormnest, if the effect-image drawable is
smaller than the source image, the Van Gogh plug-in crashes.
This is because the source image's dimensions were being
used to traverse the effect-image drawable in rgb_to_hsl ().
This patch fixes the nested for loop to use the correct
width and height values as limits.
Unlike 2.10, the Van Gogh plug-in does not set the effect image
to the current layer by default. This means that if you don't set
it yourself, the plug-in does nothing.
This patch restores the 2.10 behavior by passing the drawable
to the plug-in dialogue and setting it by default with
gimp_drawable_chooser_set_drawable ().
Following 0199faac
We use arm64 runners for the installer job to avoid queues, but...
llvm-objcopy is well know to lack parity and one sympthom is the
'invalid SymbolTableIndex' warning when handling x86 debug symbols.
This commit just makes the installer display a (unchecked) checkbox, like Win
pkg manager (WinGet) so it's doesn't change the actual behavior. It also don't
break string freeze since the .isl string already exists and have translations.
The benefit to some users is having one less click to launch GIMP: [checkbox] >
[close]; instead of: [close] > [start menu icon] > [gimp in 'recommendations'].
The function expects *data to be 64bit wide which is incidentally true
on some architectures but not others. Make it explicit (and portable).
Signed-off-by: Nils Philippsen <nils@tiptoe.de>
Resolves #10609
Continuing from 1759174d, this patch
removes the on-canvas restrictions for
guides from the New Guide dialogue and
the Measure Tool's guide creation feature.
*In file-pnm, format_name is no longer
used due to changes in exporting
functions. This was creating a warning
about an unused variable.
*In 519f301c, an attempt to add a
short-key for MacOS Settings was left in.
It did not work because "comma" should
be spelled out rather than using ",". This
patch removes the accelerator.
Resolves #11617
When we ported Map Object to GimpProcedure API,
the wrong index was set for the Cylinder's bottom face.
As a result, the top and bottom faces both appeared on the top.
This patch fixes the array index to the right value.
Our gimp-win-x86 job fails with the following error:
../modules/gimpinputdevicestore-dx.c:207:28: error: passing argument 2
of 'GetModuleHandleExW' from incompatible pointer type
[-Wincompatible-pointer-types]
Fairly Recent the call to `GetModuleHandleEx` was changed to
`GetModuleHandleExW`. This new call expects a wide char pointer
instead of a char pointer.
So replace it with the wide variant (LPCWSTR). Since in this call
an address is actually expected, the actual contents don't need to
be a wide string.
Commit 015f4946 allowed guides to be
placed off-canvas in the GUI. However,
the restrictions were not removed from
the Script-fu implementation.
This patch fixes the Script-fu parameters
and conditional checks to match the
GUI implementation.
Some apps that write EXIF metadata, forgot to add the charset to
certain tags that require it. The main case is Exif.Photo.UserComment.
This caused us to show a warning about an invalid charset, in addition
to not showing it in our Metdata Viewer.
We fix this by reading the raw data for that tag when we encounter the
above error. The raw data is then validated as utf-8 and converted
to a string if valid.
We then resave this tag to our metadata to force it to have the
correct charset; that way we don't have to do any checking in other
places in our code.
Note: there are a few other tags that also use a charset. We may have
to check those too, eventually.
Completing d09a2a6f, since the dist job wasn't added to MR pipelines that time
Note: this doesn't change the actual behavior. The job will upload to nightly
repo only when triggered from schedule pipelines. I repeat, nothing changed.
What is new is that the .flatpak bundle now is an artifact from dist job, since:
- Despite the name, it isn't a real bundle, so no need to be only in gimp stage
- In dist, it reduces storage use because only the .flatpak file lasts 8 days,
not the .tar and other files from gimp job which lasts 2 days (5495483c)
Resolves #11211
The code that moves the temporary "editing" filter
when modifying an NDE filter was not being run
on custom GIMP filters like Curves. This meant that
editing Curves would always place the temporary
"editing" filter at the top of the filter stack, giving
an incorrect preview of what the changes would do.
This patch moves the reorder code from being in
gimp_filter_tool_create_filter () to being in
gimp_filter_tool_set_config (), which always runs
when any filter is created.
This change also fixes a separate issue where the
filter mask would not be copied over for Curves.
This style mimics the color scheme used by Win32 applications since Vista (and
still used in Win11). The all grey scheme ended in XP. Let's move on.
But we will keep the actual window size and without being able to resize since
these two Inno features (WizardSizePercent and WizardResizable) are broken.
(The progress bar was changed too to conform with the defaults and uninstaller)
Darktable 4.6 updated the version output format to conform
to standards. This broke the regex check that GIMP uses to
test if Darktable is installed. The developers of Darktable
have added a new --gimp flag for us to use for checking
support. This patch updates our check code to use this
API first, then fallback on the original regex code if a
version of Darktable before 4.6 is installed.
Now, the installer files match the meson config.h naming:
'gimp_version', 'gimp_app_version' and 'gimp_api_version'.
"devel" was replaced by meson 'gimp_unstable' too.
util_version was dropped since it lost its utility.
1) Right now, MS Partner Center doesn't tell us if the .pdb bunbled as .appxsym
are fine and we only have "Unknow" dumps in the Health page from MS Par. Cen.
My theory, according to my tests with 'SymChk', 'PDBCopy' and 'llvm-pdbutil',
is that this is happening because .pdb from clang or gcc are not "perfect", but
I really have no proof to afirm this, since Partner Center tell us nothing
about them, and we don't even know if the .appxsym were uploaded to begin with.
---
2) The compiler can't generate DWARF (.debug*) symbols when generating .pdb,
which breaks debugging in DrMingw and even lldb according to my tests.
(This is not a fault of the .pdb format but a circumstance: our debuggers
only support DWARF, which is the format already used by MSYS2 packages)
---
So, the .pdb will return probably only in the potential vcpkg transition.
Currently, messing with filters that are
being managed by tools (like Warp or
Gradient) causes crashes. For now, we'll
prevent removing NDE filters which are
tool-based, and revist after 3.0 is released.
Previous changes broken local building courtesy and probably DirectInput too.
Noticed that the universal variables can not work in some contexts, fixed.
Also, done some little cleanups.
In the Image Dockable, clicking on an image will update the layers and
navigation views. However, the actual canvas image will not update
unless you double-click the item.
This adds a select_item function so the canvas is updated on a single
click as well.
Resolves #11568
Currently, the Stroke/Fill Paths options on
the Path tool disregard the Pixel Locked
flag for layers. This patch resolves this as
follows:
* On the Paths tool, the Stroke/Fill button
does not pull up a dialogue if a single
layer is selected and it's pixel locked.
* If multiple layers are selected, only those
that are not pixel-locked have the Fill/Stroke
applied to them.
In both cases, a warning is also displayed.
There's no seemingly good reason for it not to be introspected, so let's
add it to the files. This also fixes an issue where the documentation
for it is not properly generated.
By defining `GIMP_DISABLE_DEPRECATED` when creating the GObject
Introspection file, we're actually not (or only partially) generating
some of the documentation of some files that are marked as deprecated.
One example that should now properly generate documentation is
`GimpFileEntry`.
Some minor code style issues remained
that I missed in 8adcc0cd.
After further reflection, I also converted
the code to be a private/internal function.
gimp_prop_check_button_new () should
cover the majority of GtkCheckButtons,
and the function is currently only used
to fix the size of those widgets. We could
revisit it as a public function in the
future if more use cases are found.
Resolves #10026
Selecting a checkbutton makes the label bold. This increases the
width of its label, and if it's the longest item in a box, this
causes minor "twitching" and resizing of the dialogue.
This patch calculates the size of the label when bold and then
requests the label width be set accordingly to resolve the issue.
Resolves #11550
The import code for X Logical Font Description fontnames
was not updated to use GimpFont instead of strings.
This caused crashes when we tried to set GimpFont properties
with gchars. This patch updates the code to create a new
GimpFont object from the font name string.
Additionally, it increases the read length by one, as we were losing
the last character of each field as it was split on the "-" character.
Resolves Issue #9955.
GimpToolDialog CSD buttons were being singled out to only
have padding of 2px. This was inconsistent with other dialogues
without this constraint. Since the larger padding style seems to
be preferred, we'll remove the constraint for GimpToolDialog
CSD buttons.
This make them easier to understand and to run local, as we do with native ones
(They can't be run local yet, further changes will try to acomplish this a bit)
Reintroduce pkg caching for crossroad. The possibility of using it is one
in thousands since we don't have distributed cache, but it's better than
rely totally on MSYS2 mirrors, which can be be extremely sick sometimes.
Resolves #11531
GtkListBox's CSS was previously defined, but GtkListBoxRow
did not inherit those values. This patch explicitly defines this
so we do not have system theme leaks.
For now, we can't keep certain GEGL ops
like Gradient as NDE filters, since they are
connected to tools. If the layer is copied
or saved as an .XCF while the tool is still
active, it attempts to save it and causes a
crash.
This patch adds a check to make sure the
copied filter has been commited and that
it's not a tool-based NDE filter before
being copied. It also adds some NULL
checks where gimp_drawable_filter_duplicate
is used to prevent NULL from being
added to the filter stack.
As noted by Anders Jonsson, the wrong parameter description
was removed when the API was updated. Other aspects of the
descriptions were also updated to account for the change.
* Since the appimage is for testing purposes, let's use system 'libc'
* Hardcode python path since the wildcard wasn't expanding misteriously
* Improve system theme recognition making way simpler
This may help to reduce the number of duplicate reports we get about some (temporarily) frequently reported issues, like the current crash
happening since GLib 2.79/2.80, or the crash happening with older GIMP versions on macOS Sonoma.
This won't be perfect because not everyone will use or read the template, or notice the url in it, or use the url to find and check the
reports, but I count on it getting more known than right now.
file plug-in testing.
The name and location of the xml results will be the same as for the
log file, but with the extension replaced by .xml.
Just some basic support is added which adds failed testcases when
a plug-in has a failure result, which should be the most common
case of failures.
Not all cases where we make errors in our test setup will generate
failed testcases yet, although they should show up in the number of
failures.
Disabled tests won't show up as skipped tests.
We also don't track time.
Port all plug-ins to retrieve the layers
directly from the image rather than
having them passed in. This resolves some
issues with introspection and sets the
foundation for future API work.
The move to Clang in 85ed2847 didn't take into account caching,
Now, this is fixed or, better saying, reintroduced(?): e545116b
Also, flatpak-builder output was confined to the .log file to make
possible checking the end of the CI output, which was being cut.
Formerly, closing a port cleared all the attribute bits.
Then the port was not disposed of properly (leaked memory)
when the port was garbage collected.
Now, closing a port only clears the direction bits.
The kind of port is still known for a closed port.
Add test script for file port methods of Scheme.
Resolves #10765
This allows us to retain any filters that a
layer group's children might have when
copied or exported. They were previously
lost when the group layer was duplicated.
Note that an OR condition was added to
GimpDrawableFilter creation, to allow
one to be created if the layer was
attached to a parent layer rather than the
image.
The wrapper, like in native artifact, exists just for avoid searching the exe.
But, if the user wanted, wasn't possible to execute gimp-*.exe directly since
the wrapper was needed to generate loaders.cache. Now, loaders.cache are built.
This improves the gimp.cmd wrapper wording a bit to not need the README
anymore. Our dev site was improved some time ago to clarify this:
the Windows builds aren't not incomplete if run correctly (under MSYS2)
Also, add cleanup commands to make the .typelib wizardy less invasive.
Resolves #11404
Since the GimpContainer selected function automatically updates which filter is the
"active" selected filter, we can remove the code that sets it to NULL after a filter
is deleted. This fixes a bug where the top effect was always deleted in subsequent
attempts rather than the highlighted one.
A now unnecessary gimp_drawable_remove_last_filter () function was also removed.
Without this, Partner Center refuses the .MSIX by not matching the
entry Identity and DisplayName (which isn't the same as the stable).
Also, rework the naming of the .msix's to be more Microsoft-ish
for gimp-tests.log
On Linux we may not have permission to create a log at our default
location, so we need to check for that.
First we should not init the log when our plug-in is asked for info.
Only create it when we actually run the import or export tests.
Second, try to catch the permission error and write a message either
in GIMP or in the terminal for non-interactive.
This commit is mostly a little cleanup:
- Reduce redundancy in Local compatibility layer regarding build commands,
which partily reverts !1171 regarding buggy "ninja && ninja install"
- Reduce redundancy of some variables (MSYS_PREFIX and GIMP_DISTRIB)
- Remove manual QOI install since MSYS2 granted a exception in the win32 drop
This commit also reverts 7cca69cd, a fix from the autotools era that isn't
actually needed according to my tests in CI.
Copied over from the original separate work in:
https://gitlab.gnome.org/Wormnest/gimp-file-plugin-tests
After that further improved and changed and added more file format
tests.
Added meson.build files to integrate it in our build, but we do not
install it for releases.
Should resolve #11392
In dfb26f37, the NDE filters in the copied image are
retrieved with gimp_image_get_layer_iter (). This works
fine for single layer images or when all the layers are copied
at once. However, if a subset is copied then the filters are always
copied starting from the top level of the image. This can result
in an incorrect filter being copied to the wrong layer.
To fix this, we get the filters from the provided drawables list
instead. This matches the number of layers in the copied
image exactly, since it was used to create the copied image.
This regression was added by c064148a and it's similar to fb7a9954. Now, that
we are using 'interruptible: false' in custom rules, this is probably fixed.
Also, organize a bit better some pipelines with official GitLab .yml wizardy.
I was hesitating to use "<<: *" since this creates a new layer of complexity,
but this was the better way and the trick have a distinct marking by the way.
This benefits script authors and testers of ScriptFu.
Now a call to (display "foo") in a plugin goes to the terminal where GIMP started.
Whether interactive or in batch mode.
Make TS errors go to an error port instead of the output port.
Tool plugins: Console, Eval, Server get error messages from the error port.
TextConsole not changed. Tools behave per new doc "ScriptFu Tools" at dev web site.
Driveby fix of SF Server: send whole message instead of byte by byte.
Driveby comments and more semantic checking of set-output-port in TS.
Add test plugin test-display.scm
In addition, this restores the palette options for HGT import
that were accidentally removed from 2.10. Mnemonics
were also added to parameters which were missing them
earlier.
This should hopefully fix:
> realpath: /Users/circleci/macports-gimp3-arm64/var/macports/build/_Users_circleci_project_ports_graphics_gimp3/gimp3/work/build/.GIMP3-build-config-: No such file or directory
Though it's harder to verify because of the "Intel macOS resource brownouts"
going on on CircleCI infra, and only x86_64 runners allowed me to SSH to them.
But I think that's the right fix seeing the error.
The preview widget is a bit stretched, though at least I fix the contents to be
distorted (instead, the preview is fine but we've got black-filled parts
around). I'm not focusing on it because anyway, I'm not sure either if the
preview is that important, or (if it is) whether we should not just integrate it
as part of GimpVectorLoadProcedureDialog, i.e. for every vector images.
For our two "development" sub-stages, the expiration is as follows:
The 'dependencies' stage artifacts continues to expire in 2 hours.
Now, all 'gimp' ones expires in 2 days (to avoid time zone limbo).
For "stage"/tests and "production"/dist, the expire time depends
on the source of the CI pipeline. If the artifact is oriented to a
'short-span' source (e.g. MRs and commits), it expires in 2 days.
If is oriented to a 'LONG-span' one (e.g. web, schedule), 8 days
(we choose 8 to have a +1 day artifact just in case if something
goes wrong in the weekly schedule day, which isn't rare actually).
This happens in particular for in-build runs (or when using
GIMP3_DIRECTORY environment variable on an empty directory). In any
case, I don't see why we wouldn't try and create a directory which was
configured for data storage.
We compile GObject-Introspection anyway (except for cross-builds, where
anyway we don't rely on local Python scripts), so even if not installing
the Python plug-ins, still use them locally.
Resolves #11176
After the initial color space invasion, changing colors in the IFS color
transformation section no longer affected the image. It seems that
ifsD->*_cmap->color held the actual color selected by the user, but
this value was not making it into elements[ifsD->current_element]->v.*_color.
This patch connects the *_cmap->color values to the functions used
to draw the image on the screen.
Move test plugins from /scripts to /scripts/test.
POTFILES.skip that directory.
Add a readme to scripts dir.
Revise readme in scripts/test
Rename test9.scm which tests the new byte type support in Scheme.
Install it in unstable build, it is an important test,
long and sophisticated.
Install contactsheet.scm as a test plugin in unstable build.
See test/meson.build for comments about its issue.
Formerly, both Clothify and "Clothify v3" are installed
in menu Filters>Artistic.
They are duplicates.
Clothify is the original using the old-style, homegrown interface.
"Clothify v3" is new-style, GimpProcedureDialog interface.
Both are marked for translation.
Only Clothify (v2) is translated (in potfiles.in)
"Clothify v3" is not translated (in potfiles.skip)
This commit does not break string freeze.
Moves "Clothify v3" to Demos menu.
It only installs in an unstable build.
The new is installed in unstable only for comparison with the old.
FUTURE: when no string freeze:
Swap the new and the old.
Move "Clothify v3" clothify-v3.scm to potfiles.in
and move "Clothify" clothify.scm to potfiles.skip.
Swap the menu items, so the user doesn't see "v3."
- Fix a few broken references and an inconsistent argument name.
- Add the new headers in the introspectable header list.
- Add a few missing class descriptions for GimpProcedure and subclasses.
Instead of filling default GUI for a specific type of plug-in procedure in
fill_list(), we add 2 methods:
* fill_start() is ensured to run once (and only once) before any fill_list()
code runs.
* fill_end() is ensured to run once (and only once) after all fill_list() ran.
This takes care of 2 kind of GUI bugs which we could have:
1. First if no explicit fill were run (i.e. neither gimp_procedure_dialog_fill()
nor gimp_procedure_dialog_fill_list() were ever run), then the default
interface would not be added to the dialog. Yet this case could happen when
we don't want anything else but the default GUI (this will be the case in the
upcoming file-wmf-load GUI).
2. Second if at the opposite, you fill several times fill functions (I hadn't
thought of this, but noticed some already started to do this in our ported
plug-ins), we obviously don't want the default GUI to be added several times
either.
As expected, it is made to reuse shared code for every GimpVectorLoadProcedure.
In particular, they all need to choose dimensions to load at, so we are sharing
a same GimpResolutionEntry widget logic everywhere now.
I am in fact still very unsure about the code logic for this widget by the way
for these reasons:
* It still puts too much emphasis on the "resolution" (pixel density) part,
which makes people believe it's important, while they should in fact choose
the pixel dimensions most of the time and not care about the pixel density.
* Right now we can't break ratio (which in fact was already impossible in most
vector format plug-ins we had). Do we want to add a chain and allow this?
* If we consider the pixel density as the one we want to set the document with
(which may not be the same thing as the one from when we load the document),
we also want to break link between width/height dimensions and pixel density.
Right now we can't (updating one field updates the others too).
* There is always this issue of precision with pixel density vs. pixel
dimensions because we don't necessarily find the same values when computing
from one side to another because of lack of precision and this confuses
people.
* Finally there is the question of multi-page documents (e.g. PDF) where the
chosen dimensions are the document dimensions whereas each page may have a
different size which has to be recomputed independently and this got me
off-by-one errors. I think I'll need to review a bit the logic, but I'll do
once I've ported all the vector format load plug-ins first to see the most
common usages.
The code comes from plug-ins/common/file-pdf-load.c and apparently it used to be
in libgimpwidgets (very long ago). I'm copying it to its own file and massively
improve the code (depending on property binding which makes the behavior much
more robust).
Still I left it as private because I don't want to say the API is finale without
having tested it a bit more. But eventually we should make it public for
plug-ins to use it directly too. When this happens, it should get back to
libgimpwidgets.
It's still basic but will help to share code for support of various vector-able
formats, such as the logic for dimensioning them, but also the generated GUI.
Not only this, but we are paving the way for the link layers (though it'll be
after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way
for a plug-in procedure to advertize a vector format support. This way, the core
will know when a source file is vector and can be directly reloaded at any
target size (right now, in my MR for link layers, the list of "vector" formats
is hardcoded, which is not reliable).
Only affects unstable build.
Move remaining items to Demos.
They have names like "Test foo."
They only install on an unstable build.
The ScriptFu>Test menu is only in an unstable release.
It is untranslated.
The ScriptFu menus don't need to be so deep.
The Demos menu is an appropriate place for test plugins.
If the Demos menu is not in the stable release and translated,
Gimp creates the Demos menu and it is untranslated.
The "Sphere" plugin demonstrate all the widgets for arguments of a plugin.
Only its menu label is translated.
The "Hello World" plugin demonstrates an independently interpreted SF plugin.
It has no translations, even of its menu label.
Formerly in ..ScriptFu>Test menu.
They still are installed even in a stable release.
If we don't want 3.0 stable to ship with demos,
need more changes to meson.build.
They are akin to the goat exercise plugins.
These plugins are expected to ship with the goat plugins in a stable build.
!!! But 2.10 did not ship with any demo plugins in stable build.
There are duplicate "Sphere" (v2) and "Sphere v3" plugins.
Does not break string freeze.
The new-style "Sphere v3" plugin moves to Demos.
It will be installed with stable build.
No translations will change.
"Sphere" (v2) will only be installed in an unstable build.
FUTURE: we should translate Hello World and Sphere v3.
If they are to ship as demos, their GUI should be translated.
FUTURE: low priority we could rename "Sphere v3" to just Sphere,
and Sphere to "Sphere v2" so there is no conflict.
Partially reverts af79bbe0 (regarding .debug "extraction" in cross builds)
Now, we call the split debug script from the main bundling script, which makes
similar to our macOS .app bundling script. This cleans a bit of code in .yml
and make things clearer to the mere mortals in the scripts.
Its contents is a test plugin, "Test dialog".
I am responsible for it, and it is ugly, even in unstable.
Is only installed in an unstable build.
We need a convention that menu items for plugins named like "Test foo"
should only be installed in unstable build,
and should require no translations.
Note that if the Demos menu does not exist,
Gimp creates it, and it is not translated,
but only present in an unstable build.
Native arm64 and x64 TWAIN binaries are not built anymore. No need to
discard at dist time what doesn't exist. (32-bit TWAIN not affected)
Also, start to using our own ARM64 runners to do the dist. This is more
reliable since the shared x64 runners can (and indeed) cause long queue.
When there is a very long comment shown in the export dialog, the
dialog expands horizontally. Possibly making it wider than your screen
instead of wrapping the text.
Let's set word wrapping for the text view. That way the text will
wrap at a reasonable length and use the multiline text view instead
of just the first line.
They were generating a distracting output in CLANG* shells, as noted by
@lillolollo in a comment from MR: Infrastructure/gimp-web-devel!65
In the process, make AppImage and Windows (native) scripts use these
variables, without hardcoding the same variables from .yml anymore.
Fix ScriptFu, CRITICAL handling filename args user-entered in old-style interface.
Fix plugin, changes to API re Resource i.e. Palette and Colormap
Add message giving mangled name of output file.
Driveby minor refactoring of plugin.
Driveby cleanup, remove old email addresses.
Driveby use script-fu-use-v3 binding to PDB.
Resolves #10914
Some dockables such as "gimp-pattern-editor" and
"gimp-mybrush-editor" are listed as Editors even though
we don't yet have dedicated GimpDataEditors for them.
This causes problems when using certain features like
duplicating. To resolve for now, we check if
gimp_window_strategy_show_dockable_dialog () returns a
valid GimpDataEditor before trying to use it.
Per Jehan, we also verify that an edit button exists
and is visible before we try to call the edit command.
Creating a temporary config directory for the in-build GIMP (run as a tool or
for unit-testing) is not done as a build target anymore, but in the
in-build-gimp.sh script as a unique temp directory, then cleaned out on exit.
This has a few advantages:
- It is properly cleaned out once the build ends (instead of leaving a full
config dir as trash inside the build dir).
- It is not reused from one build to another (with risk of carrying bugs and
issues over).
- Every use of the in-build GIMP will have its own config directory, and in
particular when they are called in parallel.
As a side update, make sure that all `gimp_exe` runs depend on
`gimp_exe_depends`.
This is recommended by Microsoft for "*nix apps" and adding it to the
.exe manifest will avoid disparity between MSIX and other versions
(e.g. CI crossbuilds and CI native builds/installer/local builds).
Bruno note: This commit was repurposed after ad132ad0.
---
For some reason, on the Windows/Aarch64 runners only, submodule updates fails
with:
> + git submodule update --init
> From https://gitlab.gnome.org/GNOME/gimp-data
> * branch d1041a4d97871c85538938872d0ace69d2fc44c2 -> FETCH_HEAD
> error: Your local changes to the following files would be overwritten by checkout:
> images/README.md
> images/logo/meson.build
> images/meson.build
The big question was: why are there edits to begin with? This is supposed to be
a brand new clone!
After a bit of investigation, it turns out that the whole files have incorrect
EOL endings (a `git diff` returns every possible lines in the whole
repositories, but `git diff --ignore-cr-at-eol` returns nothing). It looks like
this breaks the submodule update.
Attribute uap4:ShellNewFileName is meant as a template file to be copied when
someone initiate the Shell "New" command (via the Explorer context menu).
Most of the work in this commit is by @Jehan.
These icons are used only by the .msix (MS Store) distribution of GIMP.
Some legacy icons are used only by Windows 10 and need to have smaller logo
than full image dimensions, so let's not use colorsvg2png. We just pass the
dimensions to use by configuring variants of the same base script.
The new dist job can produce two artifacts: a *.msixupload file
ready for submission and/or a *.msixbundle only for testing.
See the commit about the script for more details.
This makes possible to debug with DIA SDK, if wanted by the developer.
Also, this is needed to create .appxsym files for MS Store debugging.
Ideally meson should be able to install for us, but apparently it doesn't.
See https://github.com/mesonbuild/meson/issues/12977
Adds PowerShell script and proper manifest for making .msixupload
(only for releases) and/or .msixbundle (always, for testing).
As authorized by Jehan, 32-bit willn't be supported. The reasons are:
1. 32-bit is going to die when WIA plug-in is done. This can hurt reviews
2. 32-bit is being restricted in ARM64 version. This causes disparity
3. 32-bit is generating a big footprint. "This is bad for the environment"
To be clear: we are discarding most of 32-bit artifact (see point 1)
and what could not (TWAIN for x64 only, point 2) almost doubles .msix.
There is one small circumstantial reason too:
4. 32-bit wouldn't have .pdb even after GCC 14 because bins have same name
as x64, and MS don't allow multiarch debug symbols in the same .appxsym
Though it's not visible and could happily wait for after GIMP 3 release, this
was annoying when grepping. Just did a quick cleanup.
I also removed gimprc.common which is a forgotten remnant from the autotools
build.
Per Pippin, the only color model that can
have double precision is RGB/A.
Therefore, we need to switch all others to
use float instead. This patch converts the
HSV and HSVA double babl formats.
As hinted in d09a2a6f
We now use the word 'bundle' to signify "program files in the same prefix"
(e.g. .appimage, .zip, .app). This is in line with our source and dev-docs
(just take a search in the repo). So, appimage and windows scripts changed.
The word 'package' normally means "program files distributed for install in
the same prefix or not" (e.g. .deb, .msi, .dmg). This is in line with CMake
naming of some commands, but meson prefers to call 'dist', which we use more.
So, this partly reverts some things of GNOME/gimp!1171 and reinforce others
for even more "rationality" in the overall build structure of GIMP.
… since forever anyway!
GIMP used to have a second export dialog, a generically generated one, appearing
either before or after (depending on when gimp_export_image() was called) the
custom export dialog implemented by the plug-in code. This has been hidden deep
in code since forever (since version 2.8.0 in fact, I believe) and only kept
hidden behind an environment variable "GIMP_INTERACTIVE_EXPORT". I don't think
we'll ever revive this, so let's clean up.
In fact, not one, but in worst case even 2 more dialogs were hidden behind this
variable! The first dialog (confirm_save_dialog()) was a confirmation when the
selected drawable was a layer mask or a channel (and not a layer). Most export
code don't even seem to care about the selected drawables anymore anyway (cf.
issue #7370), except with gimp_file_save() non-interactively (issue #8855),
which is a real mess of inconsistency anyway.
The second dialog (export_dialog()) was listing the various actions to do on a
copy of the image to help the plug-in (e.g. merge layers/flatten image, etc.)
and possibly give choices to some of these actions. Though there is definitely
no reason to request this kind of thing anymore, especially for a short-lasting
image copy, the list of action could still be interesting in the future, not as
information of what is going to be done, but as information of the kind of data
loss of the exported format. I could imagine we want to be able to reuse such
information for generating types of data loss per format in the export dialog,
in particular in the context of my long-term export workflow refactoring (from
which resizing before export such as #2531 are part of, but the whole
refactoring project is much wider).
In the whole discussion of #5858, there will be the question on whether we don't
want plug-ins to be directly given a "ready-to-use" image depending on
capabilities they advertized in create_procedure().
Should resolve #11370
Per Pippin, HSV double is not a valid
color model for babl. We need to change
to HSV float to resolve the warning when
selecting colors on the Color Wheel.
This is a well know problem documented in GitLab docs that happens when
the CI isn't properly configured that was causing double pipelines in MRs.
Let's fix it, and reduce some redundancy.
This line should have never been pushed (in commit a78c41d2a3), my bad! It was
an early (extremely ugly and bad!) attempt to try and have the bindings see the
libraries another way than using DYLD_LIBRARY_PATH (which was instead resolved
with commit 3e980d5ad4).
This omission went unnoticed until I add `set -e` very likely as this failed
command would stop the script in failure.
- gimp_rgb_list_names() ported as gimp_color_list_names() using NUL-terminated
GimpColorArray.
- GimpColorHexEntry uses the new function (and is therefore now GimpRGB free!).
- gimp_rgb_parse_name() deleted as it's unused since my previous commit.
With all this, gimprgb-parse.c is now deleted from the repository! \o/
I suppose the intention of having this stage at the end was to make clear: no
job depends on it. However, this place is not common or ideal but one of two:
1) before building, which is more linear; or 2) after building (the choosen)
even if this isn't dynamic analysis (tests), since they are both related and
some compilers and build systems do static analysis. Anyway, not after dist.
The new place is a bit more clear to devs used at "build, test, deploy" praxis
and maybe will be now better noticed by the existing devs before distributing.
It's not perfect, since I explained above that there are two places/approaches.
Obviously, the stage continues to be OPTIONAL to pass, nothing was changed.
---
Also, dropped the deprecated "only:" (in clang-format job) in favor of "rules:"
and made the artifacts paths of clang-format and cppcheck more consistent.
Fix tests broken by changes to gimp_data, wilber.png=>gimp-logo.png
Uncomment failing tests whose issue was fixed.
Remove calls to deprecated functions.
Make more test files use v3 binding script-fu-use-v3
Compare floats relatively by epsilon.
Add some missing tests.
… test-color-parser.c file.
The file libgimpcolor/test-color-parser.c was compiled but never actually called
by the build. Now that we have a nice infrastructure to test libgimp API, I am
moving it there with the new format. Doing this also allowed me to discover some
bugs in CSS parsing, as well as discover Python binding was failing here (cf.
the few previous commits).
Only one test is disabled so far, the one where 4 digits are used per channel in
hexadecimal notation: "#64649595eded". This format simply doesn't appear
anywhere in the spec, and also the result values in the samples listing don't
even fit. So far, I'm just unsure what to do with it, if we want to keep this
support (of some kind of higher precision hex notation, but not specified, so is
it even used by anyone?) or not.
All the other tests just work in both C and Python!
New functions with the same name as these functions are created, except without
the length argument (i.e. it's equivalent to calling these with -1).
The reason for this is that using strings with a length variant which may be
negative to switch to NUL-terminated strings are not bindable. At least in our
case, when testing in Python, the input string ended up as corrupted garbage and
GObject Introspection docs warns about such interfaces:
> In particular, avoid functions taking a const char * with a signed length that
> can be set to a negative value to let the function compute the string length
> in bytes. These functions are hard to bind, and require manual overrides.
(see: https://gi.readthedocs.io/en/latest/writingbindableapis.html#strings)
So instead, I create a simple version which runs on NUL-terminated strings only
and which is bound, whereas unbinding the generic length-version (making it
C-only, or maybe usable in some other bindings which ignore the (skip)
annotation; apparently some do this).
- "transparent" is now recognized. It was forgotten (probably because on the
GimpRGB interface, we separated the API in a _rgb_ and a _rgba_ variant).
- rgba() and hsla() formats are now fixed (implementation was there but the
function names were not recognized.
- Adding some comment about limitations of the hexadecimal notation (we don't
support the alpha channel which is now in the CSS specs, while we also support
some non-specified variant with every channel on 3 or 4 digits) for future
work.
This fixes:
> plug-ins/script-fu/script-fu-refresh.c:70:1: warning: no previous declaration for ‘script_fu_register_refresh_procedure’ [-Wmissing-declarations]
This is meant to obsolete GeglParamColor with at least an additional argument
has_alpha which we need in GIMP. It allows to advertize when a parameter wants
an opaque color, which in particular means we know when displaying a GUI to pick
colors with alpha or not.
Our pluginrc code is already able to output NULL for a default NULL color, but
reading was failing with the following error:
> GIMP-Error: Error while parsing '/home/jehan/.config/GIMP/2.99/pluginrc' in line 289: unexpected identifier 'NULL', expected number (integer) - fatal parse error
Let's support reading such a value now, especially as for Python plug-ins, we
are not even able to add a default value to GeglColor arguments (cf. previous
commit).
In some binding (e.g. Python), we have not found how to create GeglParamColor
specs for PDB procedures, so we use GParamObject specs with `GeglColor`
object_type. Have our code handle both variants.
Fixes:
> GIMP-WARNING: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor'
Of course such generic spec won't have any future option which we may add to a
dedicated param spec (and despite adding code to handle a default value, adding
a default color still doesn't work according to tests).
There are no plug-ins which uses GimpRGB for procedure argument, nor is there
any base PDB procedure. We don't pass this type anymore through from/to
core/plug-ins. So let's clean the whole code out as a next step to get rid of
GimpRGB from our codebase!
Resolves #11347
In multi-window mode, it is possible to change images without
causing the layer effects popover to close. This results in the prior
image's layer effects being shown over the new image, which is
confusing. This patch causes the popover to automatically close
when the image is changed to prevent this problem.
AppImage is pretty fast to make, like the win crossbuild; and portable,
being very appropriate to do quick tests on Linux when pushing to git.
The overall organization of Debian jobs was changed to take advantage
of this and make things less complicated (but less clear at first sight).
I reinforce that this was the most efficent way to make the AppImage.
This fix doesn't feel right. The whole point of having a generated manifest from
the build was to use it for our flatpak job (through job dependency). Right now,
it has been rendered useless. We must either re-implement the proper job
dependency or find another way to fill the proper "command" with the right
version (maybe just a standalone script to be used in Gitlab CI and which we
could tell about to people who wish to build the nightly flatpak themselves).
Anyway for now, it should do as I don't want to spend too long on this. It
should fix this error in the log generated as artefact of the "gimp-flatpak-x64"
job:
> ../build/flatpak/meson.build:6:2: ERROR: File org.gimp.GIMP-nightly.json.in does not exist.
Resolves #11354
Due to improvements in the text API, we have to pass a GimpFont
object as the last parameter of gimp-text-get-extents-font rather
than just a String.
These files has been generated by the installer scripts for historical reasons.
Now that we have full-blown local builds and the upcoming MS Store version,
this pervasive pratice can't continue since it creates disparity between builds.
When closing the Page Setup dialog we had warnings and criticals in
the terminal.
The cause for this was that we were looking for the temp procedure
to notify the print plug-in. However, this temp procedure is only
installed if the print plug-in is running, not when running the
Page Setup directly, in which case it is not needed.
We now check if the procedure is valid (meaning the print plug-in is
running) before calling the temp notify procedure.
Resolves #11324
Similar to 403af188, we needed to update function calls
that assumed they were receiving a GimpRGB struct rather
than a GeglColor object. Future plans including adding Gegl
functions to retrieve HSV and HSL automatically, rather than
using gegl_color_get_bytes().
Removes an index that was needed to GimpRGB, but no longer
valid now that gimp_palette_entry_get_color () returns a GeglColor
object. Also, fixed an issue in Interactive Mode where the first
valid palette would be used for every other attempt, no matter which
palette you clicked on.
Switch to using gimp_item_convert ()
instead of gimp_item_duplicate () so that
the filter mask can be properly associated
with a new image when copy/pasted.
Previously, filters were lost when copying
individual layers. This patch copies them
to the clipboard image on cut or copy,
then copies them back to the pasted
image.
It also fixes an issue where filters would
be merged down if a selection was
copied instead of the entire layer.
The comment I had written back then was wrong. Meson in fact can create an env
object from another with a simple assignment (which copies the object, rather
than pointing to a same object), per the answer which has been given to me in:
https://github.com/mesonbuild/meson/issues/13045
This allows to have a properly separate environment (when using GIMP as a build
tool, we don't want to load the test files).
We are using `gimp_image_set_file` to set the filename, which
requires an extension, not doing so caused an error.
So let's add .xcf to all compose filenames.
When decomposing, the plug-in sets the filename without changing the
extension. However, gimp_image_set_file requires the filename to be
an .xcf file.
To fix this we simplified `generate_filename` to always add an
.xcf extension.
While doing this we also fixed a critical that happened when no
filename was set (new image), by testing `gimp_image_get_file` for
being NULL first.
When no filename was set it also didn't use the type when
config_as_layers was set, this is also fixed.
Resolves #11334
GBR, GIH, and PAT have internal save functions which are not meant
to be run directly. However, they were showing up in the Search dialogue
as valid options. This patch adds an additional check for "-internal" to
prevent users from accidentally running them, as they only give a warning.
The whole action name prefixing will definitely need to be straightened up in
our codebase at some point (differenciating the global actions and the local
ones).
Resolves #11337
"gtk-icon-shadow" is applied to all buttons with images,
which creates a bold effect on symbolic icons.
This patch zeroes this effect out and makes them highlight
the background in the same way as the toolbox buttons.
For certain min/max values of the LabelSpin widget, in combination with
zero digits, it proves impossible to change the initial value.
The reason for this is that the step size may become less than 1.0.
In which case, stepping doesn't work because the number of digits is
set to zero.
Let's check for this situation and when digits is zero set the step
to 1.0 and make sure that page is at least the same value.
While testing this I also noticed another issue: when initializing
the upper value was set to 0.0 and the lower to 1.0 which leads to
a critical because lower > upper.
We fix this by switching the initial upper and lower values.
There was no user feedback when our twain plug-in couldn't find the
(32-bit) TWAIN driver, making for a poor user experience.
Especially since nowadays the availability of the twain driver is
less likely, let's add an error message for the user, so they will
know what's going on.
The previous commit worked for all the compiled executables, but for Python
plug-ins (and likely all other GObject-Introspected bindings), we need to
generate a temporary typelib linking to the in-build-directory libgimp*
libraries.
This is similar to what the script `package/macports_build_app.sh` does for
packaging in gimp-macos-build repository.
Resolves #10932
Since GIMP distinguishes between saving
XCF and exporting image like PNG,
we should change the PDB to show
export rather than save in the function
calls.
This stage was introduced in 076e4d68 and it fulfilled well its purpose. But
the side effects were: more (sometimes slow) uploading and downloading of
packages and artifacts. Even if we have caching, this is far from ideal.
Now, the so-called "packaging" jobs were moved inside in the "build" jobs.
The advantages are: just one pacman install (ideally cached from deps job);
direct packaging without waiting for upload/download; and less confusion,
since "packaging" naming was implying that the .zips are somewhat official,
which isn't totally true, and sometimes overlaps the dist/deploy concept.
---
Also, the flatpak job now uses config.h instead of triggering a GIMP build.
In other words, I'm reverting part of my work in some old commits.
Unlike the previous 2 commits, this was not making an error but was the reason
why our code was keeping the last closed GimpImage alive a bit longer than it
should. In particular, the status bar code was keeping a hard reference to the
image until the focus changed, hence preventing the object to get finalized
longer than necessary.
Now it will also be a weak reference, so the image is immediately freed when the
view is closed.
Now, the CI will auto cancel jobs after a new commit is pushed and retry when
the runners fails. The first case is frequent, the last is rare but happened.
Since the GeglColor port, gimp_drawable_get_pixel () returns
a GeglColor rather than a GimpRGB structure. We needed to
update the supporting code in ColorXHTML to handle the change.
As a follow up to the previous commit, I noticed that the pdb functions
gimp-edit-cut and gimp-edit-named-cut also incorrectly used
gimp_pdb_item_is_group.
This can be seen by calling Filters/Blur/Tileable blur when a group
layer is selected. The error message was incorrect.
We replace the call here also to `! gimp_pdb_item_is_not_group`.
Calling gimp_selection_float from a Python plug-in could make it crash
with an error like Calling error for procedure 'gimp-selection-float':
Item x cannot be used because it is not a group item.
This is caused by an incorrect check for group layers.
gimp_pdb_item_is_group returns an error when the condition is False,
while we only want an error when a group layer is selected (True).
Thus we need to use gimp_pdb_item_is_not_group, which returns an error
when the item is a group, which is what we want.
These function names are a little confusing, we might need to think
about better naming sometime.
I added C/Python tests for this function, so that we can test whether
this works correctly.
This is now back in sync with how it used to be up to GIMP 2.10. Basically our
API version should always be <major>.0 in the shared libraries naming, as well
as in pkg-config and docs. Otherwise we would break library compatibility with
every minor version bump.
Code that checked if an image was NULL was run
*after* the variable was used in a function,
gimp_image_resize_to_layers (). This patch moves
the NULL check before the function call is made.
Additionally, we now verify there are at least two axis
before trying to access indexes in the naxis array.
Since !1171 the 'before_script' was being used by me for organization, but
this is at least unexpected to "mainstream" .yml pratice and can be wrong.
For example, the universal variables can't be properly used this way.
So, let's use 'before_script' only for the (official) purpose: save code.
Resolves #11292
Since the GimpProcedureDialog port, the "settings-data"
parameter has been used to save and load the selected
color map. However, the parameter was not being updated
when the user switched colormaps in the GUI - therefore, it
always used the "Custom Gradient" option.
This patch updates the "settings-data" parameter after the
change to resolve the issue.
This isn't directly related with #10922 and does NOT affect 32-bit support.
After talk with @Jehan, author of 'crossroad' and main dev of crossbuilds,
we decided that the x86 crossroad builds can be dropped by these reasons:
1) 32-bit crossbuilds weren't being built. They are used since c8ec0ae7 but
after the native 32-bit builds they ended in a state that they are the only
pipeline that isn't automatically triggered in any way, a complete limbo.
2) 32-bit crossbuilds weren't being autonomous. They are not working fine
with wine32 so the win-x64-cross artifact is a 'need' and now debian-x64,
so we were spending way more time fixing than using the 32-bit cross jobs
(sometimes the 32-bit cross jobs are just broken and we even noticed).
We have other jobs not autonomous but they don't have additional bugs
like not being able to build with .mng and .wmf (32-bit cross only bugs).
---
The x64 crossbuilds will continue to be supported. They are very useful to
develop on Linux, and test MRs on Windows. I'm an assiduous user of them :)
Resolves #11283
In the GUI, set_flame_preview () is connected to GimpProcedureConfig's
"notify" signal. However it is not disconnected afterwards, so it runs again
after the plug-in is finished and the "setting-data" parameter is updated.
Since the preview area no longer exists, this causes a crash.
This patch resolves the issue by storing the callback ID and then disconnecting
after the GUI is closed.
This was added in a22393a6 and e96b751e, following old 2_build-gimp-msys2.sh.
But, according to my tests (local and in the CI, in both Debian and Windows),
meson creates this in setup time so the manual folder creation is redundant.
Resolves #11250
In 2.10, we explicitly hid "dockable-preview-size-menu", the submenu
for Preview Size, if there were no previews to set sizes for in the
dockable dialogue. In 2.99, this code was removed as part of the
GAction port and code clean-up.
As a result, the Preview Size submenu is always visible even if the
options have no effect on the display. To restore the 2.10 behavior,
we set each Preview Size option's visibility. If all options are hidden,
the submenu does not appear.
* Move common things to the new .default section extensible for all jobs
* Reorganize order of job elements to be way more consistent and rational:
from general (pipeline/rules) to specific (job artifacts) in a liner way
* The order of rules was changed to be a bit more easier to understand
- Drops 'dependencies' which is redudant, and 'needs' have more options
- Drop apt-cache which lost use and it is sometimes troublesome to cache
+ First try to boost the use of ccache in all build jobs, when possible
+ Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
Build for macOS on CI breaks with:
> ../gimp3-2.99.19/libgimpwidgets/gimppickbutton-quartz.c:210:45: error: use of undeclared identifier 'monitor_profile'
> space = gimp_color_profile_get_space (monitor_profile,
In case there are no fonts loaded (which may happen in particular when starting
with --no-fonts), we need to make sure that font is initialized to NULL so that
we can return the standard GimpFont object and not a broken pointer.
Thanks to Idriss for the additional diagnosis, which would hopefully complete
commit 5dc86277e6 and take care of #11219.
This commit uses definitions and references to reduce repetition of CI code.
Some people (like the GitLab devs?) prefer (almost imposes) this to be done in
multiple .yml's using 'worfklow:' but this makes the CI way more complicated
and very slow to read. So, let's just keep simple in one human readable file.
---
Other changes are:
- The custom native arch pipelines now they always generate a .zip package.
This helps to ensure that everything is in place and facilitate testing;
- The pacman update (-Syyuu) was removed since it is auto done by runners;
- The ccache config was moved to .yml. This does NOT affect local builds
since meson saves ccache by default for user in '%LocalAppData%/ccache'.
Previous code would only set the class member when we were actually
loading fonts, so we ended with code paths where the member was NULL.
Fixes:
> GIMP-CRITICAL: gimp_container_get_n_children: assertion 'GIMP_IS_CONTAINER (container)' failed
It should hopefully also fix #11219 (though I couldn't reproduce this
failure).
Resolves #11256
A GError variable was created but not passed to
file_open_with_display () when opening recent files.
As a result, if an error did occur the variable would be
used while it was still NULL. This patch fixes this
by passing a reference to error as the last parameter
of file_open_with_display ().
We compute the size of the mipmapped layers wrong. We assume that
width, height are always exactly a power of 2, which is the normal case
for dds images. See issue #11256.
Since other sizes are possible, we adjust this by computing the width
times height times bytes per pixel of the current mimmap level.
Resolves #11075
In the DrawableChooser pop-up, choosing an image without
also picking a layer or channel causes the pop-up not to
reappear on subsequent attempts to click it. This is because
the callback is only recreated when the drawable is updated,
and choosing just an image does not update the drawable.
For 3.0, we'll set the Okay button to insensitive unless a layer
or channel is picked.
I added a few improvements to how we load the Photoshop layers:
- When included from TIFF, we forgot to decrease the data_length for
the parts we already read.
- Also when included from TIFF, we need to skip the global layer mask
info.
- The block length for the layer data needs to be a multiple of 4.
- Catch an invalid data condition where block_len is greater than
total_len. This could cause a change total_len to a very large
value, so protect against that.
When loading Photoshop metadata from TIFF images, the size of the data
in the temp file was often incorrect.
This happens because run_mode is usually GIMP_RUN_INTERACTIVE when
run from within GIMP. In interactive mode, the last saved config values
take precedence over the ones set in the function call, which is not
what we want in this case.
We would prefer to use interactive here, because then we can show a
dialog with a list of unsupported Photoshop features that were found
inside the image.
For now, we will use GIMP_RUN_NONINTERACTIVE and accept that we can't
do that at this time. This way we will at least have the correct values
when processing the Photoshop data.
The clipping path values are all 2 bytes, but we were only reading in
1 byte for each value. In addition to that, the path_flatness_fixed
value was not converted to the correct Endian representation.
Since these values are usually 0 and get clamped to valid values, this
went unnoticed until now.
Fixes 2 such warnings:
> warning: format ‘%i’ expects argument of type ‘int’, but argument 5 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
As well as:
> warning: conversion lacks type at end of format [-Wformat=]
And:
> warning: no previous declaration for ‘reset_output_port_struct’ [-Wmissing-declarations]
Fix unreported issue that new-style dialog using GimpProcedureDialog
does not display progress.
Change progress reporting to use app's status bar, for all scripts,
old and new style.
As before, report progress whenever a script calls a PDB procedure,
by putting the procedure name in the status bar.
Eliminate progress bar widget from old-style script dialog.
Since it was failing on Wayland, and since it is inconsitent
with new style dialog using GimpProcedureDialog.
Resolves #11246
On Windows, a CRITICAL was being repeatedly thrown if you
didn't have a monitor profile set. This is because we were trying to
pass a NULL value to g_utf16_to_utf8 () whenever we needed to
convert a GeglColor.
This patch fixes it by checking if the monitor profile filename is NULL
before trying to convert it.
Resolves #11244
GtkRadioButtons can also have the .text-button CSS class set. This class was overwriting
the radiobutton background color, making it appear dark and box-like.
This adds a specific radiobutton.text-button definition to ensure the background color
is consistent (as we had to do with checkbutton.text-button)
It is broken and throws critical, see #10596.
Expedient to hide it instead of fixing it, to not block 3.0rc1.
As discussed in #10652, a user can simply restart GIMP instead.
"Refresh Scripts" is a poor design, a bandaid.
There are plans for better alternatives to install/remove scripts.
The MR for #10652 shows the reason it throws critical,
and could fix it,
but completing the MR requires time we don't have.
Note the MR is not on these files, but on core plugin machinery.
The change is to extract functions to a separate file,
and still build them, but not call them or link them.
They also are not translated while not being called.
Eventually, the extracted files can be deleted (or restored when they work.)
There is other related cruft that needs deletion in scheme-wrapper.c.
Add canonical/idiomatic functions call-with-output-string,
call-with-input-string, any->string to the library init.scm.
Since they are useful, especially in test scripts and frameworks.
Remove their definitions from test scripts and test frameworks.
Also comment out failing test in test script string-escape.scm.
Redefine call-with-output-string etc. in the test script: test9.scm
Other fixes to the test script.
Improve logging of no memory condition for string-ports
Fix bug freeing ports that have been closed.
When ports are closed, string-port code was treating them as string-ports.
Fix #11040 and #9495 bugs with unicode in string-ports
Fix other unreported bugs with allocations and garbage collection of string-ports.
Obsolete open-input-output-string, a string port of kind input-ouput is no longer supported
and the function actually opens a string-port of kind input which cannot be written.
Comments and Gimp style in the original TinyScheme code, now in string-port.c
Revise tests of string-port.
Update TinyScheme README: Discuss more thoroughly the ancestry, and changes from upstream.
Extract pseudo class string-port methods to separate file.
No functional changes intended.
Style changes not complete: anticipate further bug fixes and styling.
This is not seen on all distributions (mostly on Debian-based ones in my
experience), but some distributions install libraries in a second-level
directory under prefix (e.g. lib/x86_64-linux-gnu/ instead of lib/ or lib64/)
whereas our prefix-guessing code for relocatable builds harcoded moving up from
1 level.
This new heuristic will assume that if the leaf directory is neither bin/ nor
starting with `lib`, then it's likely a multiarch folder and we must move up
once more to find the prefix folder.
This should also fix the problem encountered by Bruno for the current work on a
potential official AppImage.
We dereference "file" twice in gimp_prop_file_chooser_button_callback(),
once in the GIMP_IS_PARAM_SPEC_CONFIG_PATH () condition and then
at the end of the function. This is likely due to a similar structure in 2.10,
which did not have a second condition.
As a result, any Gegl filter which had a file property would crash if set from
a GUI. The first g_object_unref() is removed so we only dereference "file"
once.
Resolves #9795
(Solution provided by Andreas G, @uriesk)
Some system themes provide errant values for tooltip
box-shadows which cause flickering effects.
This patch defines the tooltip box-shadow to 0px to
prevent the issue.
Resolves #11054
NDE Filters clip to the size of the layer when
applied. Group layers get their dimensions from
the largest layers under them, so an empty
layer has dimensions of 0 by 0. This means a
filter applied when the layer group is empty will
be clipped to 0 by 0 as well.
This patch adds code to refresh the filter's crop
whenever the group layer is resized by a
layer being added or removed.
These commits introduced sensible drawbacks in our CI file organization.
Some of them I already commented in the MR but was "ignored" back then
probably due to the complexity of the MR. So, the let's revert:
- Unecessary repetition of libomp installation (4 times, now 1)
- Unecessary repetition of submodule initialization (6 times, now 4)
- Creation of new variables in the hope of more clarity. But,
they aren't consistent with the gimp-web-devel instructions
nor with other systems variables. This is terrible to undestand.
Please, let's not reinvent the wheel since this is a bad example to
packagers, since they tends to isolation and overly-engineering.
Also, made some little adjustments that I should have done in previous MR.
---
This MR was splitted. Even more simplification will be done in the future.
...to accept GeglColor paramaters instead
of GimpRGB. This function is used to draw
the layer/channel color tags.
Note that a temporary GimpRGB was left
to use with gimp_rgb_composite ().
It will be replaced once that function is
also converted to use GeglColor.
752f0fb4 did not fix saving/loading filters
in .xcf files. To do this, a new function to
retrieve the clip setting was added to
gimpdrawablefilters.c, and then used to
save the value in xcf-save.c. The existing
set_clip function was used in xcf-load.c,
just like in 752f0fb4.
Resolves #10997
When filters are duplicated for export, the clip property was
not being copied over. This caused filters that go outside the
layer boundaries (like Drop Shadow and Long Shadow) to be
clipped incorrectly.
The simple fix was to copy over the clip value when the new
filter was duplicated.
Resolves #11147
Applying the same reordering code
in cbb1e816 to adding a floating selection.
When anchored, floating selections were also
merging down all layer effects onto the original
image. This patch places the float selection
under the layer effect when added, both to prevent
this and because it seems to be the expected
behavior based on user feedback.
Resolves #11146
As Idriss Fekir and I noted, 5ce128a9 added support for
receiving GeglColor data to GimpColorAreas, but
retrieving it still resulted in RGBA application/x-color
values being stored when dragged.
This patch updates gimp_color_area_drag_data_get () to
give the format and profile information along with the
pixel values.
When loading a PSD with multiple extra layer channels, the PSD loader
crashes. We increase the number of layer_channels with 2 for every
extra channel found, which we only should do for the first extra to
skip the alpha channel.
We fix this by adding a check to see if this is the first extra channel
and in that case skip the alpha channel slot. Any other extra channel
will be added in the next available slot.
We also add an extra check in case we have extra channels when we do
not have an alpha channel in the layer. Not sure howe likely this is.
In that case we move the last extra channel to the slot reserved for
the alpha channel. That way we won't try to free non-existent alpha
channel data.
Note that eventually we should probably try to add these extra layer
channels are extra image channels in GIMP, since GIMP doesn't have the
concept of extra channels per layer.
The border-drawing code for Layer icons
has been ported to GeglColor. Note that
GimpViewRenderer still uses GimpRGB for
gimp_cairo_checkerboard_create (), which
will be fixed in a larger commit.
In 9bee3bed, Border Average's return
value was set to NULL rather than a valid
GeglColor when the procedure was
created, which caused a warning on
launch. This has been fixed.
Perspective shadow could call plug-in-gauss-rle with higher blur
radius than allowed in the wrapper. Raise the max value to
allow for this.
Fixes #11140
Since dist-installer-weekly doesn't depend on gimp-debian-x64 anymore, we need
to grab the config.h from one of the other dependencies. Let's use the one from
gimp-win-a64 (though it could have been any other Windows build job).
Fixes:
> Get-Content : Cannot bind argument to parameter 'Path' because it is an empty string.
> At C:\_r\_builds\vJWzEqDv\0\GNOME\gimp\build\windows\gitlab-ci\4_dist-gimp-inno.ps1:13 char:39
> + $GIMP_VERSION = Get-Content -Path "$CONFIG_PATH" | Select ...
> + ~~~~~~~~~~~~~~
> + CategoryInfo : InvalidData: (:) [Get-Content], ParameterBindingValidationException
> + FullyQualifiedErrorId : ParameterArgumentValidationErrorEmptyStringNotAllowed,Microsoft.PowerShell.Commands.GetC
> ontentCommand
The dependency to libomp apparently came with the move to CLang.
Fixes:
> /builds/GNOME/gimp/_install-debian-x64/bin/gimp-console-2.99: error while loading shared libraries: libomp.so.5: cannot open shared object file: No such file or directory
When running GIMP in the build environment (even before it's installed), we
don't want to "fix" paths. We had the case in particular on the macOS CI where
the install PREFIX was a parent directory of the build directory and therefore
we were "fixing" some perfectly good constructed directories (set by meson) into
non-existing folder paths.
Additionally this codepath should only run when ENABLE_RELOCATABLE_RESOURCES is
set (even though this alone would not have fixed our CI issue because the macOS
build is relocatable).
Finally I am updating the gimp-data repository so that libraries are properly
found from the (now correct thanks to this commit) paths set by meson when
running gimp-console from within the build directory.
When the config directory is set by an environment variable, the version is
likely not part of the directory path, and therefore strstr() would return NULL.
Fixes:
> (gimp-console-2.99:41446): GLib-CRITICAL **: 13:19:34.933: g_vsnprintf: assertion 'n == 0 || string != NULL' failed
Now the development and stable logos will be generated from gimp-data.
In other changes, the gi-docgen logo is installed as a symlink using
install_symlink() which exists since meson 0.61.0 so I bumped our meson
dependency (in practice we were already using this function anyway and Debian
bookworm has meson 1.0.1 so it's all good).
Finally I don't install a wilber.png anymore, which was only used by script-fu
testing, and which was the same as gimp-logo.png (except 256x256 instead of
128x128). Unless mistaken, all script-fu tests loading this image still work
with the change. The only one where I needed further change was buffer.scm
(which was checking the dimensions).
See gimp-data@9aa6e35.
- With last commit, the Windows installer pipeline doesn't depend on
"gimp-debian-x64" job anymore since a native Windows build is now able to run
GIMP (or gimp-console) as a build-time tool as well. It makes the Windows
installer pipeline (and full custom native builds) self-sufficient.
- On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require
"gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in
order to generate some image data (such as the splash image, and probably soon
logo or icons, etc.). See gimp-data@5a03c71.
- Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of
"image-debian-x64" for all Debian as well as the cross-compilation jobs. They
are all based on the same Debian image (it was debian:bookworm for native
Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork
for all) and it's just a few more packages (cross-compilation C and C++
toolchains) for the cross-builds. Moreover now the cross-builds also need the
native GIMP binary around, therefore native dependencies are needed as well.
It makes sense to factorize all 3 images into 1.
- Make sure we don't build bindings when cross-compiling since these won't work
in this case.
This commit is in conjunction of gimp-data@d273a18 and finally makes Windows
build able to run GIMP main binary itself (or gimp-console) in order to create
various images, before the installation step.
- Use the new GIMP_TESTING_INTERPRETER_DIRS environment variable for uninstalled
binary to find the .interp files (in particular because our build scripts are
usually Python scripts these days).
- Use the new GIMP_TESTING_ENVIRON_DIRS environment variable to find .env files
(actually running uninstalled GIMP binaries did run without this one, but it's
not a bad idea to add support anyway.
The python.env file sets a ':' separator for GI_TYPELIB_PATH environment
variable, which breaks finding the correct typelib files in the CI, when also
manually setting a previous value for this environment variable.
I'm not entirely sure the rule of swapping ':' for ';' is universally true on
Windows, whichever the variable. Let's hope that it is.
- Splash images will now be stored from gimp-data.
- The installer BMP image scripts also move in the same time.
- We don't need devel and non-devel variants of the BMP images in InnoSetup
scripts since the images are generated from the actual splash.
Meson subprojects just have too many problems and limitations and I can foresee
the maintenance headache and the future incoming false-positive bug reports if
we start using meson subprojects.
Comparing to the simplicity of git submodule which also has much better
notifications to help people understand when the submodule is not in sync and
how to remedy to it.
See commit gimp-data@c364adb explaining the main reasons in detail.
Note that the executables are not built yet at this point, but we just need to
pass the name for configuration. The gimp.ico generation step is run manually
anyway and requires a fully functional and installed GIMP.
See commit gimp-data@40d4822.
This commit is separate from the previous to make it immediately clear (by
comparing files) that the previous commit is a simple move with no modification
whatsoever of the icons/ directory, i.e. the symmetrical removal of add commit
gimp-data@8b54490.
We now clone gimp-data as a meson subproject. I am currently testing the
subproject feature though I am doubting a bit because of its limitations: the
git clone is not updated automatically, nor are errors clear. Therefore it would
be easy to end up with outdated data for developers not manually and regularly
running:
> meson subprojects update
Worse, it looks like even when updating the suproject, it fails to be properly
reconfigured. See: https://github.com/mesonbuild/meson/issues/12898
In our efforts to use Clang, now the nightly (in fact weekly) flatpak
is built with Clang too, not only GIMP but also the dependencies.
* However, not aalib. We welcome fixes regarding this cursed lib.
Additionally, updated some build options from some deps.
Resolves #7672
The Plasma wrapper gets the boundaries
of its filter area using gimp_item_mask_intersect().
If used on a selection, this gives the x and y
coordinates relative to the total canvas.
However, the GEGL operation will be drawn
relative to the selection - so this offsets
the effect within the selection rather than
filling the full space.
This patch fixes the problem by setting
the x and y position to 0 when there is an
active selection.
Layer effects that have not yet been committed are not
attached to the drawable. Trying to reorder them causes a
crash since they're required to be attached for undo/redo
purposes. This patch checks if they're committed beforehand,
and informs the user with a warning if it's not possible.
In GIMP 2.10 the number of segments was restricted to MAX_FANS.
That was later changed to 1024 without increasing MAX_FANS
which can crash the plug-in.
Also change the max displacement angle back to 90 degrees. The interval
0 to 90 degrees is enough to return all possible values.
Fixes #11108
...to fully use and return GeglColor.
Also, fix gimptext-parasite sending a
GimpRGB to create a GimpText instead of
the now required GeglColor, and update
documentation in gimp_checks_get_colors
to reference GeglColor instead of GimpRGB.
Resolves #11092
Same fix as in 2b3b2af2, since Blinds and Jigsaw
were the two plug-ins which used GimpAspectPreview
before the port to GimpProcedureDialog.
After the port to gimp_procedure_dialog_get_drawable_preview (),
the preview widget was being sized to the original drawable's dimensions
while the drawable was being redrawn with only its thumbnail dimensions.
This created a scrollbar that showed unallocated/overwritten buffers.
To fix, we update the preview size and boundaries whenever the preview
is changed. This removes the scrollbar and returns to 2.10 behavior.
In addition to the port, mnemonics were added to both file-pdf-save-multi
and file-pdf-save's GUI parameters.
Some runtime warnings were also fixed, such as trying to use a NULL string
parameters to make a file and trying to access properties from file-pdf-save
that don't exist in file-pdf-save-multi.
As shown in a video for issue 11087, some system themes
may add a white box-shadow on the side of unselected
tabs. This patch forces box-shadow to "none" to prevent
this.
Resolves #11057
Per Idriss Fekir's research, data from GBytes
should be written before the GByte is freed.
Perhaps due to luck, the data persisted on
Windows but was freed too early on Linux.
This patch should resolve the issue.
Resolves #11083
Per bootchk, changes in function calls to
palette_entry_get_color () and
gradient_segment_get_left_color () were
broken in Python scripts due to GelColor
being used post Color Space Invasion.
This patch fixes the calls and returns.
More descriptive name for script-fu-interface-dialog
Delete SF flag for gimp_ui_init already called: gimp_ui_init can be called often.
FUTURE: might be faster to call just gegl_init when mode is non-interactive.
After the color space invasion, the
Clip Warning filter no longer had color
areas for its shadow, highlights, and
bogus color properties. This patch ports
them to GeglColor so the widget can be
created correctly.
GimpRGB structs are also converted to
GeglColor in GimpPanedBox and two
plug-ins.
Otherwise we are not in a valid position anymore and further loading the XCF
fails. This may happen when updating a GEGL operation (in particular removing
effect properties, or renaming them).
The two threshold color pick buttons needed to have
a GeglColor parameter for their GimpPickerCallback
rather than a const GimpRGB.
This also fixes a crash caused by trying to free the GeglColor
rather than unreferencing it.
Without this, there is no easy way to quietly check for existence of a resource by name.
Needed when plugin authors can name defaults for resource args by name.
Add tests to script-fu/test/tests
Mainly fixing GimpRGB comments and
parameters that are unused (or in unused
functions).
GimpCircle and GimpGradientChooser
have color conversions ported to use
GeglColor exclusively.
Since commit 10b96b1025, we had buffer leaks as soon as we ran filters.
gimp_drawable_get_buffer_with_effects() was either creating a new buffer (when a
drawable had filters) or not. And calling code couldn't know which is which.
Code needs to be consistent. Either we return a new reference to take ownership
to, or not. So let's change to add a new reference to the drawable' buffers so
that it always returns a new reference to free.
So far, we did not consider that group layers could also be part of
a set of layers that have clipping set. This means that clipping groups
can be nested.
To support this we have completely rewritten the layer parser to detect
all clipping groups and mark them in a first pass. We now go through
the layers from the last (top) layer to the first (bottom) in this
first pass, because that makes it easier to detect the start/end
pairs of a clipping group.
In the second pass we handle the clipping groups first before adding
layers, except when a regular group is also the start of a clipping
group. In that case we need to handle the clipping after creating the
regular group, or we get an incorrect order.
Unsupported psd layers were dropped when loading psd images. This
causes problems when handling psd clipping groups, see issue #8453.
PSP also does not drop unsupported layers, so let's keep the layers
and accept that they will usually show up empty. This will help in
fixing clipping groups in a next step.
While we are at it, also remove the warnings that are only shown when
define CONVERSION_WARNINGS is TRUE (defaults to FALSE). We already
have a better way to show unsupported features, so at least for the
unsupported layers it is not needed anymore.
There are still some CONVERSION_WARNINGS warnings left over in the
blend modes conversion, which do not have a similar warning in our
unsupported features dialog.
* Makes the wording more concise and "first contributor-friendly"
+ Adds info about submitting patches
* Makes the explanation of use cases implicitly mandatory
+ Adds discuss info to facilitate the redation of use cases
This commit unites two scripts (.sh + .bat) in one .ps1. PS was choosed, since:
1) We don't need MSYS2 to distribute with Inno at first. Now, who wants to
just distribute GIMP can do it easier natively without a separate environ.
2) PS is actually pretty solid and have a good number of cmdlets, unlike the
ancient CMD, which barely supported more than 9 parameters in .bat files.
Consequently, some redundant variable checks have been removed from the .ISS.
Also, changes the name of the job and script for better consistency with the
upcoming MS Store job.
Though commit a14caafa8c was not wrong per-se, it's a bit too much. ;-)
Functions like g_ascii_dtostr() already exists for this very purpose of
converting a double/float to string in a locale-independent format.
CSS breaks when given a number with a comma as the radix
instead of a decimal. Depending on the system localization,
printf () may return numbers in this format when resizing
the font. This causes the theme to break unless font size is
set to 100.
To prevent this issue, we create the font size string manually
using integer division and mod operations.
- Replaces GimpRGB in Channel Dialog
with gdouble array, as was done in
channel_options_color_changed ()
- Replace %ld with G_GSIZE_FORMAT
in libgimp checkboard color message to
fix warning in Windows build
- Set file-gih documentation text as
translatable.
I think I may even have been the one who suggested to make this checkbox always
visible, but after more thought and usage, I just realize that this option is
not about showing the Welcome dialog, but about showing the Create tab of the
Welcome dialog. So I move it to the Create tab.
A very obvious case where the previous option location could have been
considered wrong is that we will always show the dialog (on the "Welcome" tab)
for updates, even if this checkbox had been unchecked. So if we left it as a
global option of the dialog, this could be considered a bug (the option is
disabled, but the dialog still opens on updates), whereas the new position and
shortened label make it clearer that this settings only apply to whether or not
we show specifically the Create dialog on start.
The splash image had a lot of empty space around it. From what I understood,
this is because we want to avoid it to be too big because it makes the dialog
overgrow the display size on small screens. But I don't think that was a very
good idea. We should find better ways to save space.
In d055564d, a pointer to the color profile
for NDE filter color properties was being
saved rather than the actual ICC profile.
This patch fixes the issue.
It also allows colors to load even if the
color profile is corrupted, with a warning.
Per bbb30eac, the GimpHSV object is replaced with
gegl_color_get_pixel () in "HSV double" color format.
GimpCellRendererColor still needs to be updated to
accept GeglColor rather than GimpRGB.
This commit fixes several issues with the plugin.
* Move plug-in to GimpProcedureDialog framework (see #9250)
* Use GimpPalette instead of (soon to be deprecated) Colormap (see #9477)
* Make plugin UI height, make it resizeable, update font sizes,
paddings, etc (see #10533)
Further improvements most likely are needed because plugin still uses
GimpRGB and GimpHSV (former is used by GimpCellRendererColor, latter for
H, S, and V values)
Resolves: https://gitlab.gnome.org/GNOME/gimp/-/issues/10533
Resolves: https://gitlab.gnome.org/GNOME/gimp/-/issues/10749
During the GimpProcedureConfigDialog port,
the "gimp-brush-pipe-parameters" parasite loading
code was unintentionally removed. This parasite
was used to restore the GIH parameters if it was
loaded as an image.
This patch restores that code on initial export as
GIH, then removes the parasite since the parameters
will be saved as part of the GimpProcedureConfig
going forward.
Allow (script-fu-use-v3) in script, or in SF Console.
Definitive description is in script-fu/docs/using-v3-binding.md
Makes SF interpret v3 of SF dialect.
- marshals single return value from PDB without wrapping in list
- marshals boolean return value from PDB as #t #f instead of integers
- marshals boolean to PDB from #t and #f or TRUE and FALSE
- marshals void return from PDB as () instead of (#t), but that is moot.
The version of SF dialect is distinct from the version of the PDB API.
Dialect v3 is opt-in: the initial dialect of all SF tools remains v2.
Commit also allows #t,#f for defaults of SF-TOGGLE instead of TRUE, FALSE
but that is an independent enhancement (but closely related.)
Affects interpreter state of the current process.
Not an attribute per se of a plugin.
While in this state, a plugin should not call PDB procedures
which are themselves v2 script plugins,
or a few utility scripts in script-fu-util.scm,
but that is rarely needed.
Does not remove symbols TRUE and FALSE from dialect.
A script can also call (script-fu-use-v2) to revert.
That is also discouraged but useful e.g. for testing.
Fixes #9883
There were menus that put their entries
directly in the tab menu rather than in a submenu.
This moves them to submenus to bring back GIMP 2.10 behavior.
Stray entries added by scripts are also moved to the right
submenu.
For improved readability, int or boolean types are used in place of
guchar for PDB parameters where the parameter description better fits
one or the other type.
This change affects `plug-in-alienmap2` and `plug-in-maze`.
Also, the problem with `guchar` parameters is that they currently cannot
be modified via `GimpProcedureConfig` due to the type not being
supported.
Call gimp_ui_init during query phase as well as run phase.
Maybe gimp_main() should do this.
Since space invasion from GimpRGB to GeglColor,
plugins that declare defaults for formal args of type GeglColor
need babl and gegl at plugin registration time.
The 'Docker' draft of GIMP was introduced in 09/04/2017 and then died ONE day
after, mostly because of "bad" timing (few years later we moved to GitLab CI).
Similar (in fact, even worse) than 'jhbuild' folder, update it to keep the
current development status is so hard that it is equal to do it from scratch.
So it is reasonable to delete it anyway.
Due to changes in our metadata handling API for plug-ins, the exif and
xmp metadata read from exr images was being overwritten by empty
metadata.
Fix this by following the new API and also add messages when loading
metadata fails. That way it will be easier to catch in the future if
metadata loading gets broken again.
When defining jpeg_exr a closing \0 is automatically added by the
compiler. So when we compare it using sizeof, we do not compare
6 bytes but 7. Since there won't be three 0's, this will fail.
Fix this by reducing the size by 1 and also update the comment to
make this clear and further to add that this was changed after
darktable 4.0.0.
gimp_metadata_set_from_exif has special code for handling old-style
GIMP exif parasite data, but didn't check for the more common case
of loading exif data from image formats that can't be handled by exiv2.
The exif data in these formats usually start with the TIFF endian
markers instead of "Exif", which caused a failure to read this
metadata for e.g. EXR images, see issue #10903.
We change this function to check for "Exif" at the start of the data,
in which case we assume it to be the old-style exif parasite and in
that case add extra metadata as was previously always done.
In all other cases, we do not add extra metadata.
These files are not deleted when the Unstable (GIMP 2.99) or Stable (GIMP 3)
version are installed because the root is different. So, they can be removed.
Resolves #11004
During the port to GimpProcedureDialog, the code
that assigned the current monitor object for
Windows and MacOS was accidentally removed.
This patch restores this code in the proper place.
At script create time, create a GimpRGB i.e. pixel from the declared name of default color.
At plugin procedure registration time, convert that pixel to GeglColor,
and use that color to declare the color arg using GeglParamSpecColor(default=color)
Fixes a faulty fix a few commits back where we lost the declared color name.
The proper dataflow is name->color->paramspec-with-default-color.
Extract methods related to color into new file.
So method names document what is being done.
So related code is together.
Ditto for resource.
No functional change.
Preparing for changes to reset/default and changes to representation of pixels
in lists of differing lengths rgb vs rgba.
Resolves #11003
GeglColor defaults to NULL rather than black like
GimpRGB. When selecting text with two or more colors
in the total selection, this causes NULL to be passed
to gimp_color_button_set_color () which throws an error.
This patch resolves the issue by setting GeglColor to
black if it's NULL before the call.
After the color space invasion, the
Semi-Flatten GUI was broken since it still
used GimpRGB as its color property.
This patch fixes this by porting to
GeglColor. The GimpRGB conversion was
also removed from the PDB interface
since the GeglColor comes directly from
GimpContext.
Resolves #10992.
GimpTextLayer's color attribute was
updated from GimpRGB to GeglColor,
but gimp-text-layer-set-color still passed
in GimpRGB. This patch updates the PDB
call to match the property type.
Fixes errors introduced by my prior commit c0ca0b74
1. SF is storing colors in GimpRGB, not GeglColor.
Storing using wrong pointer type seemed to work, but would not build on newer compilers.
2. spurious error message "CRITICAL....Two different plugins tried to register..."
Due to calling gimp_ui_init too early, in the class instance init.
When testing on Debian with acertain invalid PCX imagea that return
"Invalid number of bytes per line in PCX header", we get an error:
free(): double free detected in tcache 2
On Windows this doesn't cause an error, most likely due to a different
implementation of fclose.
The problem is that in case of errors fclose was called twice. Since
the file is opened outside the load_image functions, let's handle
closing also only outside that function.
In addition to that, change all g_message error notices to use
g_set_error instead, that way we always return a GError in case of an
error.
Further we also fix a possible error case of overwriting an existing
error by using g_prefix_error when the error is already set.
Resolves #10990.
Since the "mask-color" property is now a GeglColor,
we need to use gimp_prop_gegl_color_button_new ()
rather than gimp_prop_color_button_new () to
display it in the options panel.
Per @brunolopesdsilv, the About and Quit
dialogues had custom buttons which did
not receive the text-button CSS style.
This patch adds those back so the buttons
match the styling of the others in the
dialogue.
Previous pcx commit da217088d0 fixed
loading pcx images that had an off by one value for bytesperline.
However, it did not take into account that a value of 0 would be
invalid, causing a crash.
We fix this by adding a check for 0 and also failing in that case.
Since PDB now traffics in GeglColor instead of GimpRGB.
Change GimpParamSpecRGB to GeglParamSpecColor when declaring args to procedure.
Declared default is temporarily "black".
Change conversion of gvalue to scheme representation, now from GeglColor.
Incidental change to interpreter to init gegl early,
since now needed during registration phase.
Most of the C boiler-plate code is generated so that all you have to do is
implement the run() function with test code in it.
Also adding a README to make it all very clear and easy to add new tests.
With Python binding, it gets very easy to test new functions. I've been
wondering if we need C counterparts, but really since it's a GObject
Introspection binding, if a function succeeds there, it should also succeed in C
code.
For now, I'm testing a few of GimpPalette API. Not all of it yet. Also I test
both the direct C binding and PDB procedure since in some cases, one or the
other may not properly working. See #10885.
… accessed from Python.
Creating a new function gimp_value_array_get_color_array(). This should normally
not be needed (it isn't in C), but because of GObject Introspection limitation
and the fact that pygobject will automatically try to convert GValue to the
embedded value, we get this weird situation where the result is unusable in
Python for certain types. One of these types is GimpColorArray.
I suggest an annotation request to GObject Introspection:
https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/492
I think that with such annotation, followed as a second step by pygobject
support, correctly handling NULL terminated C arrays generically should be
feasible by bindings.
Resolves #10762.
Updates gimpdrawable-preview.c to use
gimp_drawable_get_buffer_with_effects (),
which includes any NDE Filters applied to
the layer in the preview.
The preview is also set to update when a
filter is applied non-destructively.
We were missing GimpColorArray support in one function. Note that the specific
example in Python in #10885 still doesn't work, but for a second reason:
gimp_value_array_index() returns a GValue which pygobject automatically tries to
transform to the contained data. And unfortunately it doesn't know about our
GimpColorArray type so we end with unusable boxed type generic data.
Since the Image Recovery dialog is blocking the main process (and requires an
answer to be done first), let's simply move down the Welcome dialog to after
this answer was given. This way, we simply won't have both dialogs in the same
time.
It was only used for the gimp-win-a64 job and was coming from MSYS2 repository
which already dropped it:
a98352b2ba
The first patch is still needed as the upstream fix is meant to appear in clang
18 according to bug report, yet our CI still uses clang 17.0.6. See:
https://github.com/llvm/llvm-project/issues/51286
Since the color space invasion, GimpRGB
properties do not create widgets anymore.
For Python plug-ins, we need to add
GeglColor properties as GObjects with
GeglColor value types as a workaround.
This patch does this and updates the
Foggify plug-in with the new datatype.
It is quite obvious that these were all kept around for the fun historical
background. And even though we can always get these back anytime through git
archeology, if these images disappear from our sight, we will just eventually
forget they even existed.
We now have a `gimp-data` repository for all data used and installed by GIMP. I
am not going to add these over there since it would go against the whole purpose
of splitting the source repository (we have too much data so we will want to
clone `gimp-data` as shallow so that it will only contain the necessary data to
install GIMP).
Yet I have created a page to reference and display all these original images
(and more! I spent quite some time researching old splashes and logos in our dev
log) for the pleasure of keeping the history of GIMP alive. It also reference
commit links for easy retrieval and further researches.
The only left images now are:
- gimp-logo.png and gimp-devel-logo.png: these are used in the About dialog or
API reference. Ideally they should be generated from the SVG source.
- gimp-splash.png: used as splash image, in the Welcome dialog and in the
Windows installer.
- wilber.png: only used in some Script-fu test scripts as far as I can see. This
should also be generated from the same source SVG as gimp-logo.png, or maybe
simply gimp-logo.png should be used instead.
Logos: https://gitlab.gnome.org/GNOME/gimp-data/-/blob/main/images/logo-log.md
Splashes: https://gitlab.gnome.org/GNOME/gimp-data/-/blob/main/images/splash-log.md
...with the Enter key. Combines the single image
and multi-image opening methods so that no matter
how you open recent images (single click, button, or
multi-select and pressing Enter), it opens all selected
images in the Welcome Dialog.
AFAIU the issue which it tried to fix only happens on custom builds and it looks
to me that it's just about multi-prefixes developer builds which were not
configured with -Drelocatable-bundle=no as they should.
When you compile GIMP yourself and intend to run it in a multi-prefix
environment, without ever relocating the build, like on Unix-like systems, then
disable this feature.
In any case, we should never do this kind of system file moving hacks in our
build system. The MSYS2 project even had to patch this out:
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1171#note_2022406
The indexed conversion code was originally written for very low-memory systems,
this makes the mapping it does quantized and noisy, for examples see issue
#5159 this commit removes quality/memory use trade-offs, modern machines can
take a 2-300mb temporary table allocation.
This is similar code to what I added for the Windows builds, except that here
it's because deps-debian-x64 will also end up feeding dev-docs job too.
Right now our tagged build of GIMP produces docs for unstable versions of babl
and GEGL.
Since !1171 we can use the CI scripts locally, but the initial implementation,
after some commits, revealed to be troublesome. So, now reworked to be simple.
As noted by Jehan, the way of defining the (many) GIMP versions can change.
So, let's take the GIMP version directly from the generated config.h file.
Also, changes the declaration of some variables to conform with "best pratices".
This list is referenced in the gimp-web-devel site, and my initial
implementation, in terms of ease to use, was a throwback.
Also, make the CI code more simple without changing the list file.
As noted in a comment on issue 10873,
choosing Selection for Fixed Gear throws
a TypeError. This is because with the change
from GimpRGB to GeglColor, we can no longer
directly access the red component with an index.
Instead, we need to call Gegl.Color.get_rgba() to get
that value, which is what this patch does.
Resolves #10882.
Before the color space invasion, INPUT_COLOR () returned
either a GimpRGB or NULL (if alpha == 0) that was used
directly in functions.
Now it's used to set a GeglColor in gegl_color_set_pixel (),
and calling that with a NULL color resulted in a Gegl-Critical.
This patch checks if INPUT_COLOR () returned NULL before
trying gegl_color_set_pixel () to prevent the issue.
The alternative solution would be to call:
> image_new_dialog_set (dialog, NULL, NULL);
This would have reset to default template. But it's still not exactly like the
"new image" action which defaults to the active image's size if there is an
opened image.
In order to avoid complicating the code further, as well as code duplication,
hence code divergence, let's call the "image-new" action, making sure that this
button will always behave exactly like the "File > New" menu item.
Then since we need to process the return value of this dialog (either re-showing
the welcome dialog in case of new image creation cancelation, or destroying the
hidden welcome dialog otherwise), I check for the singleton pointer and connect
the handlers to it.
Moreover I made the "response" signal of ImageNewDialog be handled as
G_CONNECT_AFTER otherwise we nearly never had the possibility to handle its
responses properly (because the base handler was doing it first, then often
destroying the dialog).
The rest of the time, we want to use HEAD of their main branches.
The last ctx update seem to have broken the CI build on Windows. While we'll
have to fix this, let's do this after we release GIMP.
Anyway we obviously don't want to use unstable code for actual point releases,
so it's a good thing that this made me think of adding such rules.
Use the same amount of dithering on R,G and B if they initially were all equal.
This allows us to keep achromatic gradients achromatic, while providing the
same amount of dither as before for colored gradients. Discrepancy uncovered in
issue #10756.
While the buffer used by Cairo may have a rowstride bigger than 3 * width, our
internally stored buffer has the exact size required for drawing the scale.
We were not properly duplicating the left and right colors when duplicating the
existing segments in gradient_editor_save_selection(). Therefore we ended up
freeing original GeglColor on exiting the GimpColorDialog.
Additionally to the reported crash, I add a few GeglColor freeing which were
leaked and some safeguard in gimp_gradient_get_flat_color() to ensure it always
returns a color (or raise a CRITICAL to be investigated easily).
Finally a few signals in GimpColorDialog had to be ensured disconnected when the
dialog is destroyed.
Our code expects that these GeglColor properties are always non-NULL in various
places, which may lead to crashes.
The property defaults should take care of this, and I am actually unsure why we
need to set it in the init(). Maybe the set_default() method for the GParamSpec
kicks in a bit late, while we have code syncing objects already running. I'm not
sure. It might need to be investigated later. But for now, let's simply make
sure we initialize the objects manually so that it's never NULL.
Issue #10756, without this grayscale pixels are affected by
the red part of the manipulation configuration, after this
change pixels with original saturation == 0.0 are only
changed by the master adjustment.
While doing this, I could find a lot of problems in the algorithm:
1. It looks like the original intent (from GUI and code) is that you set hue and
saturation but not really the intended lightness, rather its increase or
decrease, relatively to every pixel current lightness. I.e. that every pixel
will be set to the selected hue and saturation, and only the lightness will
change. The "lightness" field is therefore a relative value (pixel per
pixel). The first problem is that instead of lightness, we compute the
luminance, which is related but different and set this in the lightness
field.
2. The second issue is that we were using gimp_hsl_to_rgb() which after testing
(because its documentation doesn't give any TRC/space info at all) looks like
it computes a color from HSL to non-linear RGB of the same space. Yet we were
outputting to a linear RGB space. So we compute the wrong values. On the
other hand, because of the first problem, I realize (after testing) that it
makes our render closer to the intended render by chance (at least when the
TRC is sRGB's). It's still wrong, but if we were to change the output to
"R'G'B'A float" instead, the render would be much darker. In both cases, it's
wrong anyway.
I would not say that the 2 problems are canceling each others, but they are
making the final result somewhat OK.
3. Ideally we should be using babl to convert colors, and this is the best way
to actually implement the original filter intent. Unfortunately so far, doing
this is much slower (though I save a lot of time by moving out of the samples
loop and processing data in chunks, it's still slower than the current,
nearly instant, implementation).
4. Because of all previous implementation irregularities, the render is
different depending on the actual image space. I.e. that the exact same image
filtered through Colorize with the exact same operation parameters will
render differently. I would need to test further, and maybe it's normal since
HSL is also space-dependant (and that's where we work on in this operation),
but I'm wondering if the result should not be independant of the working
space.
5. I implemented our own prepare() method because the one in
GimpOperationPointFilter parent seems to allow other input or output models.
Even though in all my tests, it was always linear RGB (which is what we want
here), let's make sure by having a custom prepare() method explicitly setting
these. It's also the opportunity to create some babl fishes.
In any case, I'm leaving the code as-is for now, because it's how this operation
has been since forever (at least for as long as I was around) and I don't think
it's the right idea to change it on a whim.
This raises even more the concern of versionning GEGL operation, which we have
been discussing with pippin on IRC lately, because if ever we want to change
this one, now that operations are not just applied, but possibly
non-destructively recreated at load, we need to make sure that we recreate the
render expected at the time of creation of a XCF while allowing us to have the
filters improving when needed.
Resolves the main part of 10835. As nothing else can
be done in the GUI once all the filters are merged down
(and the GUI itself will be unavailable once closed until
a new filter is added), it makes sense to auto-close it.
gtk_widget_set_visible () was used rather than
gtk_popover_popdown () due to notes in the code about
buggy animations.
There is the possibility that users may want the GUI left
open to quickly undo the merge, so this should be
re-examined after feedback from the 2.99.18 release.
To reflect increased generality, its not just "coffee" but any gradient.
Delete "realistic looking": subjective and adds no content.
Better tooltips for the arguments.
Fix it by also enhancing, making the gradient an argument with a default
instead of a fixed choice of the gradient named "Coffee".
Instead of fixing by looking up the gradient ID in the body of the script.
Right now, I just transform any GeglColor return value into a RGB u8 triplet,
because that's also how we were supporting GimpRGB anyway, though it's seriously
limited.
Ideally we'd add some real concept of generic color abstraction in Script-fu
too, which could support any color model, space and precision.
Resolves #10848.
In cc62f2b0, we moved the filter property loading code
earlier in the process. However, the opacity, mode, and
region options for GimpFilterTool were not included in
this move, so they reset back to defaults each time.
This fixes that problem so settings are retained when
editing.
Resolves #10830
The supersample-max-depth parameter
of gimp-drawable-edit-gradient-fill
required a value between 1 and 9.
Previously this wasn't enforced, so several
scripts called it with a value of 0.
Now that it's enforced, those scripts were
broken. This fixes the calls in weave,
gradient-example, test-sphere, burn-in,
and coffee (although it has other issues)
It was a bit sad that we'd release GIMP 2.99.18 with no plug-in using
GeglColor argument yet, so at least with this, we'll have one as a demo
of what needs to be done.
- Make sure the led color is set at init().
- Unlike old GimpRGB code, values' colors must be set explicitly first.
- Make the Gimp object into a property (this one is not a problem right now, but
it's better this way).
- Don't assume the Gimp object is non-NULL. In current code, it is set to NULL.
The only consequence is that we don't use color management settings to draw
with Cairo. For this widget anyway, it feels unnecessary.
Altering the Warp tool's GEGL filter while it's being actively edited
causing a crash. More work will be needed to make these effects
work non-destructively - for now, we'll prevent users from raising or
lowering them from the NDE UI.
To simplify the logic, I created an `is_update` variable. This makes the code
much more understandable (and also simplify the redundant or over-complicated
imbricated `if` blocks).
The fix part is that the update check would have never happened for anyone
leaving the "Show Welcome Dialog" option checked, whereas we only want to bypass
the update check for new installations or updates.
Allows users to quickly configure themes and other
"controversial" options when first installed.
Also allows the welcome dialogue to appear on start,
depending on user preference.
… (u8), or CMYK is selected.
We always need a final NUL indicator in a GStrv. In these 2 cases, we might fill
all 6 first indexes, so we must have an array of size 7.
Since resources must now either belong to an image, or be tied to a file, or be
marked as internal, we must immediately save imported palettes, so that they are
tied to their file.
For the time being, only the same format as GimpRGB params is supported, which
means creating a color either as CSS strings or as RGBA list values, which means
that we can only input sRGB values right now in ScriptFu (even when calling
GeglColor-using API).
This is the second part to fix issue #10811.
Though I had already implemented passing GeglColor through the PDB, it was not
complete. In particular, the protocol was not able to pass GeglParamColor specs.
Fixes:
> LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor'
This is part of the fix to issue #10811, though it's not complete yet.
Clicking on the Save button threw an exception as the wrong class was
used to invoke the `set_alternative_button_order_from_array()` method.
Since `Gtk.Dialog.set_alternative_button_order_from_array()` is
deprecated and the GIMP functions with the same name suppress
deprecation warnings in the C code, we suppress the warning here as
well. The `warnings.catch_warnings()` function is not thread-safe
according to the Python documentation, which should not pose a problem
here.
Also, the file chooser dialog now allows specifying a new file instead
of overwriting an existing file.
The current values_cmp() method will segfault if an object contains a NULL
GeglColor value. I fixed it in commit c0477bcb0 in GEGL, but since the GEGL
release is already done, I add this special-casing on GIMP side.
To be removed when we release and depend on GEGL 0.4.50.
The crash was happening when activating the text tool and raised in a comment of
another report: https://gitlab.gnome.org/GNOME/gimp/-/issues/10813#note_2009702
When changing the selected color, we have no reason to redraw the Z preview.
This preview should only be redrawn if the allocation size changed, or if we
change the previewed model or the Z component.
As for the XY preview, it should only be redrawn if the Z value is changed (and
of course, similarly, if the allocation changed or if model or Z component
changed).
With "HSVA" and a few others, the function was not returning the right value (it
could not see it was encoding alpha channel.
I had fixed it on babl directly with commit a28309c yet I had forgotten to push
it! Let's just add some #ifdef and a comment.
No custom conversion code anymore. This also fixes some bugs in HSV when
I was wrongfully multiplying the hue by 360 when mixing babl and custom
code paths.
It's actually not enough to get proper colors for inner text tags. The
main color is correct, but color for subtext is currently not managed.
This must be fixed.
In particular, the Curves, Levels and Operation tools method implemented
are updated. Also GeglColor arguments in GEGL operations are not
transformed into GimpRGB arguments anymore in GIMP. GeglColor GParamSpec
stay GeglColor now.
We don't try anymore to convert early from a pickable color to another
format/space. Now we are able to get a GeglColor and move it around,
doing only last-second (when needed) conversions.
I'm a bit unsure about the GimpMyBrushCore which doesn't have much
indication on which color space we are working in, but the new code
should not be worse than the old one (if wrong, color-wise, it should be
the same wrong as before).
Until now we only had the case of the CMYK color selector using the
soft-proofing profile. Yet this is also interesting for other color
selectors, in particular to show out-of-gamut colors. Indeed if we
enable soft-proofing on the active image, it is interesting to show the
intersection of the current RGB/Grayscale space gamut with the
soft-proofing gamut.
Right now, this is only used in GimpColorSelect when showing colors in
LCh color space.
This is used for the gimp_color_is_perceptually_identical() function,
because the Euclidean distance in LCH is extremely limited, if not wrong
in many cases. Indeed LCH is not perfectly perceptually uniform, and for
this exact reason, the CIE defined the specific Delta E algorithms.
Later versions are also based on LCH values, so my intuition to use it
for distance was on a good start, yet these algorithms were refined a
few times to allow for corrections in perceptual uniformity
imperfections.
This was in particular needed to verify if a color is out of a CMYK
space gamut. The idea is to compare the distance of the RGB (or other)
and the CMYK version, since we cannot just check if the CMYK color is
out of the [0; 1] range (it never is). Instead if both colors are
perceptually identical, then we consider that the RGB color was inside
the CMYK space gamut.
The naive algorithm was giving any (or nearly) color as out-of-gamut.
Now using CIEDE2000, I get a much nicer results.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
Only the color dialog was getting simulation updates when the active
image changed, or when the simulation profile changed (while the active
image stayed the same). Now the Colors dockable also get updates.
Somehow, in some cases, the event box is not getting button events. I
had the case when creating new images (though it was working fine when
loading images!). I could not yet understand the issue looking at both
GIMP and GTK code and could not even reproduce by creating simple code
sample reproducing a similar pattern (an inactive button inside an event
box placed above the button and meant to catch click events).
This works as a workaround for the time being.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
I also changed a bit the new color serialization by adding a (color …)
symbol framing the contents, for cases where we don't have a specific
property name, e.g. for the color history list stored in colorrc, unlike
for GimpConfig GeglColor properties.
While doing this, I moved GeglColor property deserialization code into
gimp_scanner_parse_color() which is now able to recognize both older
(color-rgb|rgba|hsv|hsva with no color space) and newer serialization
formats ("color", color model agnostic and space aware).
Serializing palette colors is not possible right now as far too much
additional data are required, and anyway we likely wouldn't be able to
associate back the color to the right palette on deserialization,
removing any interest of keeping the index data anyway.
With that context in mind, let's just serialize palette data as basic
RGB within the palette's space.
- New libgimpcolor functions: gimp_color_parse_hex() and gimp_color_parse_name().
- GimpColorHexEntry is now space-invaded. Though recognized color names
and hexadecimal syntax are sRGB only (because CSS and SVG
specifications explicitly say that this syntax is for sRGB values), it
is possible to enter non-sRGB values with
gimp_color_hex_entry_set_color().
- GimpColorSelection is now space-invaded.
We historically have both the colormap and palette concept in core GIMP,
though they are actually kinda the same concept, except that with
"colormap" we work with an array of raw data and it's a lot less
color-aware. It is still much more efficient in some specific cases,
such as when converting the image (we can then convert the whole palette
as a single buffer, because the image palette is space-restricted
anyway), when storing undo data or when storing/loading in XCF.
But for all the rest, let's use gimp_image_get_colormap_palette() and
work with the GimpPalette API.
By default a palette can contain any mix of color models and space. These new
internal API add a concept of format/space restriction. For now this will only
be used for indexed images whose palette should only contain colors for the
specific palette format and space (at least as currently implemented in GIMP).
I still see some limitations in GimpGradient, and in particular, they are still
always stored as RGB in GGR files. It would be nice if we could store the actual
color format. This way, if someone chooses a gradient stop as Lab or CMYK color,
that's what the gradient file would keep track of. But also even storing the
space of a color (instead of storing/loading always in sRGB, even though this
may still work fine as we store unbounded double values). This might warrant for
a v2 of GGR file format.
This commit also fixes loading of SVG gradient which was apparently broken
regarding hexadecimal color parsing.
Finally I improve gegl_color_set_alpha() by adding an alpha channel when the
initial format had none.
The invasion extended to some core widgets too, in particular GimpColorPanel (a
subclass of GimpColorButton). There was quite a lot of code depending on these
widgets.
This includes improvements on the out-of-gamut colored corner being shown for
unbounded component types out of the [0; 1] range (with some small margin of
error to avoid e.g. a -0.0000001 value to show as out-of-gamut).
There are still improvements to be made on the color rendering. In particular,
it still draws as CAIRO_FORMAT_RGB24 cairo surface. We should probably move to
draw as CAIRO_FORMAT_RGBA128F eventually (more precision and even allowing to
draw unbounded colors with a possible option, instead of always clipping).
Also adding the libgimpwidgets API gimp_widget_get_render_space().
This one is kind of a huge deal, because the info returned by the color frame
was kind of messy (even though it improved lately, but space associated to color
data had to be kept in-sync by hand, which was bug-prone).
Now the color frame stores the data as a GeglColor, always aware of its space
and therefore able to do much nicer conversion. Also RGB and Grayscale options
now display the profile name of the color space (until now, we had only this for
the CMYK option using the proofing profile).
I still wish to get more options. Typically some people may want to get
RGB/Grayscale/CMYK values to other spaces (maybe sRGB, one of their favorite
profile as set in Preferences or just any random profile which they could load
from disk). Giving such ability to basically live-convert their pixel data to
various other color space would be very nice. We'll see if this will be
implemented for GIMP 3 or for after.
- New function gimp_cairo_set_source_color() which is meant to replace
gimp_cairo_set_source_rgb(a?)() eventually. This new function sets the Cairo
source color, using the target monitor's profile of the widget where the Cairo
surface is meant to be drawn on. It also uses the color management settings
(such as whether a custom profile was set, instead of using system profile, or
also simply whether color management was disabled at all). It doesn't
soft-proof the color yet.
- Padding and out-of-gamut colors drawing now use the new
gimp_cairo_set_source_color(). These don't need any soft-proofing anyway.
- Out-of-gamut color property in GimpColorConfig is now a GeglColor property.
We pass 2 GeglColor through the wire now. Since it is passed very early
(when sharing the configuration), I had some issues with initialization
order of GEGL, and in particular when calling gegl_init() before
gegl_config() inside _gimp_config(), I had a bunch of such criticals:
> Plugin script-fu: GLib-GObject: CRITICAL: Two different plugins tried to register 'GeglOpPlugIn-transform-core'
Anyway in the end, I store the passed colors as raw bytes and strings in
the GPConfig object, and re-construct the GeglColor last minute in
_gimp_config().
This fixes weird behavior when changing only the alpha value of a color, e.g. in
the channel color GUI. The before and after colors were considered the same. Now
they won't.
In particular, let's accept small margin of errors to determine that a value is
out of the [0; 1] range of its color space.
The specific use case is about a component at -0.000001 (or at 1.000001) which
will even just show as 0 (respectively 1) in the GUI and will be marked as
out-of-gamut. We want to avoid such thing to happen.
I also took the opportunity to get rid of a bit more GimpRGB code.
One of the big improvement in this commit is that text layers are now much
better at space accuracy. They were already space-aware, yet rendered as sRGB u8
only before being converted to the image's space. It means that text layers had
the following limitations:
* Any color out of sRGB gamut were trimmed.
* Precision was always 8-bit (even if the image was high-bit depth).
Now GimpTextLayout keeps track of its source space (for RGB and CMYK only, this
won't be as easy when we will support more backend, since Cairo has only RGB
support for image data) and the image TRC (in case it bypasses the color space's
TRB) and it draws within this gamut and space.
It means first that we are not limited to sRGB colors; we will draw text main
color in the full image gamut, with still 2 remaining limitations:
* Unbounded colors are impossible because Pango format (to color text) uses
hexadecimal (so even with half/float images, you can't draw out-of-gamut text
unfortunately).
* Main color precision is still 8-bit, yet a tiny bit better than before as we
at least follow TRC (so we avoid some of the precision loss when converting,
even though the bit-depth is still the biggest loss).
The outline color on the other hand is drawn through Cairo API entirely, in
float. This means that the outline color will now be without any precision loss.
Note that this depends on CAIRO_FORMAT_RGBA128F which is only available since
Cairo 1.17.2 which is not in Debian bookworm (our current baseline for GIMP
3.0). It means that the old precision will still happen with older Cairo
version, as determined by #if code at compilation.
I moved the function to select a valid contextual RGBA format as a core API
gimp_context_get_rgba_format(). This same API is now used in context actions, as
well as in the GimpDeviceStatus widget.
The latter now shows per-device fg/bg colors relatively to the active image's
format. The tooltip will also display contextual information (i.e. either the
image's name whose space is used, or sRGB).
Of course, this all updates when switching images by connecting to the
image-changed signal.
In space invasion world, we want color-related code to be contextual. When we
say "Increase/Decrease the red/green/blue channel by X%", it would actually mean
something different if you are working on a sRGB space or a wider gamut space.
Furthermore, it means also something different if you work on linear/perceptual,
overriding the space's actual TRC.
This is why this new code takes the active image into account and uses this as a
base for the space and TRC you are working on. In case you have no active image,
it defaults to the current GeglColor space (though really this case should not
matter too much). In case your image is not RGB to begin with, it uses sRGB
space.
Some old config files will contain (color-rgb) contents. Also some data, such as
historical tool presets (.gtp files) will have such values in their
(tool-options).
- app: gimp_context_get_(foreground|background)() are now returning a GeglColor.
- libgimp: PDB functions named similarly in libgimp are returning a newly
allocated GeglColor too.
- A few other PDB functions (the ones using these functions) were updated and
their signature changed to use GeglColor too, when relevant. Plug-ins which
use any of the changed libgimp functions were fixed.
- GimpContext: signals "(foreground|background)-changed" are now passing a
GeglColor.
- libgimpconfig: new macro GIMP_CONFIG_PROP_COLOR using gegl_param_spec_color().
- GimpContext: properties "foreground" and "background" are now GeglParamColor
properties.
- app: All code interacting with GimpContext objects were updated to receive a
GeglColor (that they may still convert, or no, to GimpRGB for now).
- app: gimp_prop_gegl_color_button_new() was added as an alternative to
gimp_prop_color_button_new() when the property is a GeglParamColor. Eventually
the former should replace completely the latter.
- libgimpwidgets: gimp_prop_color_area_new() now works on GeglParamColor
properties only.
- libgimp: gimp_procedure_dialog_get_widget() will generate a GimpColorArea for
GeglTypeParamColor arguments.
Also the color is internally stored as GeglColor, though there are still get
APIs and signals using GimpRGB.
The equivalent PDB functions are also changed to use GeglColor, same as app/
functions.
… gimp_color_is_perceptually_identical().
gimp_color_is_perceptually_identical() is meant to replace gimp_rgb_distance()
which is anyway always used to decide whether 2 colors can be considered equal.
So rather than having a distance algorithm which we won't be able to change
later on (if people start relying on specific values), let's just give the
answer directly on what's a same color (perceptually) or not.
Also now the distance is computed through the intermediate color space LCh which
seems to be one of the most perceptually uniform space, therefore a good choice
for such an algorithm (comparing distances on a non-perceptual uniform space
doesn't make very much sense, since a same distance may be perceived differently
in different subspaces).
This is a first commit to really getting rid of GimpRGB within core and
PDB/plug-in code. This will make color conversion reliability a lot better as
GeglColor will handle conversions for us. The goal is that we should keep origin
color space (for instance when picking colors in a GimpPickable, or when storing
in the FG/BG colors or in paletters) until the last second and convert at use
only.
It's still very much work-in-progress.
These 2 functions were removed in commit 89c359ce. They were in fact used and
clearly this historical API seems interesting (though we can likely do the same
thing using the drawable GeglBuffer, but this way is much easier).
This is now reimplemented using GeglColor instead of raw data.
Eventually this is meant to fully replace GimpRGB (as well as GimpHSV, GimpHSL
and GimpCMYK), both in libgimp and in core code, as part of both the space
invasion and the API rework. For this first commit, I keep this new object side
by side to GimpRGB.
gimp_drawable_filter_apply () is affected
by the active selection. This causes display
glitches when merging all filters or
undoing a merge while an active selection
is on the image.
This patch saves the current selection,
clears it, merges/unmerges the filters,
then reapplies the selection to avoid the
problem. In the future, this should be
re-examined (when filter masks can be
edited).
Resolves #10802.
Since the GimpProcedureDialog port, the Windows version
of the Screenshot plug-in has been missing the
"Screenshot Delay" option. This is because Windows did not
have the SCREENSHOT_CAN_DELAY_WINDOW_SHOT enum
set. Adding that back in restores the option.
Here, the instructions was hard to find in the middle of maintainer stuff.
Also, be able to build GIMP without dev-oriented distros is something very
desirable, and the gimp-web-devel is the suited place fot it.
Resolves #10736.
By default, any filter added with a drawable with
gimp_drawable_filter_new () will be added on top
of the filter stack. Now that we have NDE effects,
there can be multiple live filters when drawing.
The Warp tool applies a GEGL operation as well,
and now it draws on top of any existing effect.
This patch adds code to move the Warp's filter
below any other NDE effects so it operates on
the raw pixels only.
Note that a longer term solution might be to have
a separate stack for tool-based GEGL operations,
but that would be a post 3.0 discussion.
- The icon itself was changed to a "search" icon. Though it kinda made sense to
keep the "link" reference when I first implemented this, as a reference to how
we used to link items (whereas now we select them together), in the grand
scheme of things, it's not such a good idea and many won't likely understand.
But everyone will understand a "search" button. :-)
- It's now next to the label displaying the number of selected items, in the
item tree view header. This makes much more sense there. Also it makes the
long list of bottom buttons slighly shorter.
- Finally I make this feature accessible to the channels and paths, by actually
moving it out of GimpLayerTreeView and into GimpItemTreeView.
Certain filters like Supernova have a
random seed property. According to the
specifications it's an unsigned int, so we
can save and load it with existing
functions.
Aaaargh! I think this was the main issue which would explain why the problem was
mostly happening on the packaging job. In this job, we were still consistently
calling `pacman --noconfirm -Suy` (i.e.g "Synchronizing package databases")
which we had stopped to do for the CI builds as that was highly increasing
chances of locking pacman's process.
This is the command suggest by MSYS2 developers here:
https://github.com/msys2/MSYS2-packages/issues/4340#issuecomment-1887695290
They also say to run it outside the MSYS2 environment, which is why it's in the
CI rules, not in the shell script.
Honestly at this point, it feels like we are just stacking weird workaround to
get it to fail not too often. ;-(
Fixing a case where the script continued after a failed `ninja`. After further
testing on how `set -e` works, it looks like a toplevel `false && true` command
will fail the script (which is what we want), but it won't when inside an `if`
block!
Breaking it down into 2 separate calls fail the script correctly though. So
let's do this.
MSYS2 pacman gets randomly stuck on Windows/Aarch64. The actual issue is still
being investigated by upstream projects, though anyway it's bad for us right
now, to the point that there are discussions to remove Aarch64 support from the
Windows installer (whereas it just got added recently!) in #10729.
This is an attempt to a workaround. Instead of getting stuck forever and waiting
until the whole job times out (per Gitlab CI settings), I time-out (after 3
minutes) the pacman command within our script and try again, up to 2 more times.
Hopefully one of the calls would succeed.
I also send a SIGKILL through the timeout (though I have no idea how signals
translate to Windows processes) and run again taskkill after this, which may
seem overkill. Interestingly I get output for both, which seems to indicate that
the kill succeeds in both cases (because of several processes?).
Anyway clearly it's a bit of random code not completely understood, but the
inability to test this all locally clearly doesn't help so it's good enough for
the time being.
See: https://github.com/msys2/MSYS2-packages/issues/4340
Resolves #10769.
Flattening an image or merging down layers caused
us to lose NDE filters on undo, as we flattened with
gimp_gegl_create_flatten_node () which didn't create
an Undo/Redo object.
To fix this, we merge the filters down beforehand with
our API so that they will be restored when undoing.
Resolves #10768.
During NDE development, the Show/Hide All
function name was changed. This was not fixed
in one location where we blocked it during popup
creation, so the signal was running on dead objects.
This patch fixes this. It also fixes a few formatting
errors made during NDE development.
Two shell commands got merged as one line. This seems to work fine on
hmartinez82's runner, unlike on our new runners. Anyway it is likely good
practice to clearly separate the commands.
Fixing:
$ if ($stuck -eq "True") { Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck" Write-Output "Cleaned previous stuck pacman" }
Remove-Item : A positional parameter cannot be found that accepts argument 'Write-Output'.
At line:279 char:26
+ ... q "True") { Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Remove-Item], ParameterBindingException
+ FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand
Resolves #10766.
Currently, GIMP does not support applying or editing
filters when the layer is pixel locked. This patch
prevents users from attempting to edit filters via the
NDE popover UI, and notifies them of why.
If any NDE filter is hidden when merged, the entire layer
is hidden. This patch changes the behavior so that the
invisible filter is removed instead of committed when
merged down.
Without this, when creating the new config folder for the first time
(update from 2.10 to 2.99/3.0), if say "Legacy" icon theme was set, it
would not show on the first run, though it would show on the second run.
Now it shows directly on the first run.
After ab626e79, Script-Fu v3 now has the
SF-OPTION parameter again. This patch
ports a few scripts that use it or were
not otherwise covered by other merge
requests.
Note that further improvements are
necessary to allow these to work on
multiple layers simultaneously.
For version 3 scripts, using script-fu-register-filter
Widgets for SF-OPTION and SF-DIRNAME
Fixes #9992
Test case is Sphere v3.
Note that SF-VECTORS is still not supported,
until there is a VectorsChooser widget in libgimp.
A step towards deprecating old-style scripts using script-fu-register,
and deleting script-fu-interface, the duplicate dialog for SF.
But we still need to change or replace script-fu-register (for non-filter plugins)
to use GimpProcedureDialog.
Some GIMP-custom GEGL operations do not use GimpConfig to
store their properties (for instance, Threshold).
Previously, we weren't copying over their values when editing an
NDE filter.
This patch adds code to copy over the Gegl properties if there is
not a GimpConfig object attached to the filter.
In particular in a cross-compilation environment where you don't have an exe
wrapper or cross-host run ability, you still want to be able to configure GIMP.
It is also possible to install lua scripts anyway with -Dlua=enabled, bypassing
ability to test lua-lgi presence (a warning will be outputted at configuration
time, but no error).
While this is the job of `set -e`, putting parts of the script in shell
functions hid error returns in the build-deps-msys2 script.
Cf. #10729.
For the build-gimp-crossroad script, let's just add `set -e`.
Cf. #10725.
I believe there is a real use case for darker or lighter themes, but this
particular theme is not particularly maintained and has no light variant (or to
be accurate: the light variant is just a link to the "Default" one). If someone
is interested in such themes, we'll welcome contributions to revive a new theme
which should have at the very least both a light and dark version, and we could
name it "Contrast" (rather than "Darker" which focuses on a dark variant only).
I think it's better to do it this way rather than releasing with a half-done
job.
The Compact theme code is nearly the same as the Default one, apart from setting
palette icon size to small (which is already something done by the "Override
icon sizes" setting in Preferences), setting font-size to small (which can be
independently set by our "Font Scaling" setting) and setting 3 paddings.
Rather than having this separate theme, it feels like just moving the padding
changes as part of the icon size makes sense. In particular since, when setting
icons to "Small" right now, the default padding really feels a bit huge and out
of place. So all-in-one seems a better choice.
At first, I wanted to set a padding proportional to the icon size, but it didn't
work well. For now, I'll just choose padding sizes manually.
If you run the GEGL Operation tool without choosing
a filter, it leaves a "gegl:nop" layer effect behind.
This is not useful, so we check and set such filters as
destructive to get rid of when applying an effect.
This was provoking a CRITICAL in #9712, in the GimpFgBgEditor which was tracking
the active image, but even before this, I experienced a crash in
GimpLayerTreeView code with the same steps.
The problem is that in some cases, the image switch happens once the currently
active image is already disposed. In particular we had the case in multi-window
mode where closing a window would free a GimpImage yet without necessarily
setting another image as active, since it depends on window focus in MWM (and
the other image windows may not gain focus immediately; this depends on the
window management logic).
Therefore we had various handlers in Gimp*TreeView (or GimpFgBgEditor and
possibly other places) code which tried to disconnect or work on now freed
pointers. To handle such case, let's connect to image finalization and set the
context to NULL image.
When working on #9712, I encountered this crash first before the main issue
(with the same reproduction steps as listed by Wormnest): reason may not be set
by the method. It's better to always explicitly set this variable to NULL first.
The current GTK algorithm for finding an icon seems to be:
main icon theme in choosen style > fallback icon theme in choosen style >
main icon theme in another style > fallback icon theme in another style
Where "style" is either color or symbolic variant of a given icon. The problem
is therefore if say your prefered style is "Symbolic" and you choose a
Color-only icon theme. In such a configuration, all icons which are also
available in the system theme with a symbolic variant will be used from the
system theme (even when they are actually available in the chosen icon theme
too, yet in a color variant) and you get a weird mix of part of the icons as
symbolic from system theme and another part as color from the chosen theme.
In order to avoid this weird situation, we only set -gtk-icon-style CSS value to
the prefer-symbolic-icons property if the chosen icon theme has both style
variants. Otherwise we force the only variant of the chosen icon theme.
The icon "gimp-wilber" is used to determine whether an icon theme has both
variants, which should be documented in the developer website for icon theme
makers.
The -Dlua option has 3 cases:
1. disabled: lua plug-ins aren't installed at all.
2. auto: lua plug-ins are only installed if we find a lua installation
with access to the 'lgi' module. We now do the actual test at configuration
(not only lua existence test, but also lua-lgi).
3. enabled: lua plug-ins are always installed but if no lua installation with
'lgi' module is found, a warning is displayed at end of configuration step.
Add tests of context stack ops.
Add test of paint methods.
Test convert to all precisions.
Test paint dynamics.
Test PDB as database.
Test PDBProcedure methods.
Test display methods.
Test drawable operations.
While the script is made aware of multiple selected layers,
it still only works on the top selected layer.
Mnemonics were also added to the GUI fields,
and an unused "type" parameter was removed.
The list contains, in addition to the GIMP deps, all babl and GEGL deps.
So, let's use it.
Also, nothing new under the sun. We already use a unique list on the
Windows build instruction page (for stable branch) and do the same to
Debian image job.
The merged icon theme is simply named "Default" and contains a color and
symbolic variant for all icons. While in 2.10, it made sense to have both icon
themes because a theme had no concept of a "symbolic" variant back then, icon
themes in 3.0 have this concept and we support this in GIMP through the "Use
symbolic icons if available" option in Preferences.
Until now, it was confusing to have both themes + this option, even more as you
could use the Color icons with the "Use symbolic icons" option, which meant that
if some icons were missing, you could end up with a mix of color and symbolic
icons (and oppositely using the Symbolic theme with the option unchecked).
The new state is much simpler and less confusing. Just 1 icon theme with both
color and symbolic variants (the latter being used by default).
Note that the identical meson.build in each size subfolder is still mandatory
because of the inability of meson (still!) to generate files with
custom_target() in a subfolder as output.
We were skipping tests when there is no display, which is always the
case on Windows. However, these tests always showed as succeeded.
Unless you looked at the test log, you wouldn't noticed that most of
the tests weren't actually performed.
Exit these tests with the value GIMP_EXIT_TEST_SKIPPED instead of
EXIT_SUCCESS.
You are not supposed to use g_assert in tests because g_assert can be
disabled using -DG_DISABLE_ASSERT, which makes tests fail.
Instead let's use the recommended replacement g_assert_true. At this
time we are not bothering using more specific g_assert_* functions,
since there are plans to change our test suite.
gimp_config_writer_printf () is used to print out a gsize variable, data_length.
gsize's actual size varies depending on platform, so using the format "%lu" throws
a warning on some platforms and switching to "%llu" throws a warning on others.
@Wormnest suggested ("%" G_GSIZE_FORMAT) as a universal format to resolve
this warning.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
Chooser return GDK_EVENT_STOP so parent manager does not also popup second menu.
Specifically, return the result of the call to gimp_editor_popup_menu_at_pointer.
When a menu does pop up (for a dockable), that result is GDK_EVENT_STOP
and the event does not propagate to the parent widget.
Added a comment about why we ignore the result of a call
to gimp_editor_popup_menu_at_pointer in another place,
since it is not obvious why that call is different.
All other current behavior retained.
Other current behavior might be separate issue:
LMB or RMB outside any item, or in the current selected item,
in the chooser that popups from the toolbox,
should probably close the popup chooser, or give an audible alert,
because it does nothing.
Note that a chooser is also used in a remote dialog for a plugin,
and it closes a different way, choosing an OK button.
MINGW64
- uses 0x601 as value for _WIN32_WINNT. No need for us to define
it to that value or even lower values in some places.
This also gets rid of: warning: "_WIN32_WINNT" redefined
- has 0x0502 for WINVER, so get rid of us setting it to 0x0500 in
gimp-app-test-utils.h. It also seems that the need to use G_OS_WIN32
has disappeared here.
- DIRECTINPUT_VERSION is 0x0800, no need for us to set it to that value.
- AI_ADDRCONFIG was apparently missing from the MINGW headers in the
past, but not anymore.
The list of objects where the config object is a dedicated custom class (instead
of a runtime-registered class) is well known. These are the operations
registered inside gimp_operations_init().
The list inside gimp_gegl_procedure_execute_async() which the previous commit
was updating was not right: it was still missing "gimp:hue-saturation" and
"gimp:threshold" should not have been on the list (this was generating a
CRITICAL when trying to get the "config" property on this object).
Instead let's add some init/exit() functions in gimp-operation-config API to
distinguish the operations with custom config (registered during init) with all
the others. Then we add gimp_operation_config_is_custom() which can be used
everywhere where we want to verify if an operation is using a custom-made config
object or a generated class just mirroring the operation properties.
This way, we should not get out-of-sync anymore.
Adds gimp:color-balance to the list of
GIMP-specific GEGL operations we
retrieve the GimpConfig settings from.
Also prevents trying to set a GEGL
property when editing if it couldn't be
converted properly (e.g. GimpConfig)
Now that we save GEGL operation arguments ourselves (instead of relying on
GEGL-generated XML), we can serialize and deserialize GimpConfig arguments which
are used in various operations implemented within GIMP core code.
Additionally:
- Also support saving and loading all enum types.
- PROP_EFFECT_ARGUMENT renamed to PROP_FILTER_ARGUMENT for consistent naming.
- A bit more accurate handling on save and load errors with dedicated messages
to various issues.
- Use PROP_FLOAT_OPACITY instead of the obsolete 8-bit PROP_OPACITY (actually
32-bit but stored as 0-255 int).
- Fix a leaking string.
*It's possible to have one layer selected but edit the filter of another layer.
The FilterTool code was updated to use the filter's drawable if editing.
*Prevents editing if multiple layers are selected.
This is a current limitation of the filter tool itself, but it was causing issues with NDE.
*If an XCF with a filter from a third-party plug-in is loaded, the filter won't be
created if the user doesn't have it installed.
Note that GEGL still throws a lot of warnings about missing properties - not sure how to resolve that.
*Refresh drawable when finished editing a filter to fix issue with lingering preview splits
*Fix issue with loading more than one filter after XCF format changes
- Do not leak allocated return value of gegl_node_to_xml_full().
- When merging layer effects, use gimp_drawable_filter_commit(), making
sure we use the exact same code path as when applying layer effects
destructively from the start. This also ensures that filters are
properly removed from the filter stack (unlike
gimp_drawable_merge_filter()), which was the reason why the rendering
was wrong (hence getting the buffer without effects first, then
reapplying it after was only a workaround to an actual bug).
- When removing a filter, verify the object still exists before doing
anything with it. If this was the last reference, we don't want to
call functions on this object. In gimp_drawable_filter_commit(), we
set up a weak pointer. In gimp_drawable_filter_remove_filter() itself,
we save the pointer to the filter's drawable before actual removal (as
we don't want to dereference a freed object later on).
- export_merge_layer_effects() should merge filters recursively through
layer groups.
- clean up the XCF code:
* No need to wrap the effect pointers list into 2 zero offset. Only
have one zero offset to indicate the list end.
* Add the layer effect mask in the effect structure (not in the layer
structure), similar as for layer masks.
* Effect name and icon made as main data in the structure, not as
properties.
This patch implements an initial form of
non-destructive editing. Filters now stay active
instead of being immediately merged down.
A new column is added to the layer tree view, which
can be clicked to show a pop-over menu.
Filters can currently be hidden/shown, edited, reordered,
deleted, and merged down from this pop-over menu.
Currently, this works on layers and layer selections only.
Plenty of room for improvement!
Use g_signal_connect_object to ensure object passed to handler
is not destroyed in the middle of the handler by knock-on signal handling.
Note there are comments about this in gimpcontainertreeview.c line 1592.
And similar code i.e. calls to gimp_container_view_get_container
that seem to be intended to solve but might actually also be susceptible.
Those calls in icon view throw CRITICALs during this issue.
But testing of the tree view (a list instead of a grid)
doesn't seem to crash, so leave well enough alone.
As suggested by Jehan, the manifest will be configured by meson.
Of course, for CI compliance, this pushes the job to a further stage:
'packaging', which is what Flatpak is about, after all.
The distribution job name has also been changed, because when Store job
is merged, this will be the new nomenclature of the distribution jobs,
which was not changed since !1171 by lack of time.
Per @lukaso, the "rightwards triangle arrowhead" character
doesn't render on MacOS. This patch uses a different character
for MacOS only until a standard character can be decided on.
There is no point in keeping .patches in our source since we aren't applying
them and there are "backup" MRs in GTK: GNOME/gtk!3275 and GNOME/gtk!4432.
Resolves #10657.
d120e592 fixed a crash when pasting into an empty image.
However, it created a new issue when pasting into a layer mask.
It caused a later call to gimp_drawable_convert_type () to fail, as
the pasted image would not need to be converted if the image's
settings were used rather than the drawable.
This patch fixes both issues by checking if the selection/image is empty,
and assigned the base type and precision values from either the selection
or the image accordingly.
Resolves #10651
The "Remove All Guides" script calls
gimp-image-find-next-guide, which per
its description can take in 0. However,
the parameter sets 1 as the minimum
value.
This patch fixes the range so that it can
accept 0, which enables the Remove All
Guides script to work again.
It also updates the script to the new
multi-layer aware API.
- Drops HACKING file (it is outdated and we have the "same thing",
updated, in the devel site), but moved PDB content to the README
* Update various links now to the devel site
+ Added 'TODOs' to avoid confusion from titles with empty content
and removed some that are already implemented
Now, the script reads the major.minor version automatically from the main
meson.build file, reducing maintenance work, which is already especially
high regarding flatpak because of the natural hashes updates etc.
Also, a small organization made to make the code more humanly readable.
As consensus on Windows contributors, it is more useful for most users
the generation of the desktop shortcut by default.
Now, users who don't want it should uncheck the option in custom install
or manually delete the shortcut after a full install.
It was not possible anymore for a plug-in to add a menu item to the
local Layers, Classes and Paths dialogs using <Layers>, <Classes> and
<Vectors> at the start of the menu path.
For the first two this was due to an extra length parameter and the
drawables now being inside a GimpObjectArray. To fix that we check
inside the object array for the correct type names.
I'm not sure if Vectors ever worked, but testing shows it only adds
runmode and image parameters. To fix that we do the same as for
ColorMap.
The 'jhbuild' build of GIMP (Windows only) was added in 2013 and then maintained
by only one contributor (it even offered unnoficial nightly builds) until 2017,
when it never received a new jhbuild-specific commit again.
After so long, update it to keep up with current development status is quite hard,
so it is reasonable to remove this already dead version of GIMP.
Resolves #10643.
Prevent gimp_modifiers_editor_show_settings () from being called
when the user clicks the Modifier Reset button in Preferences if
there is no device connected to GIMP.
For certain small selections, the pattern preview can't be loaded.
Since e1e30c6f assumes the pattern loads, this could cause a
crash if a dialogue with the preview is visible.
This patch checks if the scaled pattern was loaded before using
it, and otherwise uses the default pattern.
* Fixes an ARM .patch that stop to working after !1171, causing job fail
* Changes the logic of system upgrade (pacman -Syyuu) to be less redundant
This also improves consistency with the Debian jobs
Fixes #10605.
Export to xmc when image width or height is 256 pixels
causes a crash. Add equality check to an assert to stop
the plug-in from crashing.
Resolves #10530.
In GTK2, setting a window's scrollbar policy to GTK_POLICY_NEVER
hid the scrollbars. In GTK3, this also makes the window automatically
resize to fit the contents. Since ImageMap displays the full drawable
with no scaling, this caused the plug-in window to be very large for large
layers.
GTK_POLICY_EXTERNAL in GTK3 works the same as the GTK2 version of
GTK_POLICY_NEVER, so using it instead fixes the problem.
The default width and height magic numbers were also replaced with
constants.
- file-psd, sig[4] and block_len variables are initialized to stop uninitialized warnings
- file-xpm, g_file_peek_path () is cast to (char *) to stop "discarded const" warnings
- gimpconfig-serialized.c, %llu is used instead of %lu to stop overflow warning
If a system theme sets the background-image property for stacks,
it recolors the main canvas when empty. It also adds a border to
the toolbox Wilber area.
Additionally, the Credits page of the GtkAboutDialog has odd colors
due to general viewport grid styles overriding the GTK default.
This patch fixes these problems, and adds a custom CSS class to
the GimpAboutDialog for current and future work.
The previous commit did not fully convert the title/status bar
format string to be UTF8-clean, due to a misunderstanding
of the logic behind the symbol used to indicate an image
was dirty.
Rather than always grabbing the 2nd character in the format
string, this patch now grabs the next character in the format
string after the %D, %N, %C, and %E commands.
During the API port, the Map Object
plugin had some parameters added and
others changed to GimpChoice strings.
This broke the Spinning Globe filter which
called on the map-object plugin.
This patch updates the procedure call and
fixes ranges in the map-object plugin so
spinning-globe works again,
but larger scope warnings persist.
No functional change.
I did this while chasing #10590 and #10591
The refactoring moves replicated code into functions.
So readers can understand better without having to compare sections
of replicated code.
The comments also highlight issue #10590.
Use g_connect_signal_swapped for "resource-set" signal from Resource Choosers,
to match the signal handler expecting "callback data" in the first arg.
Otherwise the first arg is the object emitting the signal.
Resolves #10611.
In GTK3, GtkRadioButtons are set using the "active" property
rather than selected, so the callback needed to check the
GTK_STATE_FLAG_ACTIVE flag instead of GTK_STATE_FLAG_SELECTED
when changing grid types.
The code was also reformatted to match current coding style.
- To set color values in the 0-255 range we now have to use set_uchar.
- Because setting a default color is not working, the color in config
could be None, which if the color wasn't changed caused a CRITICAL.
Let's check for None and if that is the case then manually set our
default color.
When cancelling foggify we get the following error:
AttributeError: 'GimpProcedureConfig-python-fu-foggify' object has no
attribute 'end_run'
The end_run function was removed a while ago, so just remove this line.
The grid state was not correctly updated when changed from within the
grid settings dialog.
Instead of using g_simple_action_set_enabled we need to use
g_simple_action_set_state, since we don't want to change whether the
action is enabled or disabled, but the checked/unchecked state.
The current code assumes that one letter is one byte long.
This caused issues when using non-ASCII UTF8 characters in
the title and statusbar format strings.
This patch replaces the loop logic with g_utf8_next_char () and g_utf8_get_char ()
to get the next letter no matter how many bytes it takes up.
As reported in issue 10604, if the Align Tool is set to align relative
to a reference object and 'use extents of layer contents' is enabled,
clicking on a path causes a CRITICAL.
This is due to gimp_pickable_auto_shrink () being called, when GimpVectors
are not GimpPickables. A datatype check is added before calling the function
to prevent the issue.
When opening images like DDS or EPS that have an options dialog,
we either get a crash, or criticals.
The critical made clear that there is a problem dereferencing:
(gimp-2.99.exe:9900): GLib-CRITICAL **: 14:52:58.831:
g_atomic_ref_count_dec: assertion 'old_value > 0' failed
Looking at gimp_file_dialog_progress_get_window_id we see that the
handle doesn't get an extra reference, while in other similar places
the handle is duplicated.
Using g_bytes_ref on the handle fixes the criticals for me.
Due to GObject Introspection we can't have the last part of an
identifier start with a digit, since that part will be used in Python
as the identifier, and Python doesn't allow that to start with a digit.
e.g. GIMP_ROTATE_90 would be used in Python as
image.rotate(Gimp.RotationType.90)
To fix this we add DEGREES in front of the number, without a '_',
even though that looks ugly.
With the sample image that contains the XMP namespace Item with the
correct url included, it is not returning the url when we ask for it.
This seems to be an exiv2 issue, but needs more research.
What GIMP doesn't do, is report that the namespace url we were looking
for wasn't found, and make sure that this doesn't block us from
handling all XMP tags.
To improve this on our end, we check if there was an error getting the
url, and if yes:
- We generate a warning message
- We create a dummy namespace url, with a special check for the missing
Item namespace to give it the correct known namespace url.
Previously, the console's font color was hardcoded to #006000.
This did not stand out well on darker theme.
This patch pulls the widget's foreground color from GtkStyleContext
to ensure it contrasts sufficiently with the console background color.
- Fix "no icons" errors generating loaders.cache with .cmd (CI-Cross).
! This is a sub-optimal fix, but it's better than a useless build.
- Fix "no interpreter" errors generating .interp with Meson (CI-Native)
and generating .interp and copying .typelib with .cmd (Local-Native).
! This is a sub-optimal fix to Local-Native, but plug-ins will work.
- Fix "no iso" error copying iso_639.xml with Meson (Local-Native).
The Inno installer scripts contents (only 3 files: files, gimp3264 and
32on64) and filenames have been organized, making them much easier to
read, and slightly less hardcoded so less prone to being misunderstood
and pervasively receiving packaging stuff.
Just to be clear, one more time: the Inno installer (or future MSIX)
scripts never should be the center of attention. This "installcentrism"
caused a domino effect of partially "abandoning" the packaging, build.sh
and the meson scripts, which explains the existence of this MR...
(Some things still hardcoded since wildcards in Inno are very limited.
Also, the rational ordering principles of this MR were not applied since
these scripts are heavily based on the x86 .zip package and changing the
order of things here, according to my tests, breaks things quite easily)
The CI crossbuild job now use the same main script (and the same
sub-scripts of linking and debug generation) of the native CI for
packaging. These unified scripts greatly facilitates maintenance.
The crossbuild deps script is now more consistent in relation to the
native one. As this is polished, the cross one is now polished too.
A crossroad gimp build script was created with a more clear code.
Also, finally make the script for packaging only, removing build step
stuff that shoudn't be here (glib-schemas generation) since this causes
disparity with the Local native build; and adding some packaging
decisions that shoudn't be in the installer scripts (eg. specific
folders of ghostscript, glib; no share/themes), which also facillitates
INNO (and future MSIX) maintenance.
The local builds now can use the same script of CI for sake of time.
The compatibility layer is very simple and makes the script more
used/tested, therefore more reliable.
The local builds now can use the same script of CI for sake of time.
The compatibility layer is very simple and makes the script more
used/tested, therefore more reliable.
Also, remove some redundacy on the code for better maintenance.
Now, we have only ONE list applicable for build-deps-crossroad.sh,
build-gimp-msys2.sh and package-gimp-msys2.sh, instead of hardcoding
3 times. This unified list greatly facilitates maintenance.
Debian changes:
- Since autotools has gone, we don't need to specify 'meson' in the
debian job and others.
- The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and
the meson sintax of Debian jobs was also updated.
Windows changes:
- Then, clarify that the win64-nightly and win32-nightly jobs are, in
fact, in the 'packaging' step, since we don't really "distribute" GIMP
in .zip and the commands are almost the same of the packaging .SH
script, without scripted optimizations for Inno Installer (or future
.MSIX), crucial for distribution.
- We don't need to specify "native" sufix in any build since they are
the rule and cross builds are the exception.
General changes:
- The job names was changed to be more consistent and in accordance
with the folders present in the artifacts.
- The 'nightly' sufix was removed from the Inno Windows Installer job
and others, since this doesn't reflect the real build frequency.
- The scripts filenames are altered to stay "in order". This is not
essential but ultra convenient since it is easy to view and search.
(The -uni suffix is explained in a further commit)
- All artifacts names now have the commit to avoid apparently duplicate
files when downloading same step artifacts from different projects.
- Finally, rearrange the order of jobs rationally: first the OSes and
archs (from the most free and modern to the most closed and legacy),
then the stages (from 'prepare' to 'analysis'), ending with the
frequency of jobs (from the most frequent, called at each push, to
the least/weekly).
Overall, this changes, although difficult to review at the first
sight, will avoid in the future quite "dumb" issues like:
GNOME/gimp#10195
When cutting and pasting a single layer,
drawables->data might be empty. This results in a
crash on Windows and a failure to paste on Linux.
Since this function is inside an IF statement that already
confirms it has a valid image, the base type and
precision are retrieved from there instead.
Resolves #10537.
During the port, the "green_invert" variable
was repeated twice rather than using the
"blue_invert" variable. This prevented the
fractal from updating when blue was changed.
This is intended to prevent system theme background-images
and borders from overriding those set by GIMP.
The minimum size of tabs is also explicitly defined.
Our handling of Photoshop's Blend Clipped Layers as Group is flawed
causing the order of layers to be messed up which may cause certain
parts of the image to become invisible or having the wrong colors.
This only fixes the incorrect layer ordering. Correct handling of
group layers with clipping needs a more extensive rewrite.
This is a manual revert of eac1df4b61
since other changes were made to the same lines.
Although using legacy layer modes for several blend modes improves
compatibility with Photoshop, we found out during testing of the
image from issue #10498, that it negatively impacts loading of PSD's
that use Blend Clipped Layers as Group.
We convert this specific PSD setting by adding a layer group and
setting Composite Mode to Blend to Background.
However, our legacy layer modes do not support Composite Mode, meaning
that PSD's using this can show up using smeared colors.
Since this hasn't been in a release yet, let's revert this and rethink
how we want to handle the combination of these PSD settings.
Resolves #9933.
We used png_get_valid (pp, info, PNG_INFO_tRNS) to check if
an indexed PNG had transparency when exporting.
However, this function does not return TRUE/FALSE but instead
the contents of that PNG chunk. Since we use index 0 for transparency,
this function always returns 0. The non-transparent indexed export code
ran regardless, creating incorrect PNGs.
We set pngg.has_trns earlier if the image has transparency, so it's safer
to use this variable instead.
Magic number 1 changed to 2 in one place. Missed in earlier fix for #10127.
Changed magic number to a defined macro constant so it might not happen again,
should GimpConfig change again.
Substantive change is call gimp_item_get_by_id instead of gimp_drawable...
And a few type changes from GimpDrawable* to GObject*.
Lots of renaming of functions, substituting "item" for "drawable."
Update comments.
Made one function static that was already private.
Fix the test case gimp_vectors_set_selected
Add more tests
Enhance testing framework, add function assert-PDB-true
Enhance some tests: make test files order independent
Fix tests broken by recent changes to GIMP
There was the question on whether it needed an hyphen or not. The hyphen
naming was often used to describe the "Hard-edge painting" style, though
even for this, it was not an absolute case. Depending on English writing
style, we could also find "hard edge painting". Also Liam was noting
that when the term appears by itself, as a noun (rather than a
qualificative), it was likely best without hyphen. So we went for the
no-hyphen wording.
Then there was the capitalization question: should capitalization rules
of data labels apply to parts between parentheses? I went with the
answer that *yes*, since it's part of the title anyway. And without the
part between parentheses, we'd have several data named the same. So it's
just as important.
As a consequence, I also re-capitalized "FG to BG (HSV
Counter-Clockwise)" and "FG to BG (HSV Clockwise Hue)" gradients,
following this updated rule.
Resolves #10477.
The dark theme box-shadow for buttons does not blend well
when hovering over it, compared to the light & gray themes.
This patch adds an additional CSS rule to make the box-shadow
no longer clash in dark theme.
Some 2.10 modes, even in perceptual space, don't produce the same
result as PS. Now, the mapping table takes this into account, which
avoids surprises for the user.
The mapping table was generically indicating 2.10 modes as first choice,
which was resulting in terrible PSD compatibility in some cases. This
commit fixes this using legacy modes verified with latest PS version
(see attached files in MR).
Comprehensive rewrite of the DDS import routine, in the interest of
easier maintainability and readability. Adds formats.c/h, containing
tables and functions related to reading and parsing uncompressed files.
Importer now supports nearly all non-video uncompressed formats.
Includes a variety of minor-to-moderate fixes made along the way
which could not be pulled out into separate commits due to dependence
on other aspects of the rewrite.
Resolves #10454.
When porting to GimpProcedureConfig, all
light types were set to "Point" when 2 - 6
should have been "None" by default.
This patch fixes the defaults.
1. Recent changes to arg validation reveal bug in call to gimp-drawable-edit-gradient-fill,
supersampling arg must be >0
2. Make easier for testers to invoke by reducing the declared drawable capability
to SF-ONE-OR-MORE-DRAWABLE
Now use gimp-resource-delete
Drive-by fix of bad call to gimp-context-set-pattern.
Fixes other calls to gimp-font-delete, etc. in a test script.
Partly fixes 9867.
Due to a bug in commit de5c805cbb, which
changed the choice widget between line and paint tool to a
GtkStackSwitcher, changing that choice did not work anymore.
The reason being that the stroke method wasn't being updated on clicking
stroke. We fix this by setting the stroke method when OK is clicked.
When creating the dialog we also set the stroke method, to reflect the
last used choice, since that was also missing.
See discussion in !946: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/946#note_1768869
On Windows/macOS, the pad device is probably not even showing at all
right now, though I can't test. Also it could be eventually implemented
with pad actions support (see Luca Bacci comment in the same MR) using
WM_POINTER API on Windows.
On X11 though, the pad device is shown, except it is kind of pointless.
So I am disabling the frame (making it insensitive) and add a tooltip.
Handle some statefulness in actions taking a double parameter, in order
to make them friendly to GtkPadController and its pad ring/strip
integration.
The GtkPadController emits those actions with a double parameter
expressing the absolute value (e.g. 0-360 for rings, 0-1 for strips),
take care of converting these absolute values to relative changes
that increase/decrease the current GimpDoubleAction value.
Going for relative increments/decrements increases the genericity
of rings when mapped to actions, as going with the given absolute
values would mean means rings could be mainly mapped to angle-like
actions, reducing its usefulness.
We have everything in place to create GtkPadControllers converting
events into actions as configured in settings, and the signaling
to trigger the (re)generation of those as device, window or configuration
changes appear.
Only the last bit attaching those controllers to actually handle
input was missing, now done in this commit.
Since there may be multiple configured tablets and pads, we need to
keep track of per-device controllers to handle the configuration for
those. This mapping is kept in GimpImageWindow as the "main" toplevel
(i.e. the one(s) typically considered "keyboard focus" and receiving pad
events) and ensured to be kept up-to-date through the ::configure-pad
signal.
This API call will snapshot the current configuration of a device
into a GtkPadController, that is created and attached to a toplevel
(this event controller only acts on toplevels).
This controller will handle pad events, trigger actions, and update
compositor feedback (e.g. GNOME Shell pad OSD) as per the actions
mapped in the configuration dialog.
If a pad device configuration gets changed, or reset, we should trigger
the creation of new pad controllers for the existing toplevels.
Add the plumbing so that saving/resetting a device configuration will
result in the same ::configure-pad signal, and trigger it from the
relevant places.
In order to apply the pad configuration so it does something, we
need to create GtkPadController objects on each toplevel for each
configured pad device.
This signal will work as a hint that a new GtkPadController should
be generated for the given device and current configuration. At
the moment, emit it when pad devices are added or removed.
The UI is heavily inspired in the existing one for midi devices
and the such, as the restrictions are somewhat similar. Since there
is not enough information to introspect the device without the help
of libwacom (and the UI should work with tablets unsupported by
it, regardless) the list starts empty, and there exists a "grab
event" button to press pad buttons (or use rings/strips) and
create/focus a list item for the button/mode.
Double clicking on an action (or pressing the "edit" button) spawns
a different dialog with a GimpActionEditor to select an action.
And lastly, actions can be deleted with the "delete" button.
Pads may have different modes (e.g. leds in the tablet) that apply
to all pad features, the list will allow different actions to be
set on the same button in different modes. This basically multiplies
the amount of mappable actions by the number of available modes.
This object holds the mapping of pad device features (buttons/rings/strips)
to actions, given the current mode (e.g. leds in the device), and can be
serialized/deserialized from configuration files.
Fixing:
> Scalar value @inargs[...] better written as $inargs[...] at pdb/lib.pl line 247.
> Scalar value @outargs[...] better written as $outargs[...] at pdb/lib.pl line 386.
This continues the theme definition work from bd398d5c.
A new edge-border-color tag was created
to allow for defined widget edges in both
light and dark themes.
The box-shadow highlights for buttons
and header/menubars was defined to
reduce system theme leaks. Some CSS
attributes were rearranges as well.
Per the official format specification and hardware implementation,
BC1 cutout pixels are always black with 0 alpha, whereas previous
versions of the plugin interpreted them as white. Commit f97e718e
partially fixed this, but made the behavior an import option that
also ignored the alpha component. This commit reverts the addition
of this option in favor of consistently following the spec.
The export properties "save-type" and "mipmaps" were left as ints
in Commit 427130be due to uncertainty on whether options could be
conditionally disabled on GimpChoice properties. From testing it
this functionality appears to work fine and is used in other plugins.
Now all combo props are GimpChoices and fully configurable from dds.c
Moves most of the code relating to YCoCg and Alpha Exponent into
misc.c/h, in the interest of making the rest of the codebase cleaner.
Removes the decode option from the import menu, as encoded files are
always decoded now (there used to be a menu button for doing this
after import, but with it gone there's no reason ever to not decode).
Finally, the remaining functions in color.c were only ever called once,
so these were extracted and inlined, and the empty file deleted.
Partial refactor of parts of ddsread to better handle DX10+ files.
Though not included here, this is necessary to import formats that
have no DX9 equivalent, namely BC6H and BC7, as the current handling
simply downgrades DX10 files and imports them like DX9 ones.
Extensive formatting and cleanup in the read-write files, and addition
of some comments where they seemed appropriate. Renamed a couple of
single-letter variables to be more descriptive.
Also removed an unnecessary global variable in ddswrite.c, and made
the "config" variable in ddsread a GimpProcedureConfig type, as was
previously done for ddswrite.
Fixes two major issues with mipmap generation, namely sRGB transforms
being applied both backwards and in 8-bit precision, causing severe
color degradation. sRGB transforms are now handled correctly and all
mipmap generation is done at 32-bit floating-point precision.
A new cubic filter has also been added (Catmull-Rom) which rounds-out
the existing lineup of cubic filters.
Also includes extensive code cleanup (sorry I couldn't separate this)
to mipmap.c/h and color.c/h
Recently some extra input validation was added, which caused the
gimp-image-set-selected-layers command in script-fu to fail with an
invalid value for argument 2.
This is caused by the object array contents always being set as
GIMP_TYPE_DRAWABLE, while the actual type may be a layer, etc.
So, let's set the actual type of drawable being used here by using
G_OBJECT_TYPE on the first data element.
Adds specific definitions for some widget borders that
are currently only defined by the system. This avoids
clashing colors depending on the system theme.
Resolves #10033
Not all system themes set a GtkRadioButton border-radius, so it
can default to 0. This creates a "box" around the radio button.
This patch defines the border-radius at 100% to make it universal.
These were using gimp_procedure_new, which was causing warnings like
LibGimpConfig-WARNING **: 13:56:33.270: couldn't serialize property
GimpProcedureConfig-plug-in-metadata-editor::image of type GimpImage,
and
gimp_plug_in_destroy_proxies: ERROR: GimpImage proxy with ID 1 was
refed by plug-in, it MUST NOT do that!
This also saves us from having to define image and run-mode parameters
ourselves.
We remove two warnings:
1. warning: format '%ld' expects argument of type 'long int', but
argument 5 has type 'GType' {aka 'long long unsigned int'}
Since GType is gsize, and this is not used in translations, use format
specifier G_GSIZE_FORMAT.
2. warning: enumeration value 'SF_IMAGE' not handled in switch (and more
similar ones).
Add a default block to let the compiler know we handle all values.
These are not generic undo function, but specific to the resize case (and even
more particularly when calling the GimpItem's resize() class method).
Also the variable was wrongly named no_undo when it actually was meant for the
opposite meaning, i.e. when we want to push an undo for a resize() call. This
made the call harder to understand. Furthermore the usage of double negation did
not help with understanding the code.
This is a fixup commit to MR !961, fixing a particular commit 5c2373a125 saying
that when canceling painting with layer expansion, strokes outside of the layer
remain visible.
When auto expanding layers, there is an option that allows user to fill
the newly expanded part with the pattern. But without this change, it
was not possible to change the active pattern without switching to some
other tool like bucket fill tool. This commit allows that.
Also added option in Edit->Preferences->"Tool Options"->"Paint Options
Shared Between Tools" that decides weather the options should be shared
between different tools.
Canceling a paint stroke restores the layer and mask (if present) to the
original size if they were expanded during the stroke. The part of
stroke that is outside the layer remains visible though.
In ink tool, if last_blobs is empty, the copy of blobs present in
last_blobs and blobs_to_render was same. Due to this, when layer
boundary is expanded, we move same blobs twice. Due to this a straight
line was drawn when starting painting from outside layer boundary. Fixed
the issue by storing a duplicate version in blobs_to_render. Updated
free part accordingly.
In layer expansion if user is trying to draw outside the layer boundary
with expand option turned on but the "Lock position and size" enabled,
the lock square will be blinked. If user is painting on layer mask, the
corresponding layer's lock will be blinked. It will be blinked only
once per stroke.
When resizing drawable for dynamic layers, the resize drawable function
would push Modified Layer/Channel item to undo stack. Initially, I was
checking if the drawable is being painted upon and used it to disable
the undo, but this when using resizing layers with layer mask, even if
mask is being painted upon, we still want to resize the main layer and
vice versa. But the main layer is not being painted upon so it would
push the undo to stack. To prevent this, I was using
gimp_drawable_paint_start before resizing, but this method is very
inefficient, as this function duplicates buffers. So added a new member
to drawable->private that will store weather to push undo or not.
Added option to tool settings that will decide how newly created parts
of layer and layer mask should be filled. For layer, same options are
provided as present in "Set Layer Boundary Size" dialog. For layer mask,
first two options from "Add a Mask to the Layer" i.e. "White" and
"Black" are added.
This commit changes gimp_channel_resize function to actually use the
passed fill type instead of using hardcoded GIMP_FILL_TRANSPARENT.
Hardcoding this value if required should be done in function calling
this function (which is already the case with all the instances already
present afaik).
Modified gimp_gegl_buffer_resize function to add three new parameters,
pattern, pattern_offset_x and pattern_offset_y. If pattern is not NULL,
then we set the pattern of buffet to this value. Like in
gimp_gegl_buffer_resize function, this logic is mostly copied from
gimp_drawable_fill_buffer function with minor changes.
This function returns resized version of the input buffer. It also takes
in a color argument. The layer background will be filled with this
color. Fill background logic is similar to gimp_drawable_fill_buffer.
The lock in the layers tab only sets lock for the actual layer and not
for its mask, so also check the lock on the actual layer and not just on
the mask when editing layer mask.
Everytime the layer expands, if the undo extents are empty, then make
them non zero. If the undo extents are zero, then user will not be able
to undo the expansion of the layer. This is perticularly required by
MyPaintBrush as just clicking the image without any motion does not draw
anything, but expands layer if required.
This function returns TRUE if the drawable is expanded. Otherwise, it
will return FALSE. This removes the need to check width and height of
the drawable to infer the same.
Made `gimp_image_editor_image_flush` and
`gimp_image_editor_image_flush_idle` functions idle. For expanding
layers dynamically, we need to use gimp_image_flush funtion from the
paint therad. The gimp_image_flush eventually calls these functions.
When painting the layers with a layer mask, if the layer need to be
expanded, the layer mask is also expanded with it. The same is done even
if layer mask is being painted upon.
Undo works with these layers by adding resizing of both the layer and
mask to the undo group if the layer is resized during painting.
Now layers will expand when trying to draw beyond layer borders with ink tool.
Tool options similar to paint tools have been added (expand_use and
expand_amount).
When painting with "Expand Layers" option turned on but "show all"
turned off, layer will not expand beyond image borders.
Layer will not expand if "Lock size and postion" is turned on.
Created a separate function gimp_paint_core_expand_drawable that handles
layer expansion while painting. The gimp_brush_core_get_buffer function
now uses this function to expand drawable. It has been separated so that
it can be reused for ink tool.
When painting with paintbrush tool, the borders of active layer will
automatically expand to accomodate the stroke. The undo does not work
with expanding layers.
This patch adds better handling for group begin and end markers
within ASE palettes. As a result, this fixes an issue where the last
color was not imported in some ASE files without groups.
Additionally, this guarantees that colors are imported using 4 bytes
per https://gitlab.gnome.org/GNOME/gimp/-/issues/10359#note_1921462
Resolves #10359
When compiled with -Werror=strict-aliasing, the build fails
on this line due to converting pointer datatypes.
This patch switches to using memcpy () instead.
Currently we only use and retain "critical" PNG chunks,
discarding any safe-to-copy but non-image chunks.
This adds code to store them as parasites and then
include them on export, thus preventing loss of data.
when loading a BMP image with an invalid compression value.
The invalid compression check was missing a goto out (error exit)
causing the GError to be overwritten, which caused a GLib warning.
We add the missing goto statement here.
Overwriting a GIF animation results in loss of frames if a previous export turned off
animations.
This sets a parasite on import which we check for on overwrite. If it was an
animation originally, we overwrite as an animation as well.
Though we mostly removed floating layers/masks (formerly floating
selections) in many interactions, at least for default behaviors for
basic pastes, there are still advanced usage attached to this concept
and some advanced users are willing to have easier access to such items.
For this reason, this commit:
- adds edit-paste-float and edit-paste-float-in-place for pasting the
contents of the clipboard as floating data with default positionning
algorithm or in-place respectively;
- renames select-float to select-cut-float which does a cut and paste as
float in one action;
- adds select-copy-float which does a copy and paste as float in one
action;
- reorganize a bit the `Edit > Paste as` submenu with sections for the
floating data variants;
- add a "Float" submenu in "Select" root menu, containing the 2 variant
actions select-cut-float and select-copy-float.
This adds an import option for DDS DXT1/BC1 images to always use
transparency. This is the default behavior, since this was what always
happened until now and it seems that DDPF_ALPHAPIXELS is very rarely
set for these type of images.
However, as the mentioned issues explains, advanced compression
algorithms can use this transparency data instead to mean a black
pixel. There is however, no certain way to determine this.
For that reason, we add an option here, that, if disabled, will
interpret fully transparent values as a black pixel.
Some games apparently need dds images to be vertically flipped.
We already have an option to flip dds images on export, so it makes
sense to also allow flipping on import.
The anchor and merge down buttons are visible at the same time, which should not be the case.
Their visibility is now dependent on the existance of a floating selection.
The New Group and Search/Link buttons are also disabled when there's a floating section.
In addition to the requested DXGI variants we also load the older
D3DF versions, including handling of the signed versions.
We also set signed when the pixelformat flag DDPF_BUMPDUDV (added in
the previous commit) is set.
As shown in issue 10287, the system theme can create a
large white border around GimpSpinButton.
This patch fixes this, and also improves the border appearance
by assigning it to the background color rather than system default.
This adds support for loading RGBA DDS images with 16- and 32-bit per
channel. Loading is supported for 16-bit half float, 32-bit float,
16 and 32-bit unsigned and signed int.
This supports both the DX10 formats and the D3D FOURCC versions.
16- and 32-bit per channel images with less than 4 channels are not
yet supported.
When saving a PDF, you have the option to export layers as pages.
This works for a single layer group that contains multiple layers.
However, the option is disabled because the plug-in only checks
"top level" layers.
This patch adds code to check if the single layer is a layer group,
then enables the option if there are more than one layer in that group.
This completes commit 685c8bde99 where the http:// scheme was automatically
transformed into https:// in some cases, in particular while typing (when
pasting for instance, it was still possible to add an http URL). So let's block
"toggled" signal handlers when the URL is explicitely edited to prevent this
annoying issue.
(cherry picked from commit b991f8b361)
This is only a temporary solution meant to be backported to gimp-2-10 branch,
so that at least the preview now matches how angles always worked in at least
the 2.10 series: angles are measured clockwise.
Now there is the question that in the documentation of the Brush Editor, it is
written that angles are supposed to be counter-clockwise. A solution was
proposed to make them so, but only for generated brushes (whereas angles stayed
clockwise for other types of brush) which is a very bad inconsistency.
Furthermore I find the whole tool options vs. brush editor settings mess quite
confusing. Some decision should be made for GIMP 3.
For GIMP 2.10 though, this should be an OK fix: no behavior change on-canvas,
only making the preview actually match what happens on-canvas (even though it
goes against what the docs say but it's probably better than breaking workflows
relying on actual on-canvas behavior).
Note: this commit is based on an initial proposition by Alx Sa in MR !1119,
except that the patch was only working when the preview needed to be scaled.
Instead we must go through this brush transformation code path for generated
brushes, whatever the scale.
While exiv2/gexiv2 could be able to load metadata from JXL files
directly, success is not guaranteed (depends on version and
configuration, for example support could be disabled or compressed
metadata could not work).
Loading metadata via libjxl should work all the time.
It is also important not to display dialog to rotate the image
according the orientation from EXIF, because in case of JXL,
the orientation is stored in codestream and it has priority.
This fixes this warning (as appeared with commit ad8b47bff7):
[1/235] Compiling C object libgimpwidgets/libgimpwidgets-3.0.so.0.9900.17.p/gimpdialog.c.o
../../../../../../../dev/src/gimp/libgimpwidgets/gimpdialog.c:774:1: warning: ‘gimp_dialog_set_title_bar_theme’ defined but not used [-Wunused-function]
774 | gimp_dialog_set_title_bar_theme (GtkWidget *dialog)
We could either put the whole `gimp_dialog_set_title_bar_theme()` declaration,
definition and usage into #ifdef, or only the implementation (making the
function a no-op on non-Windows platforms). I chose the former. There was some
discussion that maybe some implementation may happen later for other platforms,
but until then, no need to call it needlessly (even more as we don't know when
any theoretical other implementation would happen).
Certain dds images can have non-zero unexpected pitch_or_linsize values.
Until now we were only computing this ourselves in case it was zero.
Let's just always compute it and print an error to the terminal if it
differs from the value in the file.
A sample can be found in Galactic Civilizations 3: Bokeh_Hex.dds.
This change also allows us to safely load the poc in security issue
ZDI-CAN-22093 as that issue was apparently only caused by an invalid
value of pitch_or_linsize.
Optimize dds loading a bit by moving code that doesn't change outside
the loop:
1. The number of bits to be shifted when the source isn't exactly 8 or
16 bits depends on bytes per sample and isn't changing inside the loop.
2. Use rowstride variable to compute width * d->bpp once.
3. The check for rowstride > hdr->pitch_or_linsize doesn't change
inside the loop so move it out.
Inside the loop we only check the DDSD_PITCH flag once and move both
the size check and the fread check inside it.
Resolves #10262.
The gradient color was being used if Confetti or Color from Gradient
dynamics had been set, even if dynamics had been disabled.
This adds an additional check to make sure dynamics are enabled
first - otherwise, the brush's existing stamp or color is used to paint.
There were 2 issues here:
1. When more than 8 bits per sample are used, a previous commit changed
it so that we would be using 16-bit integer mode instead of 8-bit.
However, the actual code for this specific format was not updated to
reflect that.
We fix this by computing 16-bits per channel values and upshifting the
10 and 2-bit samples to 16 bit per channel.
2. The computation of masks was incorrect. It computed each channel
mask separately, based on whether it was <= 8 or not.
However, if any channel needs more than 8 bits, all masks should be
computed 16 bits since we will then 16-bit integer mode.
We fix this by checking all channel bits together, and if any is higher
than 8, but not more than 16, we use 16-bit masks.
I also took this opportunity to add support for 32-bit masks if we
ever need those.
@Wormnest noted remaining regressions after 8faad92e.
The second fread() only runs if the DDSD_PITCH flag is set,
so the error handling check should also be conditional.
Additionally, the ZDI-CAN-22093 exploit no longer runs but
still could cause a plug-in crash. This patch adds an additional
check to ensure the buffer size was within bounds.
@Wormnest pointed out that compressed files are likely smaller than
width * height * bps, so our check to prevent ZDI-CAN-22093
also caught valid files.
The size check is removed from load_image () and moved to load_layer ()
before the two fread() functions, as we know exactly how much we'll
try to read at that point.
When loading an xcf file, if a a font has already
been used, its file's hash is compared against the hashes
from the xcf file (to speedup loading), but if the font is from a .ttc file (a font
collection), then all fonts from that file will have the same file
hash, so the wrong font might be selected. a simple solution is to not
use the hash except as a last resort if every other field is identical.
These are not usable by plug-ins anymore which should store their data between
runs as arguments or aux arguments (in case of values which should be stored
from one run to another but are not really usable for non-interactive scripts).
These are per-plug-in (not polluting the whole process space with just random
strings as identifiers which could be used by other plug-ins) and even survive
restarts of GIMP.
I still keep these functions, but only internally, as they are used to store
settings of GimpAspectPreview, GimpDrawablePreview and GimpZoomPreview across
plug-in runs. Still I changed their API to set and return a GBytes directly
(mimicking the private PDB functions' API).
Also I remove gimp_pdb_get_data_size() which is useless when exchanging GBytes
directly.
Note that the 2 functions are still exported in the library, and only not
advertized through headers (so they are not really internal, just hidden), on
purpose, because we need to call them in libgimpui. So it is still relatively
easy for a plug-in to use them. Nevertheless I made clear in the function
documentation that these must not be considered public and could end up deleted
at any time. Any plug-in still trying to call these takes the risk of having
their code relying on unreliable API.
...by adding parameters and porting to
GimpProcedureConfig/GimpProcedureDialog.
Code was also rearranged to match the ordering
of other plug-ins.
As a note, the help message is "Special effects that nobody understands".
It would be nice if someone with more familiarity with this plug-in could
update the help messages to explain the parameters.
I had the case when "Sphere" script crashed, bringing down the whole script-fu
plug-in (while trying to reproduce #10214). Then after being run, we get a
dangling pointer to a finalized action object.
Even in successful use cases, we will want to give the ability to unregister
normal plug-ins/procedures wrapped as GIMP extensions, and there is also the use
case of temporary procedures, so I'm sure this bug could be reproducible even in
normal non-problematic runs.
I am pretty sure that this should be in single selection mode because we don't
even really have code to handle cases with multiple brushes or font selected.
Right now, we assume in many places that there is only one font or brush (or
other data) active at a given time.
Yet this code (or older versions of it) is old apparently and I realize that
even in 2.10, I can ctrl/shift click to select several data objects. This is the
weird part.
Anyway let's put this in single selection mode and see how it goes. If there
were actually use cases which I didn't know about, I'm sure we'll soon have
reports.
I could still see annoying scrolling up/down happening when we are deselecting
an item (typically with ctrl-click). In such a case, the cursor is on a
deselected item. Just make it bump to a closest item, preferably a visible one.
Note that "save-type" and "mipmaps" were left as ints rather than GimpChoice,
as some options are conditionally disabled and I don't know if that
is available in GimpChoice just yet.
A DDS loading bug related to 6ad54ca3 was also resolved.
The correct header value to check for the pixel size was not "depth" but "bpp".
My first versions were commits 98f0c448 then 1d8782915e but the more I go, the
better I understand the implications of the selection vs. the cursor. In
particular, when setting a cursor, which also initializes the selection to this
item only, the tree view would also scroll to this item. The current
implementation, which sets the top item as cursor, is therefore particularly bad
for multi-selection which doesn't fit fully in the view, because we also end up
scrolling up. Say you have a long list of layers, you first select the top
layer, then scroll down to the bottom layer and ctrl-click it: the selection
(now 2 items) works but you end up scrolled back all the way up.
This alternate version is much better, by ensuring that your cursor is at least
within the selection (hence avoiding the discrepancy between keyboard navigation
and pointer navigation, and which was fixed with commit 98f0c448), so that we
don't try to change the cursor when possible.
This was broken in commit 3e101922. Setting a cursor basically resets to a
single selection, invalidating pointer-made multi-selection.
But then we got back the bug it fixes, which is that we must grab focus after
the selection is actually made. So we now grab at the end.
This also had a bad consequence for multi-selection (again): if the focus was
not already on the tree view, gimp_container_tree_view_selection_changed() was
not called. This function was where the actual selection-changing is meant to
happen. So we had to shift-click (or ctrl-click) twice. The first time, nothing
would happen (but focus was given to the tree view). The second time, we could
finally update the selection.
This is why we add 2 different cases of focus grab, which should hopefully
handle all cases correctly, though this code is really extra-complex. This
replaces MR !1128.
I also remove (without replacement) 2 usages of gimp_get_data() without
associated gimp_set_data(). According to the comment, it looks like the
associated data was likely set by the GAP plug-in instead. Let's drop this.
Finally I see a lot of arguments, several of them being float arrays, so I
wondered if they were related to the curve and point arrays we are storing as
aux arg now. Apparently these arguments are not even used in the plug-in, right
now, which is explained in commit e318651c99. Maybe if these were actually
used/set and if we implement float array (de)serialization, would this aux
argument become useless?
Lastly, I deleted some code paths which were never used. For instance, stored
bval.total_steps was never set to anything else than 0 anywhere (so I removed
both the variable and the other code-path, which actually ended up being the
GAP-related data get). Additionally in p_bender_calculate_iter_curve(), there
was a big else block which was only happening when the GAP-related variables
were set. It got deleted too (as is a function only used in this block of code).
The argument is the serialized description of the generated fractal. Actually it
may even be useful as a non-aux argument. A GFile argument could eventually be
interesting too, though one arg per setting would be better of course (it allows
more easily to generate animated frames for instance). In such a case, the GFile
would be used in priority, otherwise the other args.
Notes:
* I didn't port to GimpProcedureDialog though it looks like it would not be too
hard (most of the GUI would still be custom GTK code, yet we could have the
generic "reset to initial|factory values" buttons and load/save).
* The custom "Reset" button (identical to what "reset to factory values" would
do) works fine anyway.
* The "run with last vals" works fine where there were indeed previous runs
(which may be in previous sessions), but crashes when it's actually the first
run ever. Some of the base structure data were not initialized. It should not
be too hard yet would require a bit of code reorganization to fix this.
- Argument "parameter-uri" becomes "parameter-file" (GFile instead of URI
string).
- Adding a "settings-data" auxiliary bytes argument to handle all settings for
the time being, instead of using gimp_get_data() and gimp_set_data().
- "last_file_name" was also removed from the ValueType struct, using the
"settings-data" arg instead.
- Fixing the non-interactive usage which was missing a gegl_init() call.
- Use GIO for various reading and writing to a CML parameter file.
- Better bubbling up of error messages.
- Fix the loading of the last section of CML parameters file.
- Also fixing deactived file dialog when clicking the open button a second time.
We use a GBytes auxiliary argument (i.e. not visible in the public API) which
perfectly replace gimp_[gs]et_data() API, in even better (since it also works
across sessions).
The "Reset to initial values|factory defaults" still don't work. We could make
these work even with the AUX args, but I feel like this would be far too much
work for a non-optimal solution anyway. The real solution can be when we get
more public arguments to this PDB procedure to handle every setting
individually. This can happen after GIMP 3 release (especially now that
arguments number and order don't break the PDB API anymore).
I added a bunch of arguments, in particular nearly all the settings in the main
dialog, except for "Colormap" as I'm unsure yet how to handle it. It looks like
a mix of GimpChoice and GimpDrawable. I guess it could just be both (2 args,
using values from the GimpChoice if GimpDrawable arg is NULL).
And I didn't make the settings in the "Edit Flame" dialog into arguments as I'm
not sure if the "Speed" and "Variation" in particular should be args, or are
just temporary args only meant to construct a flame (in particular, it looks
like it builds data defining the flame?). These data should be their own args
probably?
Maybe we could also have the "file" as alternative way to init the flame data
(the "Open" button)?
For now, I'm just storing the whole settings struct as an aux argument, so that
"Load/Save Settings" work, as well as the initial values from previous run.
Also the whole code is still a bit of a mess. I feel like we could really
simplify a lot of the code, all these values stored globally or duplicated now
in both the GimpProcedureConfig and the control_point structure.
Resolves #9989
In 2.10/GTK2, clicking an already selected toolbutton caused the
background color to change to indicate this action.
This patch restores that behavior through CSS updates.
It also slightly rearranges the CSS to group related button styles.
Since we were not chaining up with parent's finalize(), we were not
removing the instance from the gimp-debug infrastructure which assumed
the object was leaked and would try to read its reference count for
debugging purpose, when GIMP_DEBUG=all was set.
In fact, the object was not leaked, therefore we got into a segfault
when dereferencing already freed memory.
I added a few specific validations for range types (int, double…), and a
generic validation at the end, meant to catch all yet uncaught invalid
argument cases (yet with less details on the what and why).
In Preferences > Toolbox, clicking on an item below the
initial scroll window view causes it to jump to the top
automatically. This patch prevents this by setting the
clicked index in the GtkTreeView before grabbing focus.
I had this one crash upon exit, inside gimp_align_options_update_area() as a
consequence of gimp_align_options_image_changed() being called on an image
change. I could not reproduce after this one time and it's very likely a race
condition when everything is getting finalized, and the tool options object is
getting finalized earlier than the user context.
Anyway this should fix the potential crash.
gimp_procedure_new_return_values() takes ownership of the passed GError (it
allows, among other things, to call it directly as return value). So we must not
try and free it afterwards.
These are stored in the Extended Block. This block also holds metadata
in Exif, IPTC, and XMP formats, but those are not yet implemented in this
patch. A comment stating Exif was implemented in PSP 10 was corrected
to PSP 8 as well.
Changes only to ScriptFu.
The third term (the default) of a SF-FONT etc. spec is now ignored.
Test case is SF>Test>Sphere. There are still crashing issues
related but separate.
Changes were made to the click code for layers & masks
due to the introduction of multi-select, and this seems to
have caused the view highlight to be inconsistent.
This patch adds the gimp_layer_tree_view_update_borders ()
call after a click or selection to fix this.
On Windows, the title bar can be set to light or dark mode via DwmSetWindowAttribute ().
This adds code to update the main title bar and dialogue title bars based on the current theme.
The main title bar uses "prefer-dark-theme", while the dialogue title bars
uses the color of the widget background to assume the correct color.
If we leave a space between the macro name and opening parenthese for argument
lists, the args are not considered macro args (which will be discovered when
using it). I experienced this issue while testing code on some plug-in
yesterday, so thought I might as well fix all these broken macros for casting to
the specific GimpPlugIn subclass, so that we won't have a next time.
The gimp_procedure_run() already existed, though it was with an ordered
GimpValueArray array of arguments. Its usage feels redundant to the series of
gimp_pdb_run_procedure*() functions (which is confusing), but
gimp_procedure_run() was actually a bit more generic, because it does not
necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a
local GimpProcedure, such as the case of one procedure which would want to call
another procedure in the same plug-in, but without having to go through PDB. Of
course, for local code, you may as well run relevant functions directly, yet it
makes sense that if one of the redundant-looking function is removed, it should
be the more specific one. Also gimp_procedure_run() feels a lot simpler and
logical, API wise.
A main difference in usage is that now, plug-in developers have to first
explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when
they wish to call PDB procedures on the wire. This was done anyway in the
gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name
directly).
Concretely:
* gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and
gimp_pdb_run_procedure_valist() are removed.
* gimp_procedure_run() API is modified to use a variable args list instead of a
GimpValueArray.
* gimp_procedure_run_config() and gimp_procedure_run_valist() are added.
* gimp_procedure_run_config() in particular will be the one used in bindings
which don't have variable args support through a (rename-to
gimp_procedure_run) annotation.
Passing (name, type, value) triplets is actually useless because we can get the
type information from the procedure/config anyway. That only adds one more
verification to do. Let's just change the function so that we pass (name, value)
couples instead, pretty much like in `g_object_set()`.
As far as plug-in API is concerned, at least the calling API, order of arguments
when calling PDB procedures doesn't matter anymore.
Order still matters for creating procedures with standard arguments (for
instance, "run-mode" is first, then image, or file, drawables or whatnot,
depending on the subtype of procedure), but not for calling with libgimp.
Concretely in this commit:
- gimp_pdb_run_procedure_argv() was removed as it's intrinsically order-based.
- gimp_pdb_run_procedure() and gimp_pdb_run_procedure_valist() stay but their
semantic changes. Instead of an ordered list of (type, value) couple, it's now
an unordered list of (name, type, value) triplets. This way, you can also
ignore as many args as you want if you intend to keep them default. For
instance, say you have a procedure with 20 args and you only want to change
the last one and keep the 19 first with default values: while you used to have
to write down all 20 args annoyingly, now you can just list the only arg you
care about.
There are 2 important consequences here:
1. Calling PDB procedures becomes much more semantic, which means scripts with
PDB calls are simpler (smaller list of arguments) and easier to read (when
you had 5 int arguments in a row, you couldn't know what they refer to,
except by always checking the PDB source; now you'll have associated names,
such as "width", "height" and so on) hence maintain.
2. We will have the ability to add arguments and even order the new arguments in
middle of existing arguments without breaking compatibility. The only thing
which will matter will be that default values of new arguments will have to
behave like when the arg didn't exist. This way, existing scripts will not be
broken. This will avoid us having to always create variants of PDB procedure
(like original "file-bla-save", then variant "file-bla-save-2" and so on)
each time we add arguments.
Note: gimp_pdb_run_procedure_array() was not removed yet because it's currently
used by the PDB. To be followed.
Similar to commit 6905b0bbef for "file-pat-save-internal". For interactive
usage, nothing is changed, but for non-interactive ones, we can now choose a
list of drawables to export.
Pending more changes, relative to the discussion in #7370.
Since now the name of arguments will become more important, over order, let's
name the first parameter "run-mode" even in cases when this is a dummy argument
(most often the case when a procedure always acts the same, whether interactive
or not). I keep the mention of the parameter being useless in the nick and blurb
strings, as it's useful information. But let's keep using our "standard" arg
name "run-mode" for this first argument.
This partially revert some of the changes in commit 652a1b4388 because the
Windows CI suddenly failed because of this (my local build on Linux didn't have
any problem though) with:
> /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_save_defaults':
> /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2570:(.text+0x633): undefined reference to `_gimp_procedure_config_save_default'
> /usr/bin/x86_64-w64-mingw32-ld: /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2576:(.text+0x644): undefined reference to `_gimp_procedure_config_has_default'
> /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_load_defaults':
> /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2549:(.text+0xa2f): undefined reference to `_gimp_procedure_config_load_default'
> /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_constructed':
> /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:368:(.text+0x11b1): undefined reference to `_gimp_procedure_config_has_default'
This is because these functions are used not only inside libgimp but also
across inside libgimpui. As a consequence, the build fails when linking
libgimpui.
This goes with our planned change of not making GimpProcedure arguments order
relevant anymore regarding the PDB API. In particular, it means we don't want to
use GimpValueArray for various procedure arguments API, but directly
GimpProcedureConfig objects.
This change will allow to add or reorder arguments in the future, so that we
won't have to create new PDB procedures when adding new arguments, while still
keeping PDB API stability.
Some of these should not even be visible by libgimp and were just fine as static
as well! For the rest, I make them really private (not only with a private
header).
We cannot be 100% sure generically (i.e. for all possible bindings available
with GObject Introspection) if bindings add their own reference to objects or
not. Clearly we have cases when they always do (Lua, Javascript), cases when
they do only in certain conditions (global Python variables) and cases when they
don't (Vala). What we know for sure is that in these script languages,
developers don't manually manage memory anyway. So the additional reference is
not their fact.
So let's just maintain a list of automatic memory managed binding languages,
among the few we officially support (i.e. the ones for which we have working
test plug-ins) and verify by executable extension if the plug-in is written in
one of these.
Both keeping a manually-updated list and verifying by extension are not so
pretty solution, but for now it will do.
Resolves the second half of #300.
This adds conditional code to the gtk_window_present () call in gui.c
to prevent it from running if the user requested it stay minimized in the shortcut
or commandline call on Windows.
It also keeps the splashscreen minimized in that case.
As explained in the comment above, the reference might actually be owned by the
binding code (not by the plug-in code) and therefore can still be released
afterwards. Freeing it now while we don't own the reference exposes us to
double-free crashes.
This will be needed in particular for GIMP on Windows/Aarch64. Also even on
other OSes, it is useful to support lua plug-ins not only with luajit but also
upstream lua.
This is in part a port of commit 6f921b27bb from gimp-2-10 branch, except that I
could not easily cherry-pick because too much had changed already in the master
branch.
There are also a bunch of additional changes in some other glue scripts.
Also some rules which were in the 2.10 branch don't apply to the main one, such
as Python being copied from the x86 binaries, since clang-aarch64 has Python3
(unlike Python2).
See discussion in #9170 and !1091. It looks like this soon won't be a problem
with a recent llvm-windres (which is now patched). But until then, let's patch
upstream GIMP but only for this build.
Note: the additional `rm` call was done for this error:
> + mv _install-arm64 /home/SYSTEM
> mv: cannot move '_install-arm64' to '/home/SYSTEM/_install-arm64': Directory not empty
I guess the home directory is not properly wiped-out between runs, which is not
a huge problem as long as the runner is private to our project. Let's clean
things ourselves.
In some very hard-to-reproduce conditions, I experienced
tool_manager_selected_layers_changed() running on an invalid GimpToolManager
pointer (because tool_manager_exit() had already run) and therefore segfaulting
on quit. Let's make sure we disconnect the signal handler.
Add Border enlarges an image by twice the specified border size and creates the border in this
additional space. If an image already has the intended final size, this behaviour is not desired.
This change adds a toggle to (dis)allow resizing, similar to the drop shadow script.
This came up in a reddit thread by /u/rapidexchange
https://www.reddit.com/r/GIMP/comments/6csofx/im_new_to_gimp_so_sorry_if_this_is_a_stupid/
Adds code to read in PSP_SELECTION_BLOCK.
If there was an active selection in the PSP file when it was
saved, that selection will now be active in GIMP as well on load.
This is a consequence of commit 98f0c448. Apparently setting the tree view
cursor also reset visually the selection. So I make sure I only set the cursor
on the first path in the list of selected items.
Using gegl_parallel_distribute_area() for gimp_gegl_is_index_used() is just far
too slow by 2 order of magnitudes compared to a threaded implementation where I
process each buffer at once (but each in their own thread from a pool).
I guess the basic value check is too basic to warrant being done in threads
(note: even growing the distributed area by bumping the thread cost a lot was
not enough).
I didn't fixup commit dbaa8b6a1c directly so that we keep a trace of the
gegl_parallel_distribute_area() implementation in case we can do better later.
Additionally I fixed gimp_gegl_shift_index() to use the full drawable format,
including the possible alpha channel. Otherwise shifting indexes may result in
dropping the alpha value.
This comes with a "colormap-delete-color" into the "colormap" action group. The
action/button will be insensitive when the selected color is used in the image,
since it is only possible to delete unused colors.
Until now, it was not really possible to delete a colormap color, but since we
now use GimpPalette, people would definitely try to do so. It just makes sense
to allow doing this, but only if the color is unused.
Additionally when we do this, all the pixels refering to bigger indexes will be
edited so that they continue to refer to the same color (bigger indexes are
shifted by -1). Therefore removing an unused color does not change the image
render.
I wondered if we might want more options, e.g. the ability to delete a color
without fixing indexes (i.e. that colors over the deleted color index would
shift to the next color). This would even allow to delete used colors (though
now the last index would have to be unused one, unless we cycle colors).
Yet I don't think this should belong to this basic API. The most expected
behavior when deleting a color from an image colormap is to fix all indexes
stored in pixels so that the image still shows the same. So that's what this
function will do in this generic usage.
Improper counting of args declared by scripts versus pspecs in a ProcedureConfig.
Scripts don't declare run_mode, while pspecs have run_mode and an extra internal pspec
that is not an argument.
This is meant to replace gimp_image_get_colormap() (see also #9477).
We likely won't need a gimp_image_set_palette() because we can simply edit the
image's colormap/palette with GimpPalette API now and it is directly updated.
For instance, the following code changes the first entry in the image palette to
red, immediately:
```python
i = Gimp.list_images()[0]
p = i.get_palette()
c = Gimp.RGB()
c.r = 1.0
p.entry_set_color(0, c)
```
For this to work fine, I added a new concept to GimpData, which is that they can
be tied to a GimpImage (instead of a GFile). Image palettes are not considered
internals, they are just tied to their image, therefore they can be edited by
scripts/plug-ins.
Additionally with this commit, editing an image's colormap from libgimp API also
generates undo steps now.
Original patch by @ellestone.
The current tooltip is somewhat confusing for two reasons: It doesn't
mention the word "ICC", leaving room for doubt as to what a "color
profile" might be. And as @TheTooleMan suggested, it's easier to read
and understand if the action (opening a file . . .) is in front of the
modifier (. . . with an embedded ICC profile) instead of vice versa.
bootchk had the case in commit 6781a35668. I again had it with gfig. I think it
just makes sense to init GEGL, especially as the errors are not that explicit
and that the plug-in code may not even call GEGL code directly (so it makes it
harder to guess).
After the recent port.
* contrast-retinex: Initialize format & src_buffer to NULL
* curve-bend and map-object: Remove no longer needed functions
* file-load-gif: Fix C++ style comment
When the selection changes, the focus must be on one of the selected items. Not
doing this was creating a very annoying behavior where you would select an item
in the tree view with the pointer first, but then when moving up/down with the
keyboard arrow, the move originated from the previously set item. This was
because the arrow move used the "cursor path", i.e. the keyboard focus, and not
the item selection as origin.
In our case, let's make sure these match (i.e. the cursor path is the path of at
least one of the selected items, which is the most expected behavior for mixed
pointer/keyboard interactions).
See code in gtk_tree_view_move_cursor_up_down() from GTK code.
Resolves #10119.
If the user sets the "Image Spacing" and "Hole Width" values
to 0, the hole creation code gets stuck in an infinite loop.
This patch adds a check to the allocation code for the hole
to make sure both its dimensions are greater than 0. If not,
then the hole is not created in the first place.
… with another default shortcut.
This won't happen with the standard US layout, but among all the layouts which
exist (or will exist), there is no say that the characters behing <shift>2-5
keys are not another one of our default shortcuts for other actions. We don't
want to print this case, because it is special enough that it's really not a
bug. In this case, we just ignore the transformed shortcut on the zoom action
and be done with it.
Calling gimp_resource_delete() on a data with a file which was not stored yet
would fail on missing file as reported by Lloyd in a comment in #9976. We could
just special-case the code to make the already-inexisting case acceptable on
deletion, but there are a few more issues.
In particular gimp_data_create_filename() relies on actually checking file
existence on the file system. Therefore generating the file path too early
(before any possible rename, i.e. for uniqueness or other formatting need) would
easily generate duplicate paths (which means one of the data object would be
overwritten on exit). It's better to kinda *reserve* the set file path
immediately by saving the data file.
The only drawback I could see on saving early is possible I/O slowdown if a
script were to create many data, but I actually don't think it's a valid use
case (no script should likely create enough data files that we would notice a
slowdown, i.e. likely creating hundreds of data objects at once) anyway. So
let's go with it, at least for now.
If the GIF has a value other than 0 or 49 in its PixelAspectRatio
header, then we now use it to set the non-square pixel resolution.
For reference, GIFs calculate this value like so:
PAR = (Value + 15) / (float) 64.
It returns all the fonts (possibly more than 1) with a given name. I left the
function gimp_font_get_by_name() as a utility when one don't want to choose (or
is not able anyway, e.g. a script with minimal information), though I wondered
if we should not simplify with a single function (the new one, which is the
correct one now that it is possible to have several fonts with a given name).
It is easy to test with fonts named the same. For instance I could find 2
different fonts, both named 'Holiday'. This call in the Python console returns
both:
> Gimp.fonts_get_by_name('Holiday')
As part of this commit, I also implemented resource arrays (or subtype arrays)
as PDB arguments and return types.
… description.
- The returned value as width/height/etc. of the glyph extents (or bounding
box), not "of the font" (which doesn't mean much).
- Adding some definition for ascent and descent. This text is straight out
copied from Pango documentation comments in pango/pango-types.h.
- I don't see why we were negating the descent value. Let's keep the value sign
as defined in Pango.
- Fonctions were renamed: s/gimp_text_fontname/gimp_text_font/ and
s/gimp_text_get_extents_fontname/gimp_text_get_extents_font/
- The size_type arguments were removed. Even in 2.10, this argument was marked
as "dead" and ignored. It was only kept for API compatibility.
- The font name (string) was replaced by a GimpFont argument.
gimp_text_font() is easily tested in the Python console with:
> Gimp.text_font(Gimp.list_images()[0], None, 10, 40, "Hello World!", 1.0, True, 100, Gimp.context_get_font())
And gimp_text_get_extents_font() with:
> Gimp.text_get_extents_font("Hello World!", 100, Gimp.context_get_font())
- First do not write the protocol-version (and therefore don't read it either
nor compare it to the current one). This file does not depend on the protocol
version.
- Secondly when reading an unknown identifier, simply print a message on stderr
for debugging/reference, but ignore it up to the next closing parenthese.
- Finally do not use the file-version as a terminal error as well. When we read
a shortcutsrc with the wrong version, we still try to read it as best as we
can. There might be issues, but it's better than fully dropping the whole list
of shortcuts as it's a pretty important file (people might have spent a lot of
time tweaking their shortcuts!).
Fixing:
> [809/2421] Generating libgimp/GimpUi-3.0.gir with a custom command (wrapped by meson to set env)
> libgimpwidgets/gimppropwidgets.c:37: Warning: GimpUi: multiple comment blocks documenting 'SECTION:gimppropwidgets:' identifier (already seen at gimppropwidgets.c:23).
Hardcoded colors don't work well with theme customization (on a dark theme in
particular, it was bad).
Anyway built-in units are already grayed-out and non-editable. I don't think
further styling is needed.
This function is not perfect and in particular doesn't seem usable with binding
because of GimpUnit being some weird mix between an enum and some kind of class.
So this will have to be fixed too. See #8900.
… function gimp_font_get_pango_font_description().
Also updating file-pdf-save which is the only plug-in using these right now.
Note that I am not fully happy with the new function
gimp_font_get_pango_font_description() because I experienced some weird behavior
in file-pdf-save which is that some fonts were wrong if this is called after
pango_cairo_font_map_set_resolution().
But let's say this is a first step looking for improvements.
...and to GimpProcedureDialog.
Also resolves #25 by adding the missing PDB parameters to the GUI.
Note that there are a few remaining tasks:
* The config values are being copied to mapvals.
Eventually the rest of the code needs to be updated
to directly use the config.
* The material tab uses icons from the Lighting plug-in. They didn't show up before the port; this needs to be fixed.
* The drawable buttons are huge compared to the original plug-in. The styling needs to be looked at.
I am using the same GimpDrawableChooser with an additional drawable_type
argument to only show the appropriate tab if we want to limit what can be
chosen.
None of our plug-ins actually use a GimpLayer or GimpChannel only arg so far,
but if we have some day, or if some third-party plug-ins want to have such arg,
now they quite easily can!
After testing, setting a window as transient to another from another process is
still broken on Windows and it's hard to diagnose without using Windows
directly. Since it's not just broken, but it even hangs the whole process, which
is quite a blocker issue, let's disable again the whole code on Windows.
Converted to GimpProcedureDialog as well, and changed the
string argument for the combobox to GimpChoice.
Some widgets are still standalone and could be further improved
to work with GimpProcedureDialog.
A new aux parameter for upper/lower border area was added so this could be generated
as part of the GUI.
I received warnings about serializing the FloatArray and GBytes parameters, so I did not integrate
the existing variables with GimpProcedureConfig in this current version.
The only missing feature is that we don't constrain the various argument
drawables to RGB/grayscale or to the same dimension as the input drawable. This
could actually be quite easily implemented, either through a set of constraint
flags, or a more flexible callback function (similar to the API of
gimp_drawable_combo_box_new()). It could either be implemented on the argument
level (which has the advantage of letting libgimp handle argument sanity of
plug-in developers, even in non-interactive calls, with generic error messages)
or within the new GimpDrawableChooser API.
I was actually implementing this when I realized that this plug-in works fine
even with images of different dimensions. As for the format, GEGL handles format
conversion automatically. There is absolutely no reason to limit ourselves.
So let's drop this feature for now, because we should not over-engineer. If it
turns out useful and we get requests, we can always create later either a
specialized arg macro GIMP_PROC_ARG_CONSTRAINED_DRAWABLE() or a method to
specialize the widget with gimp_drawable_chooser_new_constrained() for
instance).
This was not working properly and needed some external build script as well as
the stamp/bogus header trick like for other similar in-source generated code.
In the same time, I get rid of old meson code which was meant for when using
meson < 0.57.0 (since our requirement is now meson >= 0.59.0).
I believe it should not happen in normal GUI case (which is when you create a
GimpProcedureDialog). I had the issue while moving around some plug-in code and
moved dialog creation before gimp_ui_init() by mistake. The issue was not
obvious until I followed the trace inside libgimp. This would be even more
frustrating for plug-in developers so let's have a clear warning message giving
the possible plug-in crash reason.
The various drawing APIs are cumulative which is not right when we want to
change a preview (especially if the preview changes dimensions! Then we end up
with pieces of the previous drawing behind the new one).
This new function will allow to reset the whole drawing. Note that we may end up
with some black background if the preview are doesn't have the right dimensions.
This should be improved later too.
Similarly to the various GimpResource select PDB calls, this allows to call a
core dialog in order to choose a drawable which will be returned back to the
calling plug-in.
This new GimpPickableSelect dialog is a subclass of GimpPdbDialog and uses the
same GimpPickableChooser widget as GimpPickablePopup, except that since it's
inter-process window management, it is harder to make a popup positioned
accurately relatively to a parent (especially on Wayland). This is why it's a
separate widget as a simpler dialog (which we will still try to make transient
as much as possible across platforms).
Improvements of GimpPickableButton:
- Update the selected pickable live as you choose it in the popup. This allows
for instance to get live preview of GEGL operations while staying within the
pickable popup.
- Store the initially selected pickable (before popping up) so that when one
cancels (either with Esc key or by clicking outside the popup, but not on the
parent button), the button comes back to the previous pickable.
- Properly destroy the popup when the parent widget is finalized to avoid
annoying cases where the popup might still be alive.
Additionally I split the GimpPickablePopup with a GimpPickableChooser containing
most of the GUI, which will make it usable as plug-in pickable chooser as well!
Clicking on the parent (typically a button, as in the GimpPickableButton case
used in GEGL operations' generated GUI) used to emit "cancel". Let's have it
emit "confirm" instead.
Also it makes for a "confirm" interaction through pointer action as there were
none until now (only key "confirm", e.g. Enter or Space keys), unless
implemented in a child class (e.g. GimpPickablePopup would emit "confirm" on
activate-item of the tree view widgets, e.g. when double-clicking an item; that
was not ideally discoverable).
A few minor code style issues were also fixed.
Note that there's only one procedure parameter (Preset name),
but it's not retained between runs.
I want to ask about this before making a full conversion to
GimpProcedureDialog widgets.
This name was really irking me because it's not a button (anymore? Maybe it used
to be just a button). Depending on the specific widget, it will have several
sub-widgets, including a label. And it can theoretically even be something else
than a button.
So let's just rename these widgets with the more generic "chooser" name.
Similar to the latest commits for GimpBrush:
- gimp_pattern_get_buffer() returns a GeglBuffer and allow getting a scaled
version of the pattern.
- Old gimp_pattern_get_pixels() is made private.
- Moved GimpPattern into its own file and store the buffer to avoid re-querying
it through PDB continuously.
No as for the widget to select a pattern:
- Preview frame ensured to be square.
- Default size increased.
- Drawing code using the new gimp_pattern_get_buffer().
- Cleaned up code.
So what I realized was that the core was sending contents without transparency.
Actually the mask was our transparency channel here. Since in most use cases,
what you want to do when you request a brush buffer is to be able to draw it
somewhere, having a buffer already with alpha is much better, even more because
by default, it looks like background color is black which is possibly not what
you expect usually from a brush preview.
If someone wants absolutely no-alpha, it's easy to get rid of the channel. It's
simply better that the default behavior is the most expected use case.
- Increase the default size to 40x40 and multiply it by the current window scale
factor to have decent preview size.
- Make the brush preview always square with a GtkAspectFrame: even though
brushes are not necessarily square, this is a much more obvious size rather
than letting GTK choose a random allocation size which ends up very weird
looking.
- Scale down the brush to the biggest possible dimensions which fit the square
preview area (if the brush native size is already smaller, I don't scale up
though) while keeping aspect ratio: previous implementation was really weird,
as we were only seeing a tiny corner of much brushes as we weren't scaling
them down. Obviously I use new gimp_brush_get_buffer|mask() functions for
this as it supports scaling.
- Implement drawing color brushes too: the previous implementation was only
drawing the brush mask, which was absolutely not what would be expected for
such brushes.
- Add a white background behind color brushes with transparency.
- Simplify and clean up the code.
One of the consequences of this new implementation is obviously that it's
mandatory to call gegl_init() when using this widget.
… and gimp_brush_get_mask().
gimp_brush_get_pixels() was a bit crappy, returning raw data with only
dimensions and bpp to go with (no color model/space, no bit depth…). So the
assumption is that we work with 8-bit per channel data, possibly with alpha
depending of number of channels as deduced from bpp, and very likely in sRGB
color space. It might be globally ok with many of the brush formats (and
historical brushes) but won't fare well as we improve brush capabilities.
- gimp_brush_get_pixels() is in fact made private.
- The 2 new functions are using this old PDB call _gimp_brush_get_pixels() to
construct buffers. This has some limitations, in particular that it returns
only 8-bit per channel sRGB data, but at least the signature won't change when
we will improve things in the future (so if some day, we pass fancy brushes in
high-bit depth, the method will stay the same).
- This new implementation also allows scaling down the brush (keeping aspect
ratio) which is useful when you need to fit a brush preview into a drawing
widget.
- Current implementation stores the buffers at native size in the libgimp's
GimpBrush object, hence save re-querying the core every time you need an
update. This can be improved as current implementation also means that you
don't get updates if the brush changed. This should handle most common use
cases for now, though.
- Also with this change, I move GimpBrush class implementation into its own
dedicated file.
- Move the property widget functions for GimpResource properties into a new
libgimp/gimppropwidgets.[ch] file. This mirrors the files
libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types.
- Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new().
- gimp_prop_chooser_factory() doesn't need to be public.
- Add a label to GimpResourceSelectButton, make so that the
gimp_prop_chooser_*_new() functions set the property nick to this label and
add this label to the size group in GimpProcedureDialog.
… from the plug-in normal runtime crossed streams!
I also add a huge comment in-code, because this was annoying enough to
understand and debug that I don't want someone to remove the idle without proper
consideration and testing in the future, thinking it's useless.
- Removing useless or redundant code.
- Simplifying various logics.
- Using GimpResource directly in temporary PDB procedures, not resource names.
- Better cleanup of the core resource chooser when the plug-in dialog quits (we
need it to ask core to close also any visible resource chooser dialog).
- Replace the "Close" button by more common OK/Cancel. In particular, the
GimpPdbDialog now properly keeps track of the initial object and when hitting
"Cancel" (or Escape key), this initial object is set back.
- Clean up some of the comments, especially when the code is self explanatory.
There is still much more to clean and improve, but it's a first welcome step.
Found by the definitely useful libgimp warnings:
> gimp_plug_in_destroy_proxies: ERROR: GimpPattern proxy with ID 13 was refed by plug-in, it MUST NOT do that!
One instance of `(GIMP_VALUES_GET_INT (args, 0)` was missed during the initial conversion.
This caused a compiler error. The value is now retrieved from the GimpProcedureConfig
object.
Brush, font, gradient, palette and pattern choices are currently chosen through
a dialog created by the core, which then returns the user choice to the calling
plug-in. This has the unfortunate consequence of having a pile of likely at
least 3 windows (main GIMP window by core process, plug-in window by plug-in
process, then the choice popup by the core process) shared in 2 processes, which
often end up under each other and that's messy. Even more as the choice popup is
kinda expected to be like a sub-part of the plug-in dialog.
So anyway, now the plug-in can send its window handle to the core so that the
resource choice dialog ends up always above the plug-in dialog.
Of course, it will always work only on platforms where we have working
inter-process transient support.
Instead of passing a guint32, pass the proper type, since our the HANDLE type
can be 64-bit on Windows (according to links I found).
I was hoping it might be the reason for the breakage under Windows, though I
also found Microsoft documentation saying that the 64-bit handle can be safely
truncated: https://learn.microsoft.com/en-us/windows/win32/winprog64/interprocess-communication?redirectedfrom=MSDN
Nevertheless I'd appreciate testing again from NikcDC or anyone else, as I
reactivated setting transient between processes on Windows.
Note that I also pass the proper types on X11 now (Window), even though guint32
worked fine. Better be thorough.
Having windows ID as guint32 is a mistake. Different systems have
different protocols. In Wayland in particular, Windows handles are
exchanged as strings. What this commit does is the following:
In core:
- get_window_id() virtual function in core GimpProgress is changed to
return a GBytes, as a generic "data" to represent a window differently
on different systems.
- All implementations of get_window_id() in various classes implementing
this interface are updated accordingly:
* GimpSubProgress
* GimpDisplay returns the handle of its shell.
* GimpDisplayShell now creates its window handle at construction with
libgimpwidget's gimp_widget_set_native_handle() and simply return
this handle every time it's requested.
* GimpFileDialog also creates its window handle at construction with
gimp_widget_set_native_handle().
- gimp_window_set_transient_for() in core is changed to take a
GimpProgress as argument (instead of a guint32 ID), requests and
process the ID itself, according to the running platform. In
particular, the following were improved:
* Unlike old code, it will work even if the window is not visible yet.
In such a case, the function simply adds a signal handler to set
transient at mapping. It makes it easier to use it at construction
in a reliable way.
* It now works for Wayland too, additionally to X11.
- GimpPdbProgress now exchanges a GBytes too with the command
GIMP_PROGRESS_COMMAND_GET_WINDOW.
- display_get_window_id() in gimp-gui.h also returns a GBytes now.
PDB/libgimp:
- gimp_display_get_window_handle() and gimp_progress_get_window_handle()
now return a GBytes to represent a window handle in an opaque way
(depending on the running platform).
In libgimp:
- GimpProgress's get_window() virtual function changed to return a
GBytes and renamed get_window_handle().
- In particular GimpProgressBar is the only implementation of
get_window_handle(). It creates its handle at object construction with
libgimpwidget's gimp_widget_set_native_handle() and the virtual
method's implementation simply returns the GBytes.
In libgimpUi:
- gimp_ui_get_display_window() and gimp_ui_get_progress_window() were
removed. We should not assume anymore that it is possible to create a
GdkWindow to be used. For instance this is not possible with Wayland
which has its own way to set a window transient with a string handle.
- gimp_window_set_transient_for_display() and
gimp_window_set_transient() now use an internal implementation similar
to core gimp_window_set_transient_for(), with the same improvements
(works even at construction when the window is not visible yet + works
for Wayland too).
In libgimpwidgets:
- New gimp_widget_set_native_handle() is a helper function used both in
core and libgimp* libraries for widgets which we want to be usable as
possible parents. It takes care of getting the relevant window handle
(depending on the running platform) and stores it in a given pointer,
either immediately or after a callback once the widget is mapped. So
it can be used at construction. Also it sets a handle for X11 or
Wayland.
In plug-ins:
- Screenshot uses the new gimp_progress_get_window_handle() directly now
in its X11 code path and creates out of it a GdkWindows itself with
gdk_x11_window_foreign_new_for_display().
Our inter-process transient implementation only worked for X11, and with
this commit, it works for Wayland too.
There is code for Windows but it is currently disabled as it apparently
hangs (there is a comment in-code which links to this old report:
https://bugzilla.gnome.org/show_bug.cgi?id=359538). NikcDC tested
yesterday with re-enabling the code and said they experienced a freeze.
;-(
Finally there is no infrastructure yet to make this work on macOS and
apparently there is no implementation of window handle in GDK for macOS
that I could find. I'm not sure if macOS doesn't have this concept of
setting transient on another processus's window or GDK is simply lacking
the implementation.
...and to GimpProcedureDialog.
selection-to-path-dialog.c was also removed as the code can now be contained
within selection-to-path.c thanks to the new API.
… is set.
The order for thumbnail creation in gimp_imagefile_create_thumbnail() is now:
1. If there is a GimpThumbnailProcedure, it is run first.
2. Otherwise we check if a thumbnail is in the metadata.
3. As last resort, we just load the full image.
Part of the fix was to copy gimp_image_metadata_load_thumbnail() into the core
code. I have been wondering if we could not drop the same function from libgimp
and remove the GimpThumbnailProcedure frome file-jpeg, since it just uses the
metadata thumbnail and it is the only plug-in using this code.
Also it is much faster to run this in core and it's generic function which makes
thumbnail loading from Exif data working for every format supported by Exiv2.
On the other hand, the file-jpeg thumbnail procedure also gathers a few more
useful information, such as the color model (in a reliably manner, since based
on JPEG header, unlike from metadata which may be wrong).
The various information (width, height, image type and number of layers) are
those of the full image, not of the thumbnail. Make it clear in the docs of
GimpRunThumbnailFunc.
Additionally:
- file-xmc was returning the proper information but variables were wrongly
named, which was confusing.
- Fix file-ico thumbnail proc which was returning the thumbnail width/height.
- In file-darktable, initialize width/height to 0 so that we just don't show any
size when we don't get the information. It's better not to show anything than
completely wrong information (the thumbnail target size).
We were choosing the bigger icon in the ICNS list. Instead let's choose the
bigger icon within the target size bounding box. In case there is no smaller (or
equal size) icon, we falls back to the smallest bigger icon.
Also make sure we set width and height to the full image size, as this is used
as information on the full image (not the thumbnail).
SVG is a vector format which is easy to render exactly within the size×size
bounding box. Let's make sure we do so.
This makes for much sharper SVG thumbnails (and also possibly faster thumbnail
render).
… than a GimpValueArray.
Similar to other GimpProcedure, move to using a config object. A difference is
that thumbnail procedures are always run non-interactively.
Also fixing WMF load thumbnail procedure: the dimension computation was wrong
when the image was wider than tall.
Also the palette argument is now a proper GFile argument (not a string).
There is also a palette argument for the export procedure, but it's currently
unused. A palette storing function will need to be implemented.
Some bit of additional logic cleanup was done.
Again, I am losing a tiny bit of UI, in particular the ratio fields, but also
the update of the size label (this was kinda broken anyway, as it updated only
when updating some fields, not others).
Also moving the default resolution to 300 PPI.
Last but not least, I transformed the "paths" int argument to a GimpChoice
argument.
The new dialog is not fully on-par with the old one. We lost the X and Y ratio
fields as well as the ability to constrain dimensions to each other. This should
be improved when we'll get proper automatically generated widgets for dimension
arguments.
… a GimpProcedureConfig for arguments.
This also factorizes the code to load metadata. By default, a GimpLoadProcedure
will try and load metadata from a file (if Exiv2 knows the format). The run()
function will be allowed to edit the GimpMetadata object but also the load flags
before it is actually attached to the image, allowing plug-ins to have custom
metadata handling code when needed.
This is used in the generated GUIs for GimpChoice arguments, but also for
validation of property setting.
New functions:
* gimp_choice_set_sensitive()
* gimp_string_combo_box_set_sensitivity()
This is just a method to simplify transforming a GimpChoice argument into an
enum value, which is easier to deal with, in C. It also allows to benefit from
switch() warnings or the like to make sure no cases are missing.
Developers won't have to maintain manually a list of the possible values in the
help string. It can now be generated from the GimpChoice and will be therefore
ensured to always be up-to-date, and nicely formatted.
I also add some pango markup to the type helper texts to differentiate it from
the main argument docs.
These will replace the int arguments used in place of enums. The problem of int
arguments used as list of choices is that it makes calling PDB functions very
opaque. This is especially bad when a list is long, so you constantly have to
refer to the documentation to understand what a series of numbers mean in
argument lists.
And the second issue is that plug-in developers have to manually maintain a list
of values both in the GUI and in the documentation string. This help text may
get out-of-sync, may end up with missing values or whatnot. Also if it is used
as tooltips, it makes for very weird tooltips in the graphical interface, with
an overlong technical list of int-values mapping which should ideally only be
made visible in the PDB procedure browser listing.
- GimpLabelStringWidget widget makes any widget with a "value" string property
into a GimpLabeled.
- Add a "value" string property to GimpStringComboBox (which makes it usable by
GimpLabelStringWidget).
This will be used for creating limited lists of strings as argument types for
procedures.
Ideally enums are the best type for this, but it can only be used for generic
libgimp* enum types, not custom enums created only for a given plug-in. For
this, we currently just demote the args to ints which lose any semantic. A
limited list of string will give back some semantic and some better validation,
even though it's a tiny bit more annoying to work with strings than int types
(at least in C).
Also fixes some spelling issues and removes a warning about an
uninitialized variable.
Currently the only argument is for non-interactive mode, so
the dialogue isn't ported to GimpProcedureDialog yet.
The dialog itself is ported to GimpProcedureDialog. However, the
width and height require another API that allows for size entries with
multiple fields before it can be considered finished.
As usual, these got forgotten!
Also colorxhtml is actually deeply broken by commit 89c359ce47 which removed
gimp_drawable_get_pixel() (Niels thought it was not used, whereas it was simply
harder to spot with bindings!).
This will have to be fixed eventually.
I was hoping to redesign further but the whole logic of animated brush creation
is made so complicated that I think it would require a whole more complex GUI
with visual hints. So anyway I stopped at basic redesign and port to the new
dialog generation code.
It still makes the code much simpler and a bit more powerful (also less bugs
hopefully). I have also reviewed the procedure arguments, removing redundant
ones (display-cols and display-rows are just computed from cell-width and
cell-height) and adding some aux arguments instead to simplify dynamic GUI code.
The assert tests were not taking well into account the case where upper == lower
or where it's an integer spin which is just separated by 1 (both cases seem
silly, but it makes sense in the case of generic — or even dynamic! — spin
widgets where we want to adjust the min and max, e.g. depending on the property
of the image, or on other settings.
Now gimp_procedure_dialog_get_label() can work both with an existing property ID
or a new property ID. In the former case, it will simply sync the label with the
procedure argument, which will make it easy to update the label contents. In the
latter case, it just initialize with the provided text.
It's the basic stupid port, though this dialog is so bad that I think I'm going
for a second stage with a basic redesign of this GUI while also moving to
GimpSaveProcedureDialog. To be continued.
The expectation of 2 references per object in gimp_plug_in_destroy_proxies() was
wrong. It is true during most of the plug-in life, because both the
GimpProcedure and the GimpPlugIn have a hash-table keeping their own reference
to it, except that in gimp_plug_in_pop_procedure(), we release the reference
owned by the procedure with _gimp_procedure_destroy_proxies() first. So at this
point of the object life, its reference count is supposed to be 1.
The source of the bug was in fact in _gimp_plug_in_get_*() (where * can be
display, image, item or resource) which was behaving differently the first time
it is called for an object with the successive calls. In the first call only, it
was creating then refing into the table (so the object started directly with 2
references) whereas on successive calls, it just returned the hashtable-looked
up reference. In other words, it behaved as a (transfer full) on the first call
and (transfer none) on successive calls. And so did all public API which were
making use of this infrastructure (in particular gimp_*_get_by_id() functions).
The arg "num-images" is clearly redundant as the "images" array already has this
information. Moreover it is bug-prone, for instance running 'Repeat "Filmstrip"'
would crash the plug-in which was defaulting to NULL "images" and 1 "num-images"
(without any GimpItem serialization ability yet).
Of course, we could just fix this, but better remove the redundant arg and all
possibilities of future similar bugs.
Also I now display a proper error message when running without input images
which says: "\"Filmstrip\" cannot be run without any input images"
The widget_creator_func() given to gimp_prop_chooser_factory() will create an
object which will take its own reference. We must release the one we got with
g_object_get().
Metadata handling is also integrated in this API:
* while giving a possibility to disable metadata saving if you want to do it
yourself (e.g. in file-heif), by setting a NULL MimeType;
* and the GimpMetadata object is added as run() argument, allowing one to edit
the metadata during the run, while still letting the infrastucture handle the
save (e.g. in file-jpeg);
* or to save intermediate metadata with gimp_procedure_config_save_metadata()
(e.g. in file-tiff).
While we definitely should not use this inside app/, because having the private
structure easily accessible as a member is very convenient, it is clear that it
makes for a much nicer public signature. Also the priv member is of no help to
third-party developers using this API to make plug-ins and is better hidden in
such a case.
The dialog itself is ported to GimpProcedureDialog, but the original
plug-in only had one config parameter (Number of Tiles).
Some of the other options might make sense as config parameters
such as the horizontal/vertical toggles and opacity.
I needed a few more GimpProcedureDialog widgets, which I now have. The only part
still not generated in this plug-in is the image selection. This is hundreds of
lines less!
It now has arguments for every usable setting (except "keep-height" which is an
aux arg because it is simulated with a 0 "film-height" in non-interactive mode).
Also the film-height/keep-height default in interactive mode is now much better.
I override the film-height default and set it to be the image's height. This
makes for a much better default at all time.
The "Reset" button in Advanced section is not useful anymore since we now have
the generic "Reset" (to Initial/Factory) of GimpProcedureDialog, though it
actually doesn't work right for the time being, as it fails serializing
GimpFont.
This will be useful for plug-in developers but also for us. Seeing we leak the
config object is often a good indication that something is wrong in our handling
of internal references (since everything relies on the config object in plug-ins
now, in particular all the GUI).
I was clearly confused when I wrote this. The sinking part matters to take
ownership of a reference in the widgets table, but we don't need to ref widgets
again before inserting them in containers. We were leaking widgets and as a
consequence the config object (and as a second consequence, some objects such as
resources for resource-selection widgets).
It would be worth porting when GimpDrawableComboBox widgets can be used as
GimpProcedureDialog generated widgets. Or even better, if the GimpPickableButton
were ported to libgimp to be used by plug-ins (since it's actually a lot more
usable).
I didn't port to GimpProcedureDialog because we'd need first a GimpSizeEntry
generatable widget, which can map to several properties (here for instance 3
width properties).
… working with a GimpProcedureConfig.
These are the easiest ones to port as most of the work was already done (mostly
just some now useless calls to remove).
Same as with gimp_procedure_new2(), I will end up renaming the function to
gimp_image_procedure_new() once all usage of this function will have been ported
to the new function using GimpProcedureConfig instead of GimpValueArray
arguments.
The one in GimpResourceSelect is a very nice example of why using config objects
is much nicer, getting arguments by their name instead of an index (which in
this case had to be tracked down by a private function to handle different
cases).
Also in gimp_procedure_config_begin_run(), make sure we sync the arguments with
the config object first thing, even in interactive and with-last-vals case
(where the args may be further overridden). This was especially important for
Script-fu scripts as the image and drawable were not provided separately, so we
need to make sure that the config file has the right values.
Otherwise we will always try to reuse previous values or use the default,
bypassing the actual passed values.
I encountered this issue while porting file-glob and realizing that the
"pattern" argument was always passed to NULL, ignoring the explicitly set
pattern.
When a procedure has no run-mode argument, we should simply not assume anything
and use the passed arguments (which is what the non-interactive mode does).
A lot less lines for the same functionalities!
This includes improvements too:
* "include-pointer" as new PDB argument;
* settings storage thanks to GimpProcedureDialog;
* it should hopefully work better in non-interactive (though it's untested).
The macOS and Windows screenshots are untested after this change, though they
should still work the same. Please report if there is any problem!
This function allows to change the sensitivity of a widget depending on the
value of another property.
We already had gimp_procedure_dialog_set_sensitive() except it was only syncing
with a boolean property, whereas the new function can compare with any property
type.
This new function is meant to replace gimp_procedure_new() when all plug-in
usage will have been switched.
This function creates the GimpProcedureConfig object on behalf of the plug-in
and calls gimp_procedure_config_begin_run() and gimp_procedure_config_end_run().
This way we ensure that all plug-in calls with successful result are properly
stored without asking the developer not to forget to call these (if a "good
practice" is in fact something we request to do every time, especially for good
user experience, we might as well make it rather a core process).
Advantages:
* Better interactive experience: using any plug-in will result in saved
previously used settings.
* for developers, working on config objects is also much more comfortable than
working on GValueArray;
* step forward for the future macro infrastructure: if we can ensure that all
plug-in calls are properly logged, then we can replay plug-in actions, in
NON_INTERACTIVE with the same settings.
Resolves #10069
Currently, the DDS header information for the width, height, and bytes per scan line
are read in and assumed to be correct. As these values are used for memory allocation
and reading, it would be good to verify they do not exceed the file size.
This patch adds a condition after the header is read in to verify those values. If they exceed
the file size (mins an offset), the file is not read in and an error message is shown.
Resolves #9996.
While GIMP has background-colors set for specific buttons,
it did not have a default button background-color. This resulted
in "random" buttons showing system theme colors like the
[Reload Current Theme] button.
This patch defines a default background-color while leaving the
specific button themes intact.
This adds a border when hovering over icons in various
grid views (brushes, gradients, etc). This makes it more
visually apparent which option you can click to select.
Also refactoring: extract two functions
Add test case scripts/test/register-fail
Catches more registration errors.
Any errors not caught at least will not crash.
Remains to be ported to 2.10, but only a few lines, without the refactoring.
The bug is in fact in GTK. "image-missing" is supposed to never missing since
GTK embeds an icon as GResource. But it turns out that the code is buggy. So if
an icon is missing from GIMP theme, then system theme, then "icon-missing" icon
as well, GIMP crashes.
See: https://gitlab.gnome.org/GNOME/gtk/-/issues/3526
As a workaround for now, let's at least add our own "image-missing", at least in
our main themes (Color and Symbolic, not Legacy). This will make GIMP not
crashing at least by default when another icon is missing.
Of course a crash could still happen if one use Legacy or a third-party theme
and if their system theme doesn't contain "image-missing" as well, until GTK is
fixed.
This localization was added recently but it was not in the installer scripts.
Discovered with unit testing: meson test gimp:build / windows-installer-langs
Though GTK+3 is supposed to take care of scaling fonts with high density
displays, it turns out it is not enough for many, for various reasons (taste,
eyesight, distance to the display…). So we add this additional settings to tweak
further the font size.
With Aryeom, we experimented/discussed both a percentage UI vs. an absolute font
size field (e.g. as they provide in GNOME Tweaks). In the end, we went for a
percentage UI because we realize that we don't necessarily know what is the
current size at all. Mostly you just want bigger or smaller, and don't
necessarily care so much at which value is the font size.
This settings only has a single limitation (that we could find), which is when
used on a theme with widget rules using absolute font-size rules (px, or
keywords such as small/medium/large). As long as the CSS rules are relative
though (either to the parent widget, or to the root size), then it works fine.
Basically a theme hard-coding font sizes won't fare well with this settings, but
since we can consider this bad practice, it's an acceptable limitation.
GTK docs is pretty clear:
> It is a programmer error to pass an invalid accelerator string. If you are
> unsure, check it with gtk_accelerator_parse() first.
So now we verify validity of accelerator strings before using shortcuts from
config files (which can be consider "human input" as the file can be modified).
A first attempt at fixing this was going through the idea of changing the
concept of radio actions, such as allowing an active action in an action group
to be called again. Or having some action in the radio group which can be called
but never set active.
But in fact, I just realized that these zoom actions are simply not meant to be
radio actions. They are not stateful actions, nor are they exhaustive.
I also updated the `other_scale` storage logic. Instead of updating it each time
the zoom changed (which was even broken in some cases, like when changing zoom
through another action), I simply save the last custom zoom value. This is the
one which is reused across calls. I don't think always resetting to the current
zoom value is very useful (if you call this dialog, it's not to zoom to the
current zoom!). Also there was some concept of flagging this stored zoom value
as "dirty" by making it negative, but this was never actually used, which makes
me believe that current logic was not the original intent anyway.
Saving the previous custom zoom explicitly set seems to be a good enough
behavior, so let's go with it.
Resolves #10072.
The current PSP palette loading code does not check if
the file's palette entry count value is below the limit
(G_MAXUNIT32 / 4 due to each color being 4 bytes long).
This patch adds this check and stops loading if the count
is larger than GIMP currently supports.
Resolves #10071.
When reading RLE compressed data, a buffer was allocated to 127 bytes.
However, it can potentially be used to read 128 bytes, leading to a
off-by-one vulnerability. This patch allocates 128 bytes to the buffer
to prevent this from occurring.
This fixes 2 issues:
1. gimp_scanner_parse_string() may fail, which here would indicate broken input.
If it does, the string variable would not be set, so we need to initialize it
to NULL, otherwise freeing it could crash GIMP.
2. The variables set by gimp_scanner_parse_string() must be freed.
While I was testing some fonts I had on my system which were named exactly the
same, I also realized that all their fields were identical (among the ones we
store at least), except for the hash obviously. While the hash is great to
differentiate fonts when we use exactly the same files, there are various
reasons where one could have the right font installed with a different hash
(e.g. a simple reason could be if it was stored in different font formats).
So I'm thinking that maybe we'll want to add more fields in the future (if there
are any more fields allowing to better discriminate among some fonts named
similarly). This commit will allow this version of GIMP to still work when
loading the future serialized fonts with new and unknown fields. The unknown
fields will be ignored but at least it will still do its best to find fonts with
the known fields. Therefore we won't have to bump the XCF format version if we
only add new fields.
Similarly this allows to add the fields in-between, reorder existing fields or
even remove some in the future if we realize something is really unneeded. It's
less a big deal than the ability to add new fields without bumping XCF version
though.
Rather than looping fully over the full list of fonts once more, and
re-computing a second time the same font similarity score (with the risk of
messing up the copy-paste), let's just store the indexes of "most similar" fonts
in the first loop, then only query and check the hash for these.
Resolves #8756 (along with !1065)
The system theme leaked due to the checkbox styling not being
defined for GtkTreeView checkboxes.
The background-image in particular overpowers other settings.
The normal checkbox styling is now specifically applied to
these checkboxes as well.
This is not the main reason for the specific output in #9994. These ones are
more probably because of similar usage in GTK (which updated its own calls to
g_file_info_get_is_hidden|backup() in version 3.24.38). But we should likely
also update the various calls we have to use the generic
g_file_info_get_attribute_*() variants.
To be fair, it is unclear to me when we can be sure that an attribute is set.
For instance, when we call g_file_enumerate_children() or g_file_query_info()
with specific attributes, docs say that it is still possible for these
attributes to not be set. So I assume it means we should never use direct
accessor functions.
The only exception is that I didn't remove usage of g_file_info_get_name(),
since its docs says:
> * Gets a display name for a file. This is guaranteed to always be set.
Even though it also says just after:
> * It is an error to call this if the #GFileInfo does not contain
> * %G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME.
Which is very contradictory. But assuming that this error warning was
over-zealous documentation, I kept the direct accessors since they are supposed
to be slightly more optimized (still according to in-code documentation) so
let's priorize them when we know they are set for sure.
Resolves #10015.
The border color of the menu checkboxes was not
specifically defined by the CSS stylesheet, causing
the boxes to appear invisible when unchecked in
certain system themes. This defines the border color
to the same as the menu text to ensure visibility.
Resolves #10007.
The menu separator color was not defined in the stylesheet,
so it could vary based on the system stylesheet.
It is now set to @stronger-border-color.
Resolves #10040.
A System Theme leak could cause a large border to be drawn around
the export options at the bottom of the Save Image dialogue.
This patch defines them specifically as 1px border with the
@strong-border-color CSS styling.
Resolves #10000.
The border around notebook headers was not specifically defined in
GIMP's CSS stylesheet, so if the system theme used a different color this
would also change. It has now been defined as @strong-border-color.
The existing CSS was also moved to the same area as the other notebook
header definitions.
Resolves #10020
For some reason, not having the border-radius CSS style set
in widgets inside scrollwindow viewports causes them to have
a giant black order if they're not a full height. This was previously
fixed for GtkGrids. This patch fixes it for GtkBoxes as well, such as
the Procedure Browser description area.
Per @Wormnest comment on ACB palette loading,
g_utf16_to_utf8 () now uses the string length rather than -1 to prevent malicious non-NULL terminated strings.
This commit and the ones prior are simple refactoring,
with no intended functional changes.
In anticipation of enhancements 9608 and 8404
which make returned values more scheme like.
Also makes code more readable.
- g_str_equal() doesn't have the proper signature for g_slist_find_custom() so
current code was never processing multiple subfonts in a markup layer text.
- Escape the font name parsed from the XCF. For old XCF format, it could contain
forbidden characters. And even for new XCF files (with fonts names generated
such as 'font123' so there should be no escapable characters), we should not
trust that the XCF/parasite contents is correct. It can be wrong for various
reasons.
- Search for ' font="%s"', otherwise the search-and-replace might catch other
XML attributes. For instance we don't want the font "ultrabold" to match
weight="ultrabold".
- The backward compatibility code didn't have code to stop 2 font name
replacements to chain up, i.e. if a real world font was named "gimpfont123"
and another "gimpfont321" and if our replacement code were to change
"gimpfont123" to "gimpfont321" then "gimpfont321" to something else. In the
end, we'd have only a single font. I am fixing it by replacing " font=" to
" gimpfont=" then only correcting the attribute name at the end. This
intermediate attribute name acts as a "done" flag.
There are 3 fixes here:
1. First, searching for "\"GimpFont\"" to determine whether or not this is a new
format text parasite is not enough, because this string can be found in a
text layer with "GimpFont" only as contents. It will serialize as:
> (text "GimpFont")
Instead search for "(font \"GimpFont\"" which cannot be created as part of
the text contents because of the unprotected double quotes).
2. We must verify that strstr() did not return NULL when searching for markup
delimiters. It may happen if the parasite contents is invalid (we must always
assume it can be, since it's user data).
3. When deserialization of a text from parasite fails (e.g. because parasite
doesn't actually exist or its format is wrong), still make sure the GimpText
has a font (setting the standard one before deserializing). Otherwise GIMP
crashes down the line.
For this, I also had to fix gimp_config_deserialize_object(): the object type
name must be parsed even if an object was already set in a GObject property.
The new parasite format cannot be loaded by old versions of GIMP. This means we
must bump the XCF version (even though technically we didn't really touch the
XCF format itself because text layers are stored in a hackish way, yet text
layers are just too important nowadays to not care).
Nevertheless if an old XCF with text layers was loaded and the text layers left
untouched, the old parasite will be saved back as-is. Therefore no need to bump
the XCF version in this specific case. Only when we created new text layers or
edited existing ones.
New code uses pango_attribute_as_font_desc() which appeared with Pango 1.50.
Since it's currently present in Debian stable, I don't bother too much and bump
this dependency.
Also let's use the same version for pango, pangocairo and pangoft2. They all
come from the same project/repository, so we must likely expect them to be equal
(if they are not, there is likely a problem).
Previous code was incrementing the similar_fonts count each time we found a
better candidate. So we ended up computing the hash even when we had only 1
candidate with maximum similarity.
Moreover this commit fixes a crash happening with the "standard font". The
lookup name must always be allocated, even when it's an empty string (otherwise
it crashes at free).
Additionally this commit factorizes the code so that gimp_font_get_hash() takes
care of hash computation instead of duplicating code.
Finally I do some code organization.
MR #1011 breaks that because now we have a display name
and a lookup name, so font info is saved in the xcf file,
and when loading, the font which matches these info is used.
This doesn't fix pango markup having the wrong fonts names.
In GimpText, The font used to be stored as a string containing its name,
Now, it is stored as a GimpFont object, which makes more sense and makes
operations on fonts easier (such as serialization).
Adds a class "gimp-offset-area-frame" to the frame containing a GimpOffsetArea in resize dialogues.
This allows the styling from 2.10 to be applied to indicate canvas size when resizing layers.
Since GimpOffsetArea is a GtkDrawingArea object, it can't have CSS directly
applied to it - that's why the class is added to the frame instead.
GIMP's .gpl palette format and Swatchbooker's .sbz format can contain
metadata on the number of columns. This value was ignored before;
now the import dialogue checks for this value and uses it.
from plug-in
I get a critical error when calling gimp_text_layer_new and the function
doesn't return a GimpTextLayer:
(file-psd:47120): LibGimp-CRITICAL **: 16:00:59.035:
gimp_gp_param_to_value: type name GimpTextLayer is not registered
Adding the above line to libgimp/gimp.c fixes the problem.
This was a regression appeared with commit 1b3af8a89b. We still don't want to
flush the whole image, but if the selected layers change, we want to flush the
display shell.
Filling with Middle Gray requires getting the image format
for conversion from CIE Lab. This works when filling a layer,
but new images are not yet available in the context.
This adds the image to the context before gimp_drawable_fill ()
is called so it has access to the image format.
For characters outside ASCII:
1. repr is wrong in REPL
2. sharp constant #\<codepoint> fails to evaluate
3. sharp constant hex #\x<hexdigits> accepts invalid UTF-8 codepoints
4. a call to error with such a character eats the output string
Also, changed the repr of ASCII control characters (was #\x7)
to their unicode repr (now a box glyph with hex)
Test framework and tests in Scheme, and portable.
Work in progress. Expect commits for more tests.
Testing framework is stable, more or less.
Add more tests
Add tests layer and layerMask.
test Item methods
More tests, selection
Test memory, vector in TS.
More tests char functions
sharp expr tests
Generating the devel docs fails on Windows because it can't find
Babl-0.1.gir, which is only available for me in GIMP's prefix.
Adding that path with -add-include-path fixes the issue for me.
While `length` is always assigned a value by gimp_color_profile_get_icc_profile (),
some compilers don't recognize this and warn about it being uninitialized.
This assigns six instance of `length` to 0 when declared to remove the warnings.
Exif tags Exif.Image.Artist, Exif.Image.ImageDescription, and
Exif.Image.Copyright were not being synchronized with their Xmp and
Iptc.IIM equivalents in the metadata-editor.
This commit adds synchronization of reading and writing of the metadata.
We adjust the struct for equivalent_metadata_tags by removing unused
fields and adding a field that points to the equivalent Exif tag in
a new struct called exif_tag_info.
On loading of the metadata tags we now also check a limited set of
Exif tags. If no value was set yet, we use the Exif value, or else
we check to make sure both had the same value. If not, print a
warning in the terminal.
On saving of metadata, we now also save to the marked Exif tags, or
if the value is NULL, we remove the tag.
In passing, we also fix two memory leaks by freeing with g_strfreev
temporary string lists.
Dates in Xmp include a time and timezone, so add a default time when
selecting a date since we can't edit time and timezone yet.
So far, we didn't take into account that IPTC-IIM has separate date
and time+timezone values instead of the combined value in XMP for
DateCreated.
When loading DateCreated check if it has the same value as IPTC
values DateCreated and TimeCreated combined. If not, we show a
terminal error and ignore the IPTC values.
If neither Xmp nor Iptc has a DateCreated, then use Exif.Photo.
DateTimeOriginal combined with OffsetTimeOriginal to set an initial
value.
When saving, synchronize with IPTC-IIM by splitting the DateCreated
value in date and time+timezone and save each to the appropriate tag.
Also make sure that for IPTC-IIM the date separator is a '-'.
Adds a bottom margin to the grids because the horizontal scrollbar
was overlapping the bottom-most row of the grid.
Adds wordwrap and left/right margins to multiline text widgets,
mainly to make the text not start right at the edge of the widget.
We were using a string for the metadata mode, meaning we had to compare
string values in a lot of places.
We simplify and probably speed-up comparisons here by replacing the
mode string by an enum value.
The only place still needing the string values sometimes is
metadata-impexp.[ch] where we added a conversion table to convert
the mode to a string.
to fix the issue when 'Standard' can be actual font from the list
or a font which starts with. (ie. Standard Symbols PS)
Fixes: #3104 (GNOME/Gimp tracker)
OpenEXR allows for arbitrary channel names. Instead of failing once the common ones are checked, this patch
checks the number of channels in the file.
If there is only one channel, it is treated as
grayscale (similar to OpenImageIO's behavior).
A debug warning with the channel name is also printed.
When replacing a selection, take and apply markup (if any)
from the first character of the selection for the entered
text.
This fixes the case when you no longer can change the
global layer text properties after replacing the text.
Also, this changes the behavior introduced in #1220.
Fixes: #7948 (GNOME/Gimp tracker)
Organizing sub-dependencies into modules helps. Later if for instance we need to
remove or change OpenEXR, we know that they are related and that Imath can be
removed if we remove OpenEXR.
The targets were just being left floating, and the pre-generated in-tree
source were always used instead
When bison/flex are found, ensure we actually dep on their output - thus
actually running the targets - and only use the in-tree copies as a
fallback
After discussions on IRC with ender/Jernej and frogonia:
* exchndl.dll (drmingw) requires dbgcore.dll and dbghelp.dll which seem to ship
with win10+, but not win7 (we don't know for Win8). So for Win7, Jernej had to
manually add it back (otherwise, building then running on Win10, it looks
fine, but GIMP fails to start on Win7).
* MSYS2 dropped Win7 support anyway and supports now Win 8.1+.
See: https://www.msys2.org/docs/windows_support/
So even though it looks like GIMP works fine on Win7 (after special-casing the
2 DLLs above by adding them manually in the installed files), there might be
unforeseen issues in the long run.
* Win7 official support by Microsoft now ended. And Win8 support is soon to be
(it actually already has, "except for Server 2012 [based on Win8], which's
supported for another 2 months"). Win8 never had much adoption anyway.
* frogonia confirms they didn't see many Win 7 reports, if at all, in the last
year.
So based on all these, and in order not to make our life over-complicated, we
drop Win 7/8 support for the next 2.99 versions and for the upcoming stable 3.0
series.
Though we keep support to these versions in the 2.10 series, in order not to
disrupt current usage too much.
Crossroad repo was finally moved to Freedesktop.
See: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/477
This should avoid the too many failures we have lately on TuxFamily
infrastructure (and also gives a proper bug tracker for Crossroad). I am very
thankful to TuxFamily for all these years! :-)
Let's not be said that I moved the repo because I don't like this friendly FLOSS
host anymore. I just needed something different for Crossroad project now.
Some fonts which pango identifies correctly, became broken
after renaming them in fontconfig, so the strategy was to
rename only fonts which pango can't see.
To check if pango got the correct font, the PangoFont
has to be loaded from PangoContext, which is costly.
It Turns out that querying FontConfig with more attributes
fixes this. Hence renaming every font doesn't affect
the fonts pango already sees.
We use fontconfig directly to rename fonts to fix some issues
with Pango (see MR !1011), and fontconfig is present on all
platforms supported by gimp (even on windows, pango is build with
fontconfig as a dependency), so it makes little sense to keep this
code path which is now never used.
in gimpchannel-select.h
Looking at the version in gimpchannel-select.c, the calls made to it,
and also what is usual, the corner_radius_x should be before
corner_radius_y.
Found looking at the cppcheck logs.
When changing the width we got a division by zero crash because we
did not consider the case of bpp * bitspp being less than 8.
To fix this we check if bitspp is less than 8 and in that case multiply
the amount of bytes by 8 and then divide by the number of bits per
pixel.
When building using MSYS2 CLANG64 profile using clang 16, we get the
following error (besides other required patches):
../../gimp/app/widgets/gimpwidgets-utils.c:931:12: error: incompatible
pointer to integer conversion returning 'HGDIOBJ' (aka 'void *') from a
function with result type 'guint32' (aka 'unsigned int')
[-Wint-conversion]
For now, let's use the same GPOINTER_TO_INT macro we use in
gimpprogressbar.c. In the end, we need a 64-bit type available to
plug-ins, but that needs more work.
Resolves issue #9809, fix by @mareroqpoland.
When "Separate Layer" is selected, the entire drawable is always
filled rather than using the selection. This patch uses the selection
instead (which will be "all" if there is no active selection)
Looking further, the @help is only used in gimp_proc_view_new() so far (for the
Procedure Browser) where the blurb and argument descriptions are already
localized. It makes no sense to only keep this in English. So let's ask to have
both arguments translated.
Now clearly we should not ask for @help to be mandatory. Very often, it makes no
sense to have a longer help string (the small blurb and the few arguments may be
very self-explanatory). So I make this argument nullable.
There is only the @help_id which I wonder if we could not have a simpler
function gimp_procedure_set_documentation_uri(). Indeed while having a unified
infrastructure with a XML summary and help IDs and whatelse makes sense for GIMP
as a whole, I think that many third-party plug-ins would work much better with a
very simple direct URL. Or it could even be a GFile to a local file (for
plug-ins which want to embed their documentation in the plug-in folder for
instance). To be continued…
I add a new class method deserialize_create() to GimpConfigInterface which
returns the GimpConfig object per deserialization, instead of modifying an
existing bare object.
This matters for cases like our GimpResource (and later our GimpItem) classes
which are fully managed by libgimp and should be unique objects per actual
resource. It should even be possible to compare the pointer itself for identity.
That's why we need to let GimpResource create the object (in reality request it
to the infra and only ref it) through this new class method.
With this commit and the previous ones, all GimpResource are now properly stored
as plug-in settings (e.g. the "film" plug-in has a font setting which is now
properly remembered).
These identifiers are not portable (across various installations and therefore
not for XCF either), but at least they are reasonably identifying data on a same
installation (unlike GimpResource's int ID which is only valid within a single
session) which makes them very fine for plug-in settings storage.
When a data file disappears, we fallback to the context default data instead.
This finds the core resource knowing its type, name, collection and internal
state (in other words, the values returned by _gimp_resource_get_identifiers()).
The way we were creating a GimpData identifier was simply wrong, because it was
based on the assumption that the source file uniquely identifies a GimpData (cf.
gimp_tagged_get_identifier() which clearly says that the returned string must
uniquely identify this data). The very simple counter-examples for why this is
a mistake to consider a data file to be a good unique identifier are collection
files. For instance, TTC files (TrueType Collection) contain multiple fonts.
Instead I am adding the concept of "collection" with the assumption that
**within a given collection**, data names are unique (I do hope this to be and
stay true). So I add gimp_data_get_identifiers() and gimp_data_identify() to get
identifiers and check for identity.
The collection will use the old implementation of gimp_data_get_identifier()
because it is quite nice to have paths relative to data and config directories
(it allows some cases of data relocation without losing data identification).
The new implementation to compute a GimpTagged identifier on the other hand will
construct a string from the quality of being internal or not, the data name and
its collection.
Rather than reimplementing the same checks for every possible resource data
type, just do it once and redirect to the correct factory container.
For the libgimp API, we leave per-type functions `gimp_*_get_by_name()` (where *
can be brush|gradient|font|palette|pattern so far), but internally they all use
gimp_pdb_get_resource().
Note that eventually we want these functions to return a list of resources as it
should be possible to have several resources of a given type with the same name
(since they are made by third-party who might have had the same idea of a name).
… fails.
This happens for plug-in settings storage. Serialization stops at first failed
property serialization, whereas we could store more. This feels like the last
settings feature is broken.
(except from the aliases "Sans-serif", "Serif" and "Monospace")
The code to get the file path was inspired by code in MR !1011 by Idriss Fekir.
My initial idea was to use FcFreeTypeQueryAll() when adding each font
individually through FcConfigAppFontAddFile() but we were only doing this for
our additional directories (not the system ones) and also before we actually
loaded all the fonts through FontConfig. So this would have required more work
to get right. Though it also means that now the ! USE_FONTCONFIG_DIRECTLY code
path is more broken than ever (as we consider this path information quite
important for plug-ins now).
Additionally to make this work, I got rid of the code making all GimpFont
objects internal data by default, which is nonsense to begin with. Fonts are not
writable by GIMP, sure, yet they are external to GIMP and loaded from a file!
This will be important for an upcoming commit (which is currently in a branch
related to issues #50 and #9250), where we want to implement GimpResource
storage as plug-in settings, because fonts were the only GimpData without a file
and we are using this information to generate a collection identifier.
Note that there is a `container_obsolete` too in GimpDataFactory and I don't
apply the "unique-name" property to it because I'm unsure what it is.
Furthermore, eventually we'll want all types of data to allow duplicate names
(brushes, patterns or whatnot may come from all sources and may be named the
same by different people). But for now, let's focus on fonts before breaking
other parts of the codebase which we might not look into right now.
… the GIMP_DEBUG_FONTS environment variable is set.
Turns out nearly a thousand font files get ignored on my installation (and I
don't install much; a lot of them seem to be bitmap fonts (PCF) in a X11
directory). I still want output so that this topic doesn't get forgotten and
hopefully some day, we can do better. But a single line on stderr (and an
environment variable for details) is enough for now.
Remap font names to unique generated names
so that pango sees them.
keep the font name for display and the internal
name for everything else.
* Fonts are still broken When exporting to pdf
* Not sure if xcf files would be usable on other systems
maybe use hash of psname internally instead
* Not sure if plug-ins using text layer work correctly
(do they use internal font name or the actual name?)
This is definitely not core type material. Also it's much better in the proper
header gimpimage-snap.h and the type name should reflect the file namespace,
especially as we make it public.
When using airbrush tool, if the layer has a offset, then the offset was
applied to the the coords multiple times creating a series of dots when
holding the airbrush still (from the gimp_airbrush_stamp function).
Fixed this problem by storing the original value of coords before it
gets updated.
Inline completion is case sensitive, this makes it
broken, because fonts desplayed in the pop should be
quried in a case-insensitive manner.
This fixes #2832.
See gtk issue #275.
We use US English which uses behavior. So we replace all occurrences of
behaviour.
Most notable is File Open behavior in preferences. Besides that several
mentions in function documentation and a few in comments.
...the tab itself. Noted by @user062. This adds a right margin to the
close button on the image tabs so that the tab size is pushed out
to fit the button.
Use the dedicated function rather than comparing strings.
Because of this, menu items for the "windows-display-*" actions were not
destroyed, neither were the relevant images because the proxy menu item was
keeping a reference to the image (for the small in-menu preview in Windows
menu).
It's nearly the same list of placeholders which will make it easier to
third-party developers (though format still changed, devs will have to add
square brackets for section names).
Now some section names are missing because we would need to break some list into
smaller sections yet want to avoid having separators everywhere. This makes me
wonder if removing my first placeholder implementation was the right idea.
Anyway this new implementation is cleaner and we should find a way to add
sub-sections without creating separators in menus.
Also I didn't try to add new section names (though I did once or twice, e.g. a
"Close" section around quit/close actions which didn't exist) but eventually we
should. Being able to name logically parts of the menus will make them even more
organized (if we can't name a group of actions, it may mean we didn't think
properly the organization and order).
Per @ajonsson, gettext does not like < or > used as symbols
and throws a warning. They are replaced with HTML entities
< and > to prevent the problem.
These should be hidden on stable releases and shown on unstable branch. But
we'll also want to show these in the stable branch, outside of release
(typically when we'll be at 3.0.1).
The combo box button is contained within a box element.
The box was also having its background-color set,
so there were small square "corners" around each dropdown menu.
This patch separates the box color from the button color to prevent
this.
"Windows" and "Help" should always be last. New top-level menus (created by
plug-ins, scripts or GEGL ops) will be appended in the order of creation between
"Filters" and "Windows" menus.
There were some mixups between a few representations of menus:
* "_Some Menu" and "Some Menu" should both map to an existing submenu "Some
Menu" (in the GimpMenuModel, the stored path doesn't contain mnemonic).
* The menu item on the other hand should contain the mnemonic and not lose it.
* Not only this, but "Some _Menu" should still map to the same menu, even if it
was already created with a different mnemonic. It means that the first
registered menmonic "wins", as we don't want duplicate submenus with same
title (even if they have different mnemonics).
So this new code is better handling the canonical menu path (no mnemonic, no
section name, no double slashes, no trailing slashes, etc.) vs. the
canonical-with-mnemonic menu path to avoid weird duplicates.
Some additional bugs are fixed where we were creating weird empty submenus
containing the same items as the parent menu as well, or when a submenu title
was a perfect prefix of another submenu title at the same level.
File/Quit, Edit/Preferences|Input Devices|Keyboard Shortcuts should not be in
the main menu bar on macOS because they are already in the "app menu".
See #9322.
- Remove the wiki which is now dead.
- Update the roadmap link and title it in plural.
- Move the "Bug Reports and Feature Requests" inside "GIMP Online/" submenu.
I'm not sure what's the default for random string attribute, but better be
explicit anyway. I think this way, we make sure that gettext won't try and
translate these.
This removes a bunch of inconsistencies we had from the before-2.99.16 version
because new items from plug-ins were all added at the bottom of their respective
submenu.
This will replace the "placeholder" concept where I was using an invisible item
with a label and no action, making it invisible. Instead let's just name
(internally) our sections. This has the following advantages:
* Conceptually more correct: basically we just want to place items among the
same category of actions.
* Easier to search for plug-in developers who'll want to place their plug-in
procedures in menus, because it uses an actually searchable attribute
("section-name").
This is used by the core by allowing a special syntax in menu paths: if finished
by "/[Section]" then the item will be place in the specific section named
"Section". In case one actually wanted to create a submenu called "[Section]",
they can use a double bracket: "[[Section]" and "[[Section]]" will both map to a
normal submenu (not a section name) titled "[Section]".
All other usage of square brackets will not be processed in a particular way.
E.g. "Hello [World]" will end a submenu titled "Hello [World]" or "Bye]" will be
a submenu and so on.
Finally this system is currently limited to the position of the item itself,
i.e. must be placed as last element in the path. In particular, you currently
cannot use it to position a new submenu inside a section. E.g. say that I want
to create a submenu "From Platforms" under the "Open" section of the File/ menu.
This is currently impossible. With this syntax, we can create new items directly
in the "Open" section, or create a "From Platforms" submenu in the end of the
File/ menu, containing our new procedures.
This could be a good improvement to come.
Sphere-designer: Since some of the strings are translated versions, we
can't know in advance how long they are going to be.
Let's use string copy/cat functions that explicitly check the size and
are guaranteed to add a NULL.
- Add modern error handling using GError.
- Check return values of fseek and fgetc for errors.
- Remove most occurrences of g(u)long.
- Fixed overflow issue with maxred/green/blue found with coverity.
I noticed this in coverity. I couldn't find any actual script using
SF_DISPLAY, so the impact probably isn't very big.
Because the enums start at 0, the size of the array should be at least
one more than the value of the last enum, which was not the case here.
Increase the size of the array by 1, so that accessing SF_DISPLAY,
which is the enum with the highest value, is valid.
Resolves #5742.
The check is for a horizontal line (where the Y coordinate
would be the same for all three points), but the X axis was
checked instead due to a copy/paste error.
Resources are stored by the plug-in infrastructure and their memory should not
be managed by plug-in code.
My commit 4f69995b46 was crappy and modified a generated function. I was just
too tired with all the heat in here, I guess!
Similarly to how we handled image items, all resources are handled and stored by
the plug-in infrastructure and should not be destroyed. This wrong annotation
was triggering bindings to unref resources when going out of scope, hence
crashing plug-ins.
Note that in the future, we expect this to be possible to create other brushes
with a same name. Maybe we should have a special function allowing to request
core resources (the ones installed by GIMP itself).
Adding unsupported messages was overwriting the old message without
first freeing it. In addition, the first message was initialized
as a string constant.
We now start with duplicating the (empty) string, so that it can be
freed. We then add a define to reduce boilerplate to add the string
for each unsupported feature. The code in this define takes care of
adding the new message and freeing the old message.
Make sure we use gsize for intermediate results to not get integer
overflow on large image sizes.
This still is not ideal, but better than a crash, since we may (try to)
allocate a very large block of memory, which we should eventually fix
by looping over smaller size buffers.
Brushes can't be large enough to actually cause overflow here, but
since the result is gsize, it can't hurt to have the intermediate
results to gsize too.
Though I didn't encounter this bug in my commit 54b22c717a, 2 unit tests are now
failing with:
> Bail out! Gimp-Widgets-FATAL-CRITICAL: gimp_ui_manager_update: assertion 'GIMP_IS_UI_MANAGER (manager)' failed
I am assuming this is a consequence of this code I just changed.
This GTK widget code could be reach from a thread calling gimp_image_flush().
Yet all GUI-related code must happen in the main thread (also even though
actions are not GTK code anymore, they can trigger GUI updates).
No issue happened from this so far (that we know of), but a trace by SBDaule for
their growing layer project showed that we'd reach this code if calling
gimp_image_flush() from the paint thread.
It looks like we left out the multiplication by 3 when passing the
colormap size to get to the number of bytes in commit 89c359ce
This fixes a crash when saving an XPM file
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/9711
After 59cb3e36, the GimpOverlayFrame that contains
the on-canvas text editor is still partially visible as a dot.
This patch now hides and shows that as well based on
the "Show On-Canvas Editor" option.
Resolves #9676.
Per @pixelmixer and @programmer_ceds's research,
setting the color attribute on the switch's image children
removes the 1/0 labels on non-System themes.
This was introduced in commit 95fa902827. Unfortunately Gitlab web UI is really
not good at showing indentation issues (or any other space coding style issues,
for that matter).
This results in an infinite loop and there is no change done, so no reason to
flush anything. Mitch had a fix for this (probably the same, per the IRC
discussion), but I really wanted to just release GIMP 2.99.16. So Mitch, if you
read this, sorry for not waiting for you to push this one!
We already search for a compatible Python version in the root meson file, no
need to look up Python 3 again in the PATH, each time we run an external Python
script in the build.
This should hopefully fix #9687.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/9653#note_1780587
Looking at MSYS2 logs, it looks like they very recently "fixed" the search paths
for lua files, which in turn broke our workaround (searching in subdirectories
of bin/ instead of share/ and lib/).
This should work better (though untested) with the workaround removed now.
Commit on luajit package at MSYS2:
703c7bae2f
In commit 48c27770 some unicode related changes were made. As a result of
that on Windows display_device, which was previously a duplicated string,
is now referenced directly.
However, the g_free was not removed, causing a crash.
We resolve this by removing the obsolete g_free.
Switching to the cfitsio library's fits_read_img () function in 03ea666f
caused RGB FITS images to be read in upside down per SiriL developers and
NASA standards (odd, since cfitsio is maintained by NASA). This flips them back.
The Microsoft style guide and other places online suggest that using a
hyphen is recommended between a number and the related word, when modifying
a noun, so let's do that in our Image -> Encoding submenu too.
The developers of SiriL sent me some RGB FITS images that rendered incorrectly
after d4f42076. These must be read in as
planes rather than individual rows.
The creation of the BMP welcome images for the Windows installer (part of
-Dwindows-installer=true build option) fails in the Windows job. After much
debugging, I could run GIMP, yet it was not enough. One of my hypothesis so far
is that the environment variables for DLLs won't work, since all the DLLs must
be in the same directory as the main binary (though with the WSL thing, I am
unsure, maybe it is still supposed to work), which only happens once GIMP is
installed. So GIMP runs successfully but not plug-ins.
Anyway I wasted too much time working on this and without a local Windows, it
just takes too long (mostly testing thanks to the CI) and is frustrating. Let's
just move to building both the localization files and the images on the main
Debian job (gimp-meson-debian), then use these as dependencies of the
win-installer-nightly job, i.e. when building the installer.
The common order logic for list of directories in environment variables is that
left paths have precedence. This is at least the case for LD_LIBRARY_PATH (and
probably GI_TYPELIB_PATH too).
Make sure that our local libraries and introspected binaries (in the build
directory) are used and not any version installed on the system or by previous
`ninja install` calls.
This was a first attempt at fixing this error on the CI:
> Cannot open display:
Though it was not enough (see next commit calling plug-ins as non-interactive
when called without interface), it is still a useful change overall.
We had the following warning:
In function 'make_remap_table',
inlined from 'gimp_image_convert_indexed' at
../../gimp/app/core/gimpimage-convert-indexed.c:1057:7:
D:/msys64/mingw64/include/glib-2.0/glib/gmem.h:261:19: warning: argument 1
range [18446744071562067968, 18446744073709551615] exceeds maximum object
size 9223372036854775807 [-Walloc-size-larger-than=]
This is apparently caused by inlining in combination with using a signed
int.
See also: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=85783
Casting to (guint) silences the warning here.
… being installed.
There is already most of the main code logic for this, though now plug-ins need
to be in their own subdirectories, which breaks for plug-ins/common/ and
plug-ins/python/, while I needed plug-ins in both these categories to generate
the Windows installer welcome images (file-png, and python-fu-eval in
particular).
Once again, meson was not very helpful, since all its functions still refuse to
output generated files in subdirectories, so I end up duplicating plug-in files
with a custom Python script.
This should fix the CI. It was working on my machine as GIMP was installed, but
such a build rule should work even without GIMP installed.
This will also be useful in the future when we'll want to run unit tests of
plug-ins through the finale GIMP binary itself.
After discussion with Jernej, InnoSetup should now work better with rescaling
a big image properly to the window size, yet the ratio should still matter.
Apparently the welcome image is a hack and this is why it requires specific
ratio images. We don't use the big size yet, but since Jernej told me which
dimensions are expected, I already added the code for it to make it easier
later.
So anyway this code would allow us not to have to commit welcome images each
time, which are basically resized copy in BMP of the splash screen, slowly yet
surely filling up our repository with image duplicates.
After all, we develop a scriptable image editor! We should use it to edit images
and export in expected formats!
I only use this script for the devel installer for now, for testing and see how
it goes.
While some packages may be needed only when building (and others only when
packaging), we should probably have a shared list of packages needed for both
steps so that we avoid discrepancies which lead to missing libraries in our
installer.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/9653#note_1777596
Even though it's just for 3 dots, this may actually be formatted differently in
different languages. Let's not assume we all share this punctuation mark.
Fixes several missing declaration warnings because in fact of missing include,
such as:
> warning: no previous declaration for ‘console_editor_new’ [-Wmissing-declarations]
Fixes 2 old-style definitions:
> warning: old-style function definition [-Wold-style-definition]
The previous commit did fix one such reason (multiple separators next to each
other), but I realized there is one other case where single separators are just
too big: when the menu is embedded in a GtkHeaderBar, each separator would have
a weird margin of several pixels (at least in my case, probably taken from the
underlying system theme). And worse, this margin was using another background
color.
So anyway this CSS rules takes care of not adding weird margins to menu
separators.
Resolves issue with #8461.
This provides a conditional value for the fill options to only show
a color and pattern, rather than fore/background colors.
Currently only used for the text editor.
Though not a bug, this change will get rid of the following warning:
> app/dialogs/module-dialog.c:291:28: warning: ‘location’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> 291 | text[INFO_LOCATION] = gimp_module_is_on_disk (module) ?
… to long format of unit names.
We can clearly see that the main part of the widget is correctly resized but not
the popup. Unfortunately we don't have access to the popup widget which is
private data, so the best workaround I found so far was to pop the menu down and
up, which basically provokes a redraw to the correct size after contents change.
This fixes MR !385.
There was a bug in commit ca6b58e970 which went under the radar. The gimp
variable was not set at creation, so this line was crashing:
> container = gimp_data_factory_get_container (text->gimp->pattern_factory);
Since MR !706, (style solid) doesn't exist anymore which makes gimprc parsing
fails (hence losing configuration).
This fixes:
> Gimp-Config-Message: 21:20:21.018: Error while parsing '/home/jehan/.config/GIMP/2.99/gimprc' in line 18: invalid value 'solid' for token style
> Gimp-Config-Message: 21:20:21.018: There was an error parsing your 'gimprc' file. Default values will be used. A backup of your configuration has been created at '/home/jehan/.config/GIMP/2.99/gimprc~'.
Replaces "Solid Colors" option in Fill Path with Foreground/Background
Colors options. This allows users to fill with either, rather than
having to switch the foreground color each time.
GIMP_CONTEXT_PROP_MASK_BACKGROUND was added to the fill and stroke
contexts to allow the background color to be recognized.
In places where Solid Color was used as a default, Foreground Color is
now used instead.
In our use case it is necessary to save the transform matrix, and the
easiest solution is to make the label selectable. If we print the
whole matrix into a single label, formatted with tabs and linefeeds,
then the whole matrix can be copied with a single operation.
This adds a new boolean to text options, "Show on-canvas editor".
When toggled, it immediately hides (or re-shows) the current
text layer's on-canvas text editor.
It uses the same signal and function as the "use-editor" property.
With more recent logic, not all actions are inside the application's action map.
We need to look up actions in our GimpUIManager.
This fixes failing to find the actions with the "text-editor." prefix (in the
text tool editor's toolbar).
Resolves #9636.
gimp_object_get_name (gimp_display_get_image (display)) returns NULL
instead of the filename. documents_raise_display was changed to call
gimp_image_get_imported_file () or gimp_image_get_file() instead to
get the actual filename.
When porting depth-merge to GimpPlugin in 5154b271 the return statements
were not fully replicated. As a result, the depth-merge function was
called even if the dialogue had been cancelled.
This patch adds the missing return statements to prevent this.
Half of the smaller dimension seem a better value, since once we reach any half,
it means we will compute using all pixels anyway. Any width higher than this is
useless.
Adds a check to cast resolution to an int if units are pixels,
rather than calling gimp_unit_get_scaled_digits().
This prevents a LibGimp-CRITICAL about "_gimp_unit_cache_get_digits:
assertion 'unit >= GIMP_UNIT_INCH' failed"
Since commit 89c359ce47, it's supposed to return a GBytes, yet it was returning
raw data (probably intermediate hacking state which was not properly cleaned
up).
It was crashing for instance GimpDrawablePreview widgets at drawing time.
Partially resolves #7211.
plug-in-ripple is a wrapper for the GEGL ripple effect. GEGL allows for
double values for period and amplitude, while the GIMP PDB only allows
integers. This patch aligns the datatypes.
Note that Angle and Phi are still limited to the current design.
For all the test-ops thus far in gegl, gimp:menu-label has been
the same as title + "..", to keep the number of duplicate strings
that need to be translated and the number of needed boiler-plate
lines of meta-data in GEGL down, this is the default behavior when
a title key exists.
The checkbox label wasn't included the :hover CSS, so its background
color didn't change. This created a "box" around the label without the
highlight color when the mouse was over it.
My previous commit was improving the case where we just get many "dirty" signals
and successful inhibition. But if the inhibition request was failing, we would
just retry again and again.
This new version will hold off on on requesting the inhibition for the next 10
minutes. Then it will try again, in case the failure reason might have been
temporary.
… the reason message changes (i.e. when number of dirty image changes).
Some actions in particular would trigger several "dirty" signals, there is no
reason to uninhibit then re-inhibit repeatedly. And as a more general rule,
there is no reason to do so even for different actions while we are not planning
to update the inhibition reason.
It may not be the main reason for #9446 (because if it hangs for several
minutes, there is likely something going on, deeper at the dbus call level), yet
it would definitely alleviate the issue (dividing the wait by as many times as
the dirty signal was emitted!).
The RGB histogram shows three histograms overlaid on each other.
This multiples the pixel and count attributes by 3. To correct this,
the result of gimp_histogram_get_count () is divided by 3 for the
pixel and count displays.
Resolves #414.
Currently GIMP only loads the palette colors used in a GIF, discarding
the rest. This can cause issues when a consistent palette is required
(e.g. a video game sprite or background).
This patch uses either the global or local GIF max palette value to set
the colormap size, thus retaining the full palette on import.
Rename fields of ConsoleInterface more desciptive
Add c,h files for object editor and history
Extract object ConsoleEditor
Extract object ConsoleHistory
Extract TotalHistory methods
As @bootchk noted, gimp-file-load-layers does not check the result of
file_open_layers () but the final return variable
which is always NULL at this point in the function.
This patch corrects the problem so it checks the proper variable.
The order of GIMP_PROCEDURE_SENSITIVE_DRAWABLE |
GIMP_PROCEDURE_SENSITIVE_DRAWABLES was reversed in
gimp_procedure_set_sensitivity_mask (), which caused scripts using
SF_ONE_OR_MORE_DRAWABLE to crash.
… the main instance.
Note that it doesn't say if the batch command succeded, only if they were
successfuly communicated to the main process for processing.
When passing an application ID (which is necessary for application inhibition to
work, i.e. logoff/reboot/shutdown inhibition), GApplication will try to ensure
process uniqueness, which will trigger a new activation to an already running
process. Since our current code assumes that the application can be activated a
single time only, this was what was triggering a whole lot of errors (on the
first running process) in #9598 because there was all the initialization code
which ran again, whereas it was not supposed to.
This doubly-running initialization code was also what completely messed up the
session files, hence broke the GUI after a restart (#9599).
Therefore passing G_APPLICATION_NON_UNIQUE advertizes we don't want GIO to
handle process uniqueness for us.
Note that this is actually a very interesting feature which we have had in GIMP
codebase forever. It would be interesting to kill all our own uniqueness code in
favor of GIO code (and let them handle/maintain passing command line arguments
from one process to another, for all possible platforms). So I added a TODO for
this (for now, we just ignore this feature as it doesn't work well with current
codebase).
Additionally to the F1 shortcut, a secondary icon is now shown in the
action search entry. It works exactly the same as F1, i.e. that by
default, it shows the action search manual page (when nothing is
selected), or the manual page for the specific action currently selected
otherwise.
The default F1 result (if no action is selected) is to show the generic
help page for the action search. If an action is selected, it will show
the specific help for this action.
Since we are already building a static (build-only) libapp, to be used with
tests or tools, let's also use it for the main (GUI) executable.
For the CLI executable though (gimp-console-2.99), we must re-compile
libapp_sources from scratch anyway, because we define the additional macro
'GIMP_CONSOLE_COMPILATION'.
While Debian testing is the sensible choice for dependency requirements while we
are in full-dev mode, now we are getting closer to 3.0 release, and Debian 12
"bookworm" barely got out.
If we continue to develop at current pace, GIMP 3.0 should be released before
the next stable Debian, so we should not use dependencies unavailable on the
latest stable (otherwise GIMP 3.0 won't be distributable soon enough on Debian,
nor on Debian derivatives such as Ubuntu, Mint, etc.).
This is why we are now basing GIMP dependency requirement on Debian bookworm.
We'll likely get back to the next "testing" after GIMP 3.0 release.
Now that we don't blindly generate a messy list of all non-special cased actions
in Filters > GEGL Operations, "GEGL Graph" is all alone in this submenu. It just
makes sense to bring it back to the Generic submenus where it used to be.
Instead of unconditionally add all the non-special-cased GEGL operations into
the menu, only insert the ones which explicitly use the new "gimp:menu-path"
GEGL key.
See new operation "gegl:adaptive-threshold" added in commit 7c2a70eee for such
an example.
Note that the other operations will still get their own generated action (which
means for instance that you can still search them through the action search and
that you can create custom shortcuts for your favorite actions). But now you
won't get an overlong generic list of non-organized actions in a single submenu.
Some people were finding this messy when they had a lot of custom GEGL ops.
Also it means that GIMP doesn't assume that any custom GEGL op is usable in
GIMP. Indeed some ops are really not meant to be used as filters, which is why
we have the gimp_gegl_op_blacklisted() internal function; but this cannot apply
to custom operations. Therefore from now on, instead of GIMP guessing, operation
developers will have the say on whether their op should show in menus and in
which menu path exactly!
Moreover the "gimp:menu-label" key will be used as short label, i.e. the label
which is used in menus in particular, where the menu path is a helpful context
(hence allowing to use shorter menu labels).
The main "title" will still be used as long label, for places where there is no
such context, for instance the action search.
When reverting commit d51c64ec06 and reimplementing as fa2e9adc29, the code to
make sure the generated per-op action name is unique disappeared. This code
ensures that the action name is indeed unique, otherwise the action will
override a previously registed action, which could be made from a plug-in, or
even by another GEGL operation. Indeed, while GEGL operation names are supposed
to be unique, they are post-processed to be valid GIO action names. So it is
totally possible to have 2 GEGL ops with different GEGL names, yet the same
GAction name.
8bpp and below ICO formats use a 1 bit mask for transparency.
When imported the mask is treated as an additional transparent color.
If the icon used the max palette (e.g. 2 colors for a 1bit icon),
the default export format will become larger than necessary.
This checks if the layer still has 1 bit alpha, and subtracts the
mask color from the count.
This patch does the following things:
- An option "Merge menu and title bar" (this is hopefully more understandable
than calling it "Client-side decoration" or again "header bar") is added in
Preferences > Image Windows. This option triggers the restart warning.
Moreover when checked a small warning message will tell that in some cases, it
may not work (there are feedbacks of people having 2 title bars when using GTK
applications using CSD).
- For the reason evoked above (sometimes 2 title bars) and also because the CSD
concept seem really to divide people a lot (some love this as much as others
hate this), this new option "custom-title-bar" on GimpGuiConfig is FALSE by
default.
- When the option is checked, the image windows will use a GTK header bar
containing the menu, the window title (image name and information) as well as
the usual minimize/maximize/close buttons per your OS conventions.
- Since the header bar is set to be hidden when maximizing, if you checked "Show
menubar" for the "Default Appearance in Fullscreen Mode" in Preferences >
Image Windows > Appearance, the menu will be moved to its "old style"
position, i.e. above the canvas. This makes the menu possibly visible (if
relevant option is checked) even in fullscreen mode.
- I tweaked the Default theme to show the header bar with minimal height,
because I find GTK default theme's headerbar height unreasonably high
(especially if the point of the header bar is to save screen space). I am
unsure if this was the right move though, because maybe the default theme
should not do such choices (maybe this should go in the Compact theme?).
I don't see a reason why the quick mask menu was sharing the same
manager as the image menu (the main top menu and on-canvas). This was
why it was receiving all notifications to create menu items on <Image>,
as registered by plug-ins.
Giving it its dedicated manager makes sure this doesn't happen.
This reverts commit 3a35974e3a.
This is not the right fix for the issue (which was happening on the
Quick Mask menu specifically) because root menu models are set with a
NULL path. So forbidding root menu models to handle new subpath means
preventing plug-ins to register new top-level menus.
The correct fix for the issue on the quick mask menu will happen in a
coming commit.
See issue #9586.
In commits a6756b515b and 23da44e3c8, newer API of librsvg were used, over our
current minimum requirement. The reason why we don't bump this requirement is
that librsvg 2.40.x are the latest versions which are full-C. While we have
nothing against Rust, it is not available on all existing platforms, and we
really want to have GIMP buildable everywhere, while also have SVG support
always present (even though it's a vector format, it's an important one in
graphics work nowadays).
See issue #6821.
So in the end, let's keep the old minimum requirement, but test against librsvg
version to compiler either with old API or new one. The changes are limited
enough that it's not too much a bother.
...trying to get the index. Resolve #9568.
The color picker tool calls this twice if you're in Add to Palette mode,
and the editor's color may not be set the first time it's run.
This adds a check to ensure the color is set before trying to retrieve
it from the palette to prevent a CRITICAL.
Don't set both a branch and a commit, otherwise flatpak-builder will
compare the HEAD of this branch (which may evolve with the commit).
Fixes:
> Failed to download sources: module qoi: Git commit for branch master is dfc056e813c98d307238d35f7f041a725d699dfc, but expected f6dffaf1e8170cdd79945a4fb60f6403e447e020
The layer resize to selection and crop to content menu commands were
using the same help ids. This made it difficult to have them both listed
separately in the index of the manual.
Since we use separate help ids everywhere else for menu commands, let's
give each its own help id here too.
Though this doesn't make a problem in normal use (AFAICS), we have crash
in a unit test in CI because the action_factory object was apparently
invalid when calling gimp_action_factory_delete_group().
Because of this, the script was failing to get the version string, which
in turn was breaking InnoSetup.
This fixes the following InnoSetup bug:
> Error on line 116 in C:\_r\_builds\k3_3muaB\0\GNOME\gimp\build\windows\installer\gimp3264.iss: Value of [Setup] section directive "VersionInfoVersion" is invalid.
This commit makes no real changes but style.
As discussed, this makes it much easier to compare commit diffs, rather
than an overlong line where you have to search which package may have
been added/removed/changed.
Resolves #9560.
The Simulation Intent and BPC widgets in the Preference Dialogue needed
to be connected to their properties with `gimp_prop_*` when created to
show the saved default image values.
It does absolutely nothing except sitting there, providing an is-a
relation (both ways because GimpData is its only subclass). This will
simplify having more libgimp API on GimpResource, without having to
add different PDB code for app and libgimp.
This replaces the various GimpHSV/GimpCMYK .aco palette conversions with
Babl.
As a result, it now possible to support importing CIE Lab palettes
(colorspace 7)
Much like for images and items. Change the PDB to transmit IDs
instead of names for brush, pattern etc. and refactor a whole
lot of libgimp code to deal with it.
modified: libgimp/gimpplugin-private.h
The Extensions dialogue assumed that it had a header bar. Since this is
not always the case, conditional checks were added to prevent
GtkHeaderBar code from running. This also fixes a crash when you
double-click to expand the extension description.
The name of the nl-filter plug-in in the manual was recently changed to be
more in line with its description.
Since that is already the name of the plug-in file here, let's also update
the name of PLUG_IN_PROC to be in line with this.
Use g_idle_add() instead of g_timeout_add(300ms), which makes
it respond instantly, while still keeping the actual zoom
call out of the slider callback.
Fixes #9500
By doing `gimp_display_shell_pointer_grab()`, we actually prevent events
from a tablet coming through. There doesn't seem to be a reason to use
it and it's not regressing in functionality either, so let's just remove
it.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/8016
Some images have Exif.Photo.PixelXDimension and Exif.Photo.PixelYDimension
metadata tags in addition to Exif.Image.ImageWidth and
Exif.Image.ImageHeight (mainly tiff images). So far, we were not updating
these optional tags, meaning they could get out-of-sync with the actual
dimensions when resizing and then exporting the image.
Since these tags are non essential, we will only update them if they are
already present.
This way we handle all kinds of proxies (particularly buttons).
Also add a small hack that prevents extended multiline tooltips of
GimpButton from being overwritten by gimp_action_update_proxy_tooltip().
If "data" is a GimpItemTreeView or a GimpImageEditor, we REALLY want
only the image from these dialogs, even if NULL, and NOT some other
image from a display or context that randomly is around anyway. Fixes
the sensitivity states of lots of buttons in these dialogs.
According to the ::drag-drop GTK documentation: "The call to gtk_drag_finish()
can be done either directly or in a “drag-data-received” handler which gets
triggered by calling gtk_drag_get_data()"
The GimpToolbox's vbox handling DnD chooses however to do both, the drag-drop
handler is calling gtk_drag_get_data() and invariably calling gtk_drag_finish()
to hint that the DnD operation is ending. While this worked in practice in X11,
This is a harder either/or in Wayland resulting in the transfer being cancelled.
In order to behave better wrt the documentation, and make DnD into the toolbox
work on both X11 and Wayland, avoid the first gtk_drag_finish() if the data is
being requested, and only bail out if no offered target matches what the widget
can handle. The handling done indirectly through gimp_toolbox_dnd_init() and
gimp_dnd_*_dest_add() will take care of finalizing the DnD data transfers
successfully.
Closes: https://gitlab.gnome.org/GNOME/gimp/-/issues/7373
Apparently this has never worked until we refactored our menus, now it
suddenly does but not as originally intended. Simply remove the
accelerator and let only the canvas event handler deal with the Tab
key. Restores 2.10 behavior which was quite ok.
Fixes #9352
distress-selection.scm uses gimp-image-set-active-channel which has been
removed causing script failure when a channel is selected instead of a
layer.
Use the new multi-layer aware gimp-image-set-selected-channels and also
use the gimp-item-id-is-* functions instead of the deprecated
gimp-item-is-* functions.
In GimpLayerTreeView, set the action states using GimpActionGroup
instead of using gimp->app directly to look up the actions ( after
trying to get the Gimp from a NULL GimpContext).
Fixes #9433
What we call "System" theme should have very minimal edits over the
actual system theme. So let's drop all the "font-size" properties (one
"larger" one, but especially the many "smaller" ones).
This means that the "Default" theme also will keep system font size.
This is as discussed with Ville and Liam, the later saying he can barely
read dockable texts because of this.
On the other hand, we use "small" font size as a general rule in the
"Compact" theme, which is especially meant for people who want a compact
theme.
The Default theme may have been a bit too dark. Instead let's have it a
tiny bit lighter (and also foreground color a bit less white).
For now, the old "Default" dark theme doesn't disappear totally and is
moved to a "Darker" theme as we have been discussing and wondering on
whether this is prefered by some people (it is). Aryeom also thought a
darker theme may be a good idea.
Moreover Liam actually thought that losing some of the contrast
(especially with the text a tiny bit less white now) is not desired in
his case where eyes may not be as sharp as they used to. Therefore a
"High Contrast" theme may be needed.
Aryeom also suggested that sliders to choose colors could be a much more
generic solution, which might be possible yet would require more ugly
hacks generating on-the-fly theme changes (we do something similar for
dark theme choice already).
This is all work-in-progress and a result from Wilber Week 2023 work.
… for Windows.
Though it's useless for actually building the GIR files, we still need
this package now, for building script-fu with introspection abilities,
to generate GIMP and GEGL enums.
See the 2 previous commits for more information.
This allows our script-fu plugins to use the GIMP enum values, just like
all our other plug-ins know them.
In other words:
* Names are consistent with those of other plug-ins
* Introspectable enums are automatically added as they are added to the
introspection file, without even needing a recompile
* No need to keep track of our enum types anymore, as that is just a
redundant implementation of introspection in practice. This in turn
will let us simplify some of the pdb code
Currently, patterns are loaded as-is - if the full pattern is larger
than the preview, its cut off and you only see the left corner.
In those cases, the pattern is scaled using gegl_buffer_get ()'s scale
parameter.
and Plug-in/Procedure Browser size.
gtk_widget_set_size_request () is applied to the dialog, as it does not
seem to bubble up from being applied to individual elements.
The existing 2.10 width/height values are used.
getting rid of using the the deprecated pointer grab API.
Since there is something fishy and gtk_get_event_widget(event) always
returns the GtkInvisible we grab on (not the actual event widget), we
just steal the "find widget at pointer" code from gtkinspector and
find the help widget that way.
The height of the boxes was never determined by the preview but by the
label+entry, causing vertical padding around the preview. Now the
preview fills the area in more cases, at the cost of a few less
horizontal pixels for the entry.
gimp_toggle_action_real_toggle(): set "active" before emitting
"change-state" so we don't infinitely try to set the state in case of
a recursion.
gimp_toggle_action_toggle(): add notify("active") because it wasn't
done anywhere.
Fixes #9392
GLib has a specific type for byte arrays: `GBytes` (and it's underlying
GType `G_TYPE_BYTES`).
By using this type, we can avoid having a `GimpUint8Array` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GBytes`, we allow other languages to pass on byte arrays as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with byte arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
Our metadata library exiv2 only registers the most commonly used xmp
namespaces. Other namespaces need to be explicitly registered. We did not
read or try to store these namespaces, which caused a lot of warnings about
"No namespace info available for XMP prefix '...' and then we could not
process that metadata or save/export those tags.
We had to wait for gexiv2 support for registering/reading namespaces, but
that was added in gexiv2 version 0.12.2 (and the "try" version in 0.14.0).
When reading xmp metadata we process all namespaces and add them to our
metadata xml when we haven't seen them before in the same image.
A GHashTable is used to keep track of the prefixes we have seen before.
The new namespace xml tag is skipped in older GIMP versions, but will be
used now to add the namespaces when exporting images with xmp metadata.
TIFFs with PSD layers can be saved in either Macintosh or IBM PC format.
IBM PC section labels are reversed and the integers are Little Endian.
We now check for 'MIB8' sections and reverse the necessary values so
that the PSD plug-in functions can handle them.
In !769, I accidentally removed the ability to paste into an empty
workspace with Ctrl+V since I added a "does image exist?" check before
the `edit_paste_as_new_image_cmd_callback ()` call.
This patch resolves the issue by moving the check after the
"paste as image" function call.
"Hold and Modify" ILBM images use control bits to increase the palette
beyond what's stored in the CMAP chunk. This patch checks if
HAM mode is set and then interprets the plane bits accordingly.
This commit converts `GimpModuleDB` into a `GListModel`. This allows us
to drop quite a bit of custom code to have an adaptive list of modules
by just becoming a `GListModel` implementation.
Next to that, this commit also rewrites `GimpModule` to use the `notify`
signal for its 2 new properties: "auto-load" and "on-disk", rather than
trying to define a custom signal for that. This in turn allows us to use
basic methods like `g_object_bind_property()`.
Finally, the module manager dialog now uses `GtkListBox`, which can
easily bind to that new `GListModel` infrastructure.
Use a `GtkListBox` to show the list of GIMP themes rather than a
treeview. The idea is that we can expand this a bit more to give a
preview of the theme later on.
In case someone passes a `GtkWidget` rather than a `GtkWindow` as a
parent to a `GimpDialog`, we still have another way of trying to get its
parent window, using `gtk_window_get_toplevel()`. If we still get a
window from that, it allows us to still specify a reasonable
"transient-for" value for our newly-made `GimpDialog`.
Certain XMP metadata tags currently can't be saved by us until we get
support in gexiv2 for adding new structs not present in exiv2.
We remove these tags from the exported metadata because the XMPSDK in
exiv2 would otherwise fail to write all XMP metadata.
Examples are the newer (2019, 2021, 2022) sample images from the
IPTC Photo Metadata Standard.
We also add all the static functions present in gimpimagemetadata-save
at the top, which had been forgotten in the past.
Resolves #5742.
From fa0a0212, the splash's upper text was scaled to PANGO_SCALE_MEDIUM
both when the image width was 2x or less than 2x. This was likely a
copy/paste issue, as the lower text code scaling does not duplicate.
This patch fixes it by changing the else condition to scale to
PANGO_SCALE_SMALL.
Note that this change is unlikely to be seen as it requires a very small
splash screen image to reach the else condition.
As GdkRGBA stores colors as doubles rather than guint16, the assignment
code had to be moved into the ifdef block as well.
Note that this code is only used if X11 is not available on build.
These five plug-ins already used GimpProcedureDialog when I originally
worked on them for !9250. However, their export GUI needs to
use GimpSaveProcedureDialog instead.
1. gexiv2_metadata_has_tag with gexiv2_metadata_try_has_tag;
2. gexiv2_metadata_set_exif_thumbnail_from_buffer with the "try" version.
For a while now the minimum gexiv2 version for the master branch is 0.14.0,
which means we can replace these deprecated functions, since the new
versions were added in 0.14.0.
We were using fixed size buffer with strcpy/strcat, which gave warnings in
coverity.
Even though in our case there was no chance of buffer overflow, let's
replace this by using g_strconcat, which allocates memory for the
string which we free after use.
Also get rid of a few unneeded memset's for strdata.
Let's make cfitsio an optional dependency, showing up in the final configure
output. The file-fits plug-in will just not be built when the dep is missing.
Per @Jehan, this solution would prevent default icons from being loaded
in custom themes if they did not include their own version.
The only thing kept from !909 is the replacement of hardcoded strings
in a few files with constants defined in gimpicons.h.
Switch to NASA-maintained cfitsio library for loading/exporting FITS images.
This allows us to import compressed FITS files (GZIP, HCOMP, PLIO, RICE) in
8/16/32 bit and float/double precision. It also simplifies export code using
the built-in cfitsio APIs.
It is actually available in the SDK but was removed from the runtime (relatively
recently, it would seem). As a more general rule, it seems that GNOME is phasing
it out slowly in favor of libappstream. So probably we should do the same
eventually.
Yet for now, to at least have a working nightly flatpak, let's add it to our
package.
The flatpak_ci_initiative.yml template we include got changed 2 days ago,
replacing the "only" by a "rules", which broke our CI file.
Cf. commit 193f63c20f87d38868c05beee6446b387b73e140 in repository citemplates.
The present commit should (hopefully) fix this error:
> Unable to create pipeline
> jobs:flatpak-nightly config key may not be used with `rules`: only
(even though the error is a bit cryptic, the problem is apparently that both
rules: and only: keys cannot be used together)
… clean-exiting on all dev code (whether stable or unstable branches).
This is because the dirty exit prevents the on-exit crashes which seem to happen
somewhere in the memory cleanup (which apparently corrupts memory but all crash
traces don't show the proper area where the issue actually hapened). So let's
have release exit the process without issue (at least all important user-facing
data is saved properly by then), while not hiding the issue to developers.
Also on dev code, the GIMP_DIRTY_EXIT will allow to go anyway for the quick
exit() path, so that for instance one can work on other pieces of code without
feeling bothered by the constant crashes on exit.
For the record, the crashes we are talking about appear when you update to a
recent GLib, after the removal of GSlice implementation (which is basically now
just a malloc/free alias). There may be issues in our usage of GSlice though we
also experience crashes even just with commit 69e9ba80e on GLib which hints at
issues in our GObject/GType code.
xcf_save_prop() starts with va_start(), hence must end with va_end(). Yet any of
the xcf_write*_check_error() macros could end this function abruptly. Therefore
I'm adding a "cleanup" argument to the macros, allowing to add any code
necessary to clean the current function before returning.
- Missed a necessary autotools change: forgot to remove ui/Makefile
from configure.ac
- Not all compilers allow declaring variables in a case statement without
putting them in a block, so we add a block now.
Instead of loading the GtkBuilder .ui file we now create all widgets in
code.
Added several support functions to reduce code copy/pasting and making
additional widgets and supporting more metadata easier.
The overall layout should still look the same, with a few exceptions:
- Each notebook page only uses one grid. This makes it possible to align
all data entry widgets.
- Featured Organization and it's code were two treeviews next to each
other. These are now organized below each other to make automatic code
generation easier.
- Since we needed to touch this code anyway, I also fixed Xmp.dc.creator
and Xmp.iptcExt.ModelAge to be multiline. This closes #7286.
- The old icons used for the date button, add, and remove row buttons
were replaced by gimp-grid, list-add and list-remove.
Since this was the last .ui file used in GIMP plug-ins, we remove all
files from the .ui subdirectory and references to that.
Note that there are several more places where GtkBuilder is used, but
those cases uses strings defined in code instead of .ui files.
We had a lot of duplicate code using gexiv2_metadata_try_set_tag_string
and then checking for errors.
Simplify this by re-using the existing set_tag_string function by
introducing an extra parameter that tells us whether or not to clear
the tag first.
It was a temporary code added before relevant code landed in babl. The necessary merge request landed in Babl some time ago, and Gimp now requires Babl version 0.1.98, which includes the needed commit.
Related to merge_requests/509
In the master branch we depend on gexiv2 0.14, so we can remove the
deprecated functions and replace them with the "try_" versions.
We can't backport this, since our stable branch has a lower dependency
for gexiv2.
This ports the Import and export dialogs to use GimpProcedureConfig.
It covers all properties except GUI-only options
(which were still ported to libgimpui rather than direct GTK calls)
Additionally, a warning was fixed and mnemonics were added to the
property titles.
The metadata-viewer uses a GtkBuilder .ui file to create the interface.
In GIMP we prefer our interfaces to be created in code and these builder
files are also not available anymore in GTK4.
This commit removes the .ui file and support code, and creates the
interface from code in our plug-in.
Five icons in the Layer dockable were being replaced by GTK defaults at
runtime. A "gimp-" prefix was added so that GIMP's version would always
be used. A few dialogues were fixed to use constants rather than
hardcoding the filename, to make it easier to update the icon in the
future.
In 2.10, print_temp_proc_name () took in the image id. When it was
updated to take in GimpImage, it still assumed the g_strdup_printf
parameter was an integer.
This is fixed by calling `gimp_image_get_id ()` on the image parameter.
While testing the DCX import MR I saw that one image (abaddon.dcx) was not
recognized. This image uses 4 planes with 8 bpp while we only support
3 planes. The 4 planes type includes an alpha channel.
A few small changes allow us to also load 4 planes by allowing 3 or 4
planes instead of only 3.
Photoshop can save metadata when exporting to tiff or jpeg, including
a thumbnail that we can't update. This can contain sensitive data, so we
should not export it. See issue #8383.
To do this, we add the two Photoshop specific tags that we know of to the
list of tags that should not be exported, so they won't be saved.
This allows file-psd-load-metadata to show a warning message like the
PSD plug-in does when unsupported features are loaded.
As PSD metadata does not store rasterized versions of fill layers,
a new option is added to show these layers are dropped entirely unlike
with PSDs.
The dialog title changes based on which plug-in called it.
This adds the PSD metadata plug-in procedure call to the JPEG
plug-in, as part of implementing issue #7549.
Also implements the import half of issue #1842.
JPEGs only store image-level metadata like paths.
This adds the PSD metadata plug-in procedure call to the TIFF
plug-ins, as part of implementing issue #7549.
Also implements the import part of issue #2921.
TIFFs can have both image and layer-level metadata.
The load_paths() function was removed, as the PSD plug-in should
handle this now.
Creates a new public procedure that can be used by JPEG/TIFF files to
load any PSD-formatted metadata they have. This consolidates code
to the PSD plug-in, and lets JPEG/TIFF get immediate updates as the
PSD plug-in improves its own metadata support.
Note that only Macintosh formatted metadata is currently supported
by the PSD plug-in; IBM PC formatted metadata is reversed and not
yet interpreted.
Replaces GimpPickableInterface's pixel_to_srgb () functions with
pixel_to_rgb(). Now GimpRGB's values should be in the correct
image color space from the beginning of the process.
Some valid PCX/DCX files wouldn't load because the bytes per line
header check can be off by one due to integer division rounding.
This adds 1 to the equation to account for this.
DCX files are containers that store up to 1023 PCX files.
The PCX plug-in is rearranged to allow reading multiple PCX images per
file, rather than assuming there's only one image.
GimpFrame has a property 'line-spacing'. gimp_frame_get_label_spacing ()
tried to access it as 'line_spacing', so it always returned 0.
Fixing the typo should now return the true spacing value.
After testing a bit more, I realized that the thread was constantly re-rendering
the thumbnails, even though I didn't touch the "white-background"
button/argument.
This was not just a completely invisible problem, it actually affected the page
selection (it was very hard to select pages by clicking on them, it was randomly
working, and more often not selecting anything). This is how I realized there
was a problem.
The reason was simply that I was never actually calling g_cond_wait() because of
a first_loop flag I forgot to set.
Note that docs of g_cond_wait() explains that it is possible that "spurious
wakeup" happen. At first I thought I had this issue, which is why this commit
also adds a boolean flag to check after a wakeup, to make sure that I was in the
"condition met" case and not the "spurious wakeup" one.
Even though I realized afterwards the real reason was much more stupid, I still
left this additional check.
Fortunately this issue doesn't seem to affect the 2.10 code. Or to be more
accurate: the continuous render very likely happens there too, yet it doesn't
break page selection interaction with GTK+2 as far as I can see.
Port commit 41f40f530a from gimp-2-10 branch to the main branch:
While at first, the idea of always loading PDF with transparency seemed good
(commit 7aff7e9c70), I realized that a lot of administrative PDF (generated with
text and vector graphics, rather than scans or alike containing raster) actually
have transparency. So now all these documents load with transparent background.
Clearly all the office software are assuming that PDF readers will fill the
background with white.
So add a checkbox to decide whether or not to fill the image with white. I don't
update the PDB procedure. I'll just do this on the main dev branch (while also
updating a bit the code to newer API).
Fortunately I regularly open such PDF documents with GIMP and could witness this
no-transparency expectation before we released GIMP 2.10.34! 😅
As side changes, I also:
* ported file-pdf-load to work with GimpProcedureConfig arguments instead of
GimpValueArray;
* ported the dialog to GimpProcedureDialog and generating as much of it as
possible (except for the page selector/preview, and resolution entries);
* renamed the "pdf-password" argument to "password";
* added the "target", "antialias" and "white-background" procedure arguments.
A few issues which would deserve to be looked at more closely in the future:
* adding "width" and "height" arguments and decide how to handle "resolution";
this will likely be better handled with a new GimpVectorLoadProcedure subclass
to support vector formats in particular;
* shouldn't page selection be handled in a better way? Probably this could be
handled by adding a generic logic in GimpLoadProcedure (as multi-page support
is a common feature across image formats);
* GimpInt32Array arguments ("pages") can't be stored anyway right now.
* the "target" arg should be an enum.
This fixes:
> app/core/gimpitemlist.c:632:7: warning: ‘g_pattern_match_string’ is deprecated: Use 'g_pattern_spec_match_string' instead [-Wdeprecated-declarations]
The new function appeared in GLib 2.70 which is our current minimum GLib
requirement, so the replacement is fine.
Generated actions are not necessarily application-wide actions ("app." prefix of
detailed action name). As is the case here, they can be actions specific to a
group only.
With our old code, we needed dummy actions for every submenu. This is not needed
anymore. Actions are only for end menu items (items which actually do something,
not just open a submenu).
Get rid of them all, as well as the code to ignore any action ending with such
suffixes in action-listing pieces of code.
Especially some remnants of when Gimp(Toggle|Radio)Action were not descendants
of GimpActionImpl and had to reimplement GimpAction interface.
Also fixing a few details here and there.
This helps make sure we break circular references as soon as possible when
destroying an action group. I also steal the pointer before freeing objects to
make sure the list is empty immediately and any further signal from the actions
won't affect this group.
Note that it will only work for a model attached to a GimpMenu. In particular,
it won't work for the menu bar set to a GtkApplication with gtk_application_set_menubar().
In other words, it won't work on macOS where we let the OS handle the menu.
Use this for the "View > Zoom" and "View > Flip & Rotate" submenus which used to
display the zoom level and rotation angle. This regression is now fixed.
Though it actually worked in some cases, and failed in others (I have not
figured out which build option exactly makes the format with hole work anyway),
printf manual actually explicitly says:
> There may be no gaps in the numbers of arguments specified using '$'; for
> example, if arguments 1 and 3 are specified, argument 2 must also be specified
> somewhere in the format string.
This explained while it was crashing GIMP (again, only with some build options,
or lack of build options):
> *** invalid %N$ use detected ***
There were 2 possible solutions for this: either ensure that the order number is
always used, but that defeats the purpose of plural localization. Instead I
reorder the argument so that the file name (which must always be shown for sure)
is first in arguments. This way, even if the order number is sometimes omitted
(be it in English or in any language), we avoid the crash.
gimp_rectangle_options_fixed_rule_changed is called when either the
checkbox or the dropdown for Fixed Size is changed.
However, the "fixed-size-active" property was not updated until after
it ran, so the toggle behavior is inverted.
This checks to see if the toggle was changed and updates the boolean
before setting the size field as (in)sensitive.
The GimpProcedureDialog API allows int and double SpinScales. However,
it calls gimp_prop_widget_set_factor () which requires doubles.
A conditional check for a double property was added to this call.
A check was also added to ensure int properties have a factor of 1.0.
Just "Layers" or "Patterns" was always very confusing. It was even worse when
both tools and dialogs had nearly6 the same name (for instance "Gradient" was
the tool action, but "Gradients" was the dialog).
Now these dialog actions will be labelled more obviously in the action search,
such as "Layers Dialog" or "Gradients Dialog".
Of course, the short name will stay in contextualized menus, such as in the
"Windows > Dockable Dialogs" top submenu, or in the Dockbooks' "Add Tab"
submenu.
While the short label can be "Gradient" for instance, because it is in the
submenu "Tools > Paint Tools", this is a confusing label say in the action
search.
Now the longer label will be used in there and will say:
> Activate tool "Gradient"
"edit-paste-as-new-image-short" and "vectors-selection-to-vectors-short" were
just duplicate of the action named the same, except for the "-short" suffix, and
the only point was to have different labels.
Not though that this time, it was not enough to conclude that the action in a
menu shoud have the short variant. These were both used differently depending on
the menu.
Instead I added the concept of "label-variant" attribute in .ui menu files. When
the "long" variant is set, then we simply use the longer label.
There is still one more "-short" action: "tools-by-color-select-short", but I am
a still unsure how to handle this one.
All Gimp*ActionEntry (except GimpProcedureActionEntry) now have a short_label
member.
This commit doesn't add any new short label yet. It just fixes the struct usage,
and fixes a few localization contexts here and there when I saw such broken
strings.
I also fixed a few gradient editor action strings which were not proper labels
(like "splitmidpoint" or "splituniform", or missing uppercase, etc.).
The short labels are just the file names as we have all the context in the menu
to understand what these actions do (in Windows menu, ordered by view position
and with a `Ctrl+n` shortcut next to each, increasing by position).
In the action search for instance, we keep a 'Show "<image name>"' label.
Also I'm adding a relevant tooltip to further explain what each of these actions
do, using the view position.
Basically actions in menus should show the short label (we assume the menu
position brings contextuality) when available, whereas it will use the longer
label in GUI lacking contextuality.
As a first such usage, the `file-open-recent-*` actions have the file name which
will be opened as short label. This is used in menus since the submenu `File >
Open Recent` ensures that the action which will run is perfectly understandable.
On the other hand, in the action search, the action is named 'Open "<file
name>"' since an action named only with a file name would not be understandable.
Since we now generate actions for GEGL ops, we might as well generate menu items
for these too.
What I did:
- Move the "GEGL Operation…" tool (generic dialog with a drop-down list of all
non-ignored GEGL ops) to Tools menu.
- Create a "GEGL Operations" submenu in Filters > Generic.
- Move "GEGL Graph" to the top of this new submenu.
- Generate a new menu item for each generated action tied to a GEGL plug-in,
alphabetically sorted.
Though the GEGL Operation tool is still useful as a generic dialog, let's
generate also per-operation (the ones not ignored and not already special-cased
in the rest of the GUI) tools and actions.
These "tools" are mostly hidden (e.g. not selectable in toolbox where it would
be a bit useless as they would show with the generic GEGL icon or none), but
they can be searched with the action search, shortcuts can be assigned and they
can be added to menus.
Since the recent changes, these 3 tests are not working:
- tools
- session-2-8-compatibility-multi-window
- session-2-8-compatibility-single-window
(the 2 latters were only working with xvfb anyway)
I could just dig further as I did a bit these last few days, and tweak more and
more the testing code. But I think our current unit-testing framework is just
non-reliable and for all these years, we have spent more time fixing the tests
than actually relying on them to tell us there is a bug in GIMP.
Furthermore creating new tests is so cumbersome that basically none do it.
I have a plan laid out in #9339 for a much better and more reliable unit testing
infrastructure, based on the GIMP executable itself and a very simple syntax to
create new test scenari (so that even non-developers should be able to create
them eventually). So until then, let's disable these tests and stop wasting
time.
Same as ZoomIn/Out keys, these are implemented as secondary shortcuts to actions
"windows-show-display-next" and "windows-show-display-previous" respectively.
See issue #637.
- The `accelerator` variable is a NULL-terminated array, allowing up to 3
accelerators per action (so far, none has more than 2).
- Only the struct GimpProcedureActionEntry still has a single accelerator as I
don't think it makes sense that we change the plug-in API to allow a plug-in
to register more than 1 shortcut for a procedure (e.g. we don't want a plug-in
to just register all possible keys for their procedure!).
Of course, users will still be allowed to register more shortcuts for plug-in
actions through the shortcut dialog. It's only the initialization which
1-shortcut max for procedure actions.
- Remove all actions ending up in "-accel" as these were only a trick to
register more shortcut for a same action. Now we just have the real
possibility (rather than creating bogus duplicate actions). As a consequence,
these actions accelerators have been moved as secondary accelerator to their
main action.
The deleted actions are: "view-zoom-out-accel", "view-zoom-in-accel",
"view-zoom-16-1-accel", "view-zoom-4-1-accel", "view-zoom-2-1-accel" and
"view-zoom-1-1-accel".
… Default Values" buttons in Preferences.
I considered just deleting the "Remove all shortcuts" action, because really I
am wondering how useful (and often used) it is, and if we are not over-featuring
the shortcut code.
I could find the origin commit 6da388be93, from 2006. Basically the use case is
for people who want such a different mapping overall that it's much better to
start from a blank slate (e.g. DVORAK users, like in the original report).
See: https://bugzilla.gnome.org/show_bug.cgi?id=331839
So in the end, I just reimplemented this with newer code.
Also this commit fixes the "Reset Keyboard Shortcuts to Default Values" code.
This was always confusing to people that they had to click "Save" then "Close".
With new code anyway, any change is instantly put into effect, and the only
point of "Save" is to actually store immediately in the shortcutsrc file. But
this is clearly not very clear to people (and it can be done in the Preferences
dialog too).
Instead let's just have a "OK" button. The file will be actually updated on exit
only (if "Save keyboard shortcuts on exit" is checked). And that's it.
The only missing feature would be the ability to cancel the latest changes
before hitting OK, i.e. having a "Cancel" button too. Let's see to do this
later.
Also get rid of various old references to menurc and don't install it anymore to
etc/ (neither the new shortcutsrc as it doesn't look like it brings much value
to do so).
This uses a new concept of "default shortcuts" which must be called only once at
most per action. Any subsequent shortcuts setting are custom settings.
Commenting these lines out is mostly informational as it allows to see in a
quick glimpse in shortcutsrc file which are custom shortcuts or not.
gtk_accel_map_load()/gtk_accel_map_save() are not working with the new
GAction-based code. GtkApplication does not seem to have helper functions to
simply load and save accelerators in a file, so we just implement it ourselves.
A few things are missing right now, namely:
- On parsing, it doesn't handle any kind of duplicate accelerators (possible
especially if someone edited the new shortcutsrc manually).
- On reading, maybe we should only write down the changed (from defaults)
actions, while keeping the old ones commented-out, as menurc used to be. This
is actually useful info both for debugging or even for users who want to look
at this file and see what they changed.
- We should add import code to transform the menurc into shortcutsrc when
updating GIMP, otherwise all custom shortcuts would get lost.
There is still the question on whether we should add the group name too. I think
we should, expecially for plug-in's procedure actions, though right now these
are just added in the GtkApplication's main action group anyway. I'll see later
to refine this.
Now that we don't have any action duplicated in groups based on names (i.e. that
there could just be 2 actions with the same name in different groups), let's
have the GimpAction also store its group.
Use this to fix some code which was now crashing when confirming erasing an
existing shortcut.
In particular on macOS, we want to show some default common actions (see
comments in !837) but gtk_application_prefers_app_menu() docs says that it will
always return FALSE on this OS. So we ignore this call on macOS.
Depending on where it's used, this list of action can be either in the
"dockable" or the "dialogs" action group.
The meson rule is a bit more complicated than I wished it were because of the
ever-so-blocking lack of simple dependency in meson.
Cf. my latest comment: https://github.com/mesonbuild/meson/issues/8123#issuecomment-1496168759
This deals in particular with the dockable issue. Each dockbook needs its own
GimpUiManager and the action groups inside, which are identified by a string
identifier but also by a different user data (allowing to identify the specific
dockbook an action was call from, so that for instance you close the right
dockable).
It also makes the name requirement of plug-in procedure more flexible as a
procedure name clash can only happen between plug-in procedures now (not with
core actions).
This is a continuation of previous work where we are slowly moving to most logic
being in GimpMenuModel so that it works both when we create menus ourselves or
when we let GTK do it for us (e.g. the main menu bar in macOS).
It should make it possible to attach an action group to a widget, instead of
making it global to the application. This will be useful/used for context
actions, such as actions which are only relevant to a dock and which will
therefore be duplicated to each dock (with the specific dock as user action so
that we work on the right part of the GUI).
I have not implemented all virtual methods. Not sure if they are all necessary.
It was actually working fine except that I wrongly named the submenu somehow,
but even more particularly I thought it was about single dockables (tabs)
whereas it was about full detached docks (a window containing several
dockables/tabs).
As a further optimization (even though the big slowness situation is
mostly resolved anyway by a previous commit), let's not rebuild whole
submenus when only a few items were added or removed.
1. First make so that the action "visible" property is only notified
when the visibility actually changes. This way, we can trust that the
visibility of the item and of the related action are properly synced.
2. Now when an action which is part of a model changes its visibility,
we trigger the proper "items-changed" only for the added or removed
item. This replaces the old procedure of removing then adding
everything (i.e. a full reset).
3. Add some utilities in gimpwidgets-utils (out of gimpmenushell.c).
This cleans up some code and also fixes some bugs which were
reimplementing (badly) some code I already implemented (right) in a
static function.
4. Fix adding new actions in sub-sub… menus. Previous code was only
showing the direct parent, not up to the root menu (this could happen
for plug-in procedure items in particular).
When an action is removed from a group, we verify if it's not in any group
anymore. If so, we remove it from the GimpApp action map.
This fixes some CRITICALs happening when some actions were dynamically deleted
and re-created, in particular the "windows-display-XXXX" actions.
These were the last use of the old GtkAction API and it was particularly
annoying here as this widget is used both in core GIMP and in plug-ins, yet core
GIMP actions were not GtkAction anymore (so the "activate" signal handler's
signature was different, which would crash the core code).
Now the clash is resolved as this widget just uses GAction (which both
GimpAction, for core code, or GSimpleAction, for plug-ins, are).
This is also the absolute last use of GtkAction (and other related API) in all
our code (core, libgimp* and plug-ins). \o/
I've hesitated if we should make it a GActionGroup, whose API handles actions
fully through name strings. I didn't see what it brings us short-term compared
to the additional work, so for now it's just a class of its own, not
implementing GActionGroup interface. Maybe later.
Pre-GIMP-3.0 code logics would re-allocate several GimpMenuFactory or
GimpUIManager for no good reason. While it was still working with old GtkAction
code, with our new GAction-based code, we were ending up overriding an action
with a new version of the same action, while keeping reference to old actions.
This made for discrepancies of the enabled or visible state of actions.
The new code keeps singleton of some objects and references to already
registered GimpUIManager or GimpActionGroups objects and make sure no actions
with the same name are created twice.
Unless mistaken, this is not needed anymore. New GtkApplication code should take
care of creating the native macOS application menu for us.
Cf. also contents of MR !558.
Testing the 2 code paths is otherwise extremely annoying. Let's just add an
environment variable allowing us to run one or the other implementation if the
variable is set.
Since GAction don't have labels or visibility, it is up to every application to
fill the GMenuModel with such infos. In my previous implementation, I was simply
handling these in GimpMenuShell subclasses (GimpMenu, GimpToolbar and
GimpMenuBar) since we need them for tooltip support (unavailable from GMenu).
Nevertheless there are cases where we want to use GTK API directly with a
GMenuModel, in particular with gtk_application_set_menubar(). This is necessary
to handle the macOS specific code path, where we don't want our usual menu bar.
This OS has its own display of a software menu bar, directly in the desktop GUI.
See !558 for some screenshots of this.
So this commit moves around some code away from GimpMenuShell subclasses into
the new GimpMenuModel class. Now we use this new class instead of simpler GMenu
objects. It handles syncing with GimpAction-s, auto-updating labels, visibility
and sensitivity, as well as adding custom items (plug-in actions, recently
opened files, opened images, etc.).
Only remaining API are action group-related.
While doing this, I also remove 2 debug actions which don't look like they were
outputting any information anyway (at least on the main dev branch):
"debug-dump-items" and "debug-dump-managers".
In such a case, we may not want to connect to "query-tooltip", yet we still want
the normal tooltip to show up. This was a case for instance for the recently
opened file actions ("file-open-recent-*") or opened image actions which were
not showing their tooltips.
When we do this, their actions are not properly run, because this happens after
the "hide" signal. So we need to detach the popup in an iddle function (so that
it runs after all in-progress signal handling happen), which will in turn
removes the last reference to the object.
My last commit message was slightly wrong. I had one last special case to
handle: the ability to only create sub-GimpMenuShell (i.e. at a specific path
other than the root).
We are using this ability in particular for tool options submenus.
It's still pretty simple now and allows to add toolbar buttons and separators
(at start or end). There is no possibility of runtime-customization yet, but in
the future, it would be great to allow such ability and use this widget for a
main window toolbar which people can customize to add quick access to their
favorite actions.
Somehow the toggle actions were not working correctly on GimpMenu popped up e.g.
as dockbook menus (but it was fine in the GimpMenuBar). I straightened up the
code to be a bit clearer. I also rely on the "toggled" signal rather than
"change-state" (the latter is supposed to happen before state change actually
happen). It now works much better.
Several menus can be triggered either as popups on their own when right-clicking
the dockable or on items, or as a submenu in the docks main menu.
In the former case, we want the menu items to be at the root level, whereas in
the latter case, we want them inside a properly named submenu.
To handle this, I wrap these in a properly labelled <submenu> in the .ui files,
and I add a boolean flag to gimp_menu_shell_fill() which will drop the top
submenu if and only if this is the only top item. I use this flag only when
using these menus as popup menu on their own.
Also fixing a few memory leaks around these pieces of code.
… group name.
The gradient editor submenu add 2 submenus with changing names. It was using
again bogus actions: "gradient-editor-blending-func" and
"gradient-editor-coloring-type" do nothing except for being used as name
holders.
Instead I add the concept of group name for GimpRadioAction-s and when I use a
radio action attribute as <submenu>, this submenu will use the group name (and
sync with it, if it changes).
I only translated the undo menu into GtkBuilder's .ui format for now.
The only missing part is that the icon is now shown.
Note that in various parts, I don't rely anymore on a bogus menu action (i.e.
"undo-popup" action in this case) which does nothing but has an associated label
and icon. I simply add the label and icon as submenu attribute directly in the
.ui file, which is translatable and whose strings should be parsed by gettext.
Eventually I'll just get rid of all the various "*-popup" or "*-menu" bogus
actions.
The new GimpMenu is derived from GtkMenu. Both GimpMenu and GimpMenuBar are now
implementing GimpMenuShell which allows to share a lot of the logic for filling
the menus, adding items, etc.
This is less and less a GtkAction. Note that I don't implement
gimp_action_get_name() because once we will drop completely GtkAction and make
GimpObject the parent, we can just use gimp_object_get_name().
The dialogs-menuitems is shared between dockable-menu and image-menu, just as it
was with the old format. For this, we use XSL transformation with XInclude, then
drop the namespace (because GTK doesn't like the unknown namespace being defined
and crash immediately otherwise).
This is a placeholder which is not meant to appear in the menu. Our new system
uses placeholders internally, but plug-ins cannot make use of these.
Not sure anyway if this is so useful in the cases of plug-ins. At least, I don't
feel it is for these particular use cases.
Also getting rid of gimp_action_get_proxies() API which is now unneeded, I
think. Furthermore GimpMenu does not have to connect to label changes. Making
the items proxies of a GimpAction is enough to have them updated.
The tooltip contains the reason for action inactivity, if relevant. And in case
of a GtkMenuItem in particular, it will also contain the "Press F1 for more
help" text at the bottom.
Not sure why gtk_actionable_set_action_name() works fine to activate base
GimpActionImpl, but not subclasses like GimpProcedureAction or GimpEnumAction
(and maybe others subclasses?), such as the "file-open-recent-*" actions. This
will have to be investigated further IMO.
While in the menu, under a contextual "Open Recent" submenu, it is well
understandable, the action is much less understandable without context, e.g. in
the action search. So I prepend an "Open" prefix.
Maybe a future alternative could be to have GimpAction have both contextual and
non-contextual labels (a.k.a. short vs long label)?
The proxy properly shows a color area or viewable (depending on context), and
this is properly updated when the associated properties are changed.
The label change is also properly updated in the label part of the proxy.
Very relevant actions to test the proxy items are dynamically updated are
generated actions such as the "file-open-recent-*" actions (with both label and
viewable updates), or again the Edit > "Fill with (FG|BG Color)|Pattern" (with
color/pattern updates).
These are the menu items such as the recently opened images, or recently used
filters, etc.
Some notes:
- I added back a "placeholder" concept in the GimpMenu logic. This will allow to
place items at specific positions in the menu (either under the placeholder,
which will make the last item be on top or above the placeholder to have the
last item be in the bottom, depending on needs). Technically placeholders are
just menu items with a label (used as placeholder key) and no associated
action, which I will leave invisible.
- I add a logic for submenus so that they are invisible by default and are only
made visible when we add a menu item with an action in there.
- I removed filling the "/Filters/Recently Used/Plug-ins" placeholder. As far as
I could see, it was never filled (neither with old or new code) and the
"/Filters/Recently Used/Filters" actually already takes care of filling the
"Recently Used" submenu with both GEGL operations and plug-in calls.
- The old gimp_ui_manager_add_ui() API is for all types of menus, e.g. including
the ones created by dockables or elsewhere whereas my new API is (for now)
still specific to the top menu. This will have to be further implemented
later. I left a bunch of "TODO GMenu"-s for the time being.
- I see 2 dock-related generated items which seem to never be added, for
recently added and closed docks. It doesn't seem to work in the old API as
well. I'll want to have a closer look too.
Some actions in particular can change their label. E.g. "file-export" and
"file-overwrite" will have customized labels containing the imported or exported
file name. The menu will now reflect such changes, live.
I'm starting to override GtkAction properties, starting with "sensitive" in
order to finally move away from GtkAction. Obviously, this breaks the
sensitivity check of the original menu.
I could reproduce this while closing GIMP immediately after starting it.
Sometimes the idle source would be running and working on now finalized objects.
"windows-show-tabs" and "windows-use-single-window-mode" were set to FALSE by
default, while it is now supposed to be TRUE, same as the config properties. The
discrepancy was only showing with my new GimpMenu which better follows the
action's state.
This demonstrates a first version of our replacing menu, using GAction and
GMenuModel. I had to make our own subclass of GtkMenu to process the model (from
a .ui XML file) for the following reasons:
* gtk_menu_new_from_model() doesn't support tooltips, which is a feature we use
quite extensively in GIMP: with all our filters, being able to give a longer
description is often useful; moreover we use tooltips to give hints about why
a menu item is deactivated as well.
Unfortunately it looks like GTK doesn't consider this lack as a problem and
don't plan on adding tooltip support.
See: https://gitlab.gnome.org/GNOME/gtk/-/issues/785
* I won't to avoid copying action's label and icons in the .ui file. This only
duplicates strings and would be a source of issues each time we change
action's strings (we'd have to do it in 2 places, which someone will
inevitably forget).
Now it still has various issues:
* The syncing between actions and menu items need to be cleaned up. It's still
in early demo code.
* It uses directly some Gtk*Action code because GimpRadioAction and
GimpToggleAction are not directly related right now (only through their
parents).
* gtk_application_set_menubar() might still be necessary on macOS as I think
it's what enables the native menu system on this OS. It means that we'll have
to edit the menu model to add back the labels (as this function does not
extract these from the linked action since GAction has no label or icon
concept).
* Icons are not taken into account right now.
* I'll have to verify if GimpAction with proxy work (but my guess is that right
now, it won't).
* Action's active state is not synced with menu item active state right now.
* Various actions are inserted live, such as opened images, opened views,
recently opened images, and so on. This needs to be implemented back.
* Plug-ins need to be able to create their own menu item into this new menu.
* For all these various reasons, I'm keeping the old menu around, for the sake
of comparison, until the time the new one becomes feature-full.
Part of this commit is inspired by !558 and obsoletes this MR.
Simply with a NULL context, we can't set or get accels from a GimpAction. Having
a mandatory context was a problem for GimpColorButton which could create a
GimpAction even though libgimpwidget has no knowledge of GimpContext.
All the remaining pieces of code where the deprecated concept of accelerator
closure was still used have now been replaced by proper GimpAction API using the
newer GAction API.
It's still not perfect, especially as we might want to get back GimpActionGroup
for this specific dialog (it may be nicer than an overlong list of actions). And
overall, I am not fond of this interface so maybe I'll want to review how we
display and change actions too. Moreover we now have the ability to set several
shortcuts per action, which was a really wanted feature and this dialog doesn't
allow this yet.
I'll get back later at this widget, but for now, it is a step forward for
deprecation.
- New gimp_action_get_display_accels() added to GimpAction API to get directly
the human-visible strings for actions.
- Also adding an "accels-changed" signal to GimpAction. As far as I can see,
even though accelerators are now to be set on the GtkApplication, there seems
to be no signals or properties to connect to at all on this class. So instead,
let's do it on our GimpAction (which means we must absolutely not use
gtk_application_set_accels_for_action()).
- GimpAccelLabel now uses the proper GimpAction API instead of accelerator
closure which is a disappearing concept.
In particular, there is no concept of accel closure for actions anymore in
GAction, which means that eventually gimp_action_get_accel_closure() will have
to disappear too.
Depending on the OS, the display name may contain characters which are not valid
for action names. In particular, on X11, the display name could be ":0.0" and
therefore we get actions named "app.dock-move-to-screen-:0.0" or
"app.view-move-to-screen-:0.0". The ':' is invalid, which will make calling
gtk_application_get_accels_for_action() (or more simply our new function
gimp_action_get_accels()) fail.
See docs of g_action_parse_detailed_name().
The new utils function gimp_make_valid_action_name() will help us get rid of
invalid characters for actions whose name was generated from strings we don't
totally control.
Furthermore gdk_screen_make_display_name() is now deprecated API, and more
generally gdk_display_get_n_screens() is deprecated too and now always returns 1
since GTK+ 3.10 (i.e. now each display only contains a single screen). Instead
we just use gdk_display_get_default_screen() for every GdkDisplay. So this
commit doubles as GTK/GDK deprecation cleanup.
If we want to reuse this in subclasses, we'd need to overwrite finalize() in the
subclasses, call gimp_core_app_finalize() and chain up with the parent class.
Not doing this until now was leading us not to call GApplication or
GtkApplication finalize() function, which in turn, in the later case, was
leaking all the GAction-s which were added to the GActionMap. I realized this as
a leaking GimpContext-s warning was printing when ending GIMP.
Adding a 'Show" before the image identifier, which is now between quotes, and
making this string localizable.
This makes the action more understandable, especially when listed in
less-contextual UI such as the action search.
The obvious reason why it was not implemeted in GimpAction is because as
interface, it cannot have a private struct.
Yet actually we can, by setting the struct as qdata on the object, as we do in
several other interface. This allows to move implementation of functions or
properties for things which make no sense to reimplement each time we implement
a subclass.
… "Add La_yer Masks with Last Values".
Add the "with Last Values", otherwise the shown label is the same as
"layers-mask-add" action, which is confusing (until we read the longer
description/tooltip).
It's basically a conveniency action for internal usage, which is similar to
"layers-mask-add" (except for sensitivity rules). In particular, I don't want to
see 2 seemingly identical actions in the action search.
There were 2 pieces of code where I was unsure of the use. I left them
surrounded by `#if 0` macros and a comment for the time being, to easily find
them later if we encounter issues.
Note that I could edit the GimpUiManager directly to use the GAction API, but I
feel like it is adding a level of complexity to existing GIO/GTK API. So right
now, I am planning to either get rid of it or really simplifying it a lot.
We had this feature "can-change-accels" where people could change their shortcut
directly by browsing the menu. It was on the property "gtk-can-change-accels" in
GtkSettings. Unfortunately this got deprecated in GTK+ 3.10 (more accurately in
dev version 3.9.8, according to GTK's NEWS file), and is therefore ignored since
then. In other words, whether we check the box or not in our Preferences, it
doesn't do a difference.
If we want to get the feature back some day, we'll have to reimplement it with
custom code. In the meantime, there is no need to leave this visible in
Preferences.
Right now, our actions are added both in the GActionMap (a.k.a. as
GApplication|GtkApplication) and with the old GtkActionGroup API. The later code
is meant to be removed soon.
A major difference with the old implementation is that we don't add the actions
in separate action groups. Even though GLib has a GActionGroup concept, these
don't seem to be used at all when adding actions on the GtkApplication level.
It might mean that eventually we will even remove the GimpActionGroup code and
move everything up one level.
Of course, I am still evaluating if we really want an action group concept, in
which case, we could simply recreate it, but I'm actually unsure how useful it
is. The only place where I see a use to this is in the shortcut settings (to
organize actions by groups), but even there, it was rarely useful to me. I
usually rather search for actions by text search anyway.
Since these were not children of GimpActionImpl, I had to reimplement basically
the same code, which is kinda ugly. When we'll have finally gotten rid of any
dependency to Gtk*Action, these 2 classes should be re-parented under
GimpActionImpl, hence simplifying their code.
A good chunk of the code is taken from GSimpleAction implementation in GLib.
Thanks to Lukas Oberhuber for his early attempt to implement something similar.
- gimp_image_add_sample_point: guide is a left-over from copy-pasting and
add apostrophe
- gimp_image_get_sample_point_position: it was not clear that the
parameter was the y-offset and the return value the x-offset
I noticed after porting the last few plug-ins that GimpPreview went
to black when you unchecked the auto-preview option.
These widgets must be added directly to the dialogue rather than via the
new API in order for the unfiltered image drawable to be loaded
properly. They will eventually be removed in favor of on-canvas preview,
but let's get them working correctly for now.
The warning was:
> Warning: GimpUi: gimp_procedure_dialog_fill_scrolled_window: unknown parameter 'contents_id' in documentation comment, should be 'property'
I realize that UI_TEST is only used in our meson scripts and is therefore not a
reliable environment variable to check for whether we are running a unit test or
not. GIMP_TESTING_ABS_TOP_SRCDIR should be present for all unit testing, on both
build systems.
- Lua, Javascript and Python were boolean defaulting to true, which was
installing them even when not available (and if not installed then, it
would show warnings at each run). Instead I make them features with
'auto' as default. In this default, we don't install when the
interpreters are absent.
- These 3 options can still be forced by setting them to 'enabled' (the
interpreters are not actually necessary during build).
- Vala behavior stay the same (and unlike other binding, you cannot
force it since it has a build step); it's only renamed to just "vala"
for consistency of option naming.
The real problem was not actuall logout-inhibition, but availability of the
GtkApplication. Anyway this feature is not really to block the system while
unit-testing but for saving people's actual work. Let's just disable running it
in test case.
This will fix the CI.
Two of our scripts have a spinbutton step size the same as the page size.
Since page size should be larger than the step size, this causes a
CRITICAL in LibGimpWidgets:
gimp_label_spin_set_increments: assertion 'step < page' failed
We fix this by setting a page size larger than step size in
coffee.scm and tileblur.scm.
If a 1 bit PCX image is opened interactively, a dialogue will let
users choose to either use the built-in palette, or force the colors to
be black/white only. Otherwise, the user can choose this via a script
parameter.
The meson build had the tools tests disabled unlike the autotools build.
Since enabling them doesn't cause any problems, let's enable them for
meson too.
Our CI meson tests for single window failed even though the sessionrc
looked the same as the one created by the autotools tests.
Looking at the Makefile.am it explicitly states that the tests shouldn't
be run in parallel or in a different order than specified, which was not
the case in our meson build.
We change this by setting is_parallel to false for each build, and
setting a different priority for each test. Since higher priority values
execute first we count down.
I noticed that in our CI meson job certain tests were skipped, which didn't
happen with autotools.
On examination I noticed these tests check for HAVE_XVFB_RUN. Even though
meson checks for xvfb-run etc, it doesn't set HAVE_XVFB_RUN.
Adding HAVE_XVFB_RUN allows the tests to run without skipping certain parts.
Users have noted that legacy layer modes have better compatibility
when exporting PSDs and reopening them in Photoshop.
This patch adds a notice with that information to the PSD export GUI.
- Use a pre-defined MAXDATABLOCKSIZE for all the buffers filled with
GetDataBlock that is known to be large enough.
- When reading comments ensure that it always ends with a NULL.
- Ensure that the right/bottom frame dimensions are also within range.
Inspired by issue #9195 I went over how we handled error messages when
loading GIF images.
- I replaced some cases with g_set_error and added an error parameter to
ReadImage.
- Introduced function read_error that uses g_set_error when image == NULL,
or else g_message.
- Enabled translations for the messages.
- Synchronized the error messages used to reduce the amount of work for
translators.
- Changed the error code returned internally in a few places, to be better
able to distinguish between encountering and end_code (-2) and possible
corruption errors (-1).
- Moved allocating dest down to not need freeing it in case of error.
- Allow to show partial results in case of errors.
The IART and INAM metadata fields were stored in gchar arrays,
which have a limit of G_MAXSHORT indexes.
However, you can have strings larger than that in the format.
To prevent overflows, they were changed to gchar*. f_read ()'s result
is also checked, and an error is set if it returns 0.
The frame count variable is also now reset per icon block to prevent
overflow as well.
I'm actually syncing with a branch which I can't test right now because flathub
seem to have some breakage. For the nightly, let's just directly push as anyway
we can't test in Gitlab MRs either because of the non-master jobs timeout.
See: https://github.com/flathub/org.gimp.GIMP/pull/202
We should always keep the diff between these files to a minimum.
- Fix the markdown styling.
- Add commands on how to build GIMP from the local repository instead of a brand
new clone (otherwise I don't see how one could develop with flatpak). I knew
it were possible, but until today, I never tried to do this so I had to test
first.
- The cron file was from the very early flatpak experiments before Flathub came
into the picture, as well as the GNOME Nightly repository. Back then, we
wanted to set up our own nightlies or release repository through a cron.
- It is still interesting to keep some instructions for local builds of the
flatpak as some people want to use this for development (but all the part
about exporting to a repository, signing, etc. is now unneeded for such use
case). So I'm updating the howto to more current recommendations.
- `flatpak-howto.txt` renamed to `README.md`.
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).
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.
In case of negative y in the region to process, we were accessing invalid memory
(negative array index).
I hesitated between make so that a given ordinate always use the same index or
if we just want the start ordinate (whatever it is) to use index 0. The later
could have just been `(y - result->y) % RANDOM_TABLE_SIZE`.
I just decided to keep the existing logic (former case) though to be fair, not
sure it matters much.
(cherry picked from commit a86560bb57)
Cf. the previous commit: colorsvg2png has a memory leak in librsvg (so we can't
fix it easily). In any case, it's just a one-time-use tool, we don't really need
to focus on its memory bugs as long as it does its job to make icons.
Actually even with this, b_sanitize=address still detects a memory leak. After
some testing, it seems that just creating a RsvgHandle, then freeing it
immediately is enough to leak some data, which means the leak is in librsvg.
Additionally, the ImageMap-specific icons weren't showing up due to the
filenames not matching the references strings ("imap-polygon" but
the filename was "imagemap-polygon.png"). This patch fixes that by
renaming the strings to match file name.
Partial code style fixes were made as well; a lot more are needed.
The magics used for detection for CUR and ICO are not very unique and
interfere with the detection of certain types of TGA images.
Since these TGA images are regularly used, it seems better to only base
CUR and ICO detection on the extension, just as we do with TGA version 1
files.
See also issue #7912
Krita had a bug where it incorrectly saved 4 for the alpha bits instead of
8. We will allow 4 and convert that to 8 to be able to read the incorrect
TGA images.
The likelyhood of real TGA images with 4 alphabits seems pretty low, so it
should not interfere with real images that have this set. We were not
supporting that anyway.
- fix a typo s/Commponent/Component/.
- Add &std_pdb_compat() to the new PDB procedures (I realize that's probably
what the contributor was asking about, back in !446). Not sure if it's right
as there were none in this file, but these are clearly just wrappers around
GEGL ops, so it seems fitting.
- Some alignment fixes.
- More accurate "$since" variables.
(cherry picked from commit 66ef1ef1ef)
(cherry picked from commit dbf9f277a2)
Committer's (Jehan) updates:
- Component type is now int32 (int8 is not a PDB type available anymore).
- PDB files re-generated to handle changes in API and types.
When a plug-in enters a bogus file name such as "Untitled.xcd" as URI,
g_file_is_native() returns FALSE. So when saving such file, core code tries to
mount a remote volume and fails (of course), without even opening the file
dialog.
This change is an attempt to detect such cases beforehand and not even try to
save it (just open the file dialog directly; the file name is still useful as
default proposed file name, as this part is actually valid).
Actually remote files will have a valid URI anyway (something with a valid
scheme, such as https:// or whatever other scheme).
As side fix, I am adding a missing space to the error which I got.
- This is unneeded in all import procedures. See previous commit. Note though
that this is not because of a change in previous commit. This was already
useless previously. The file set with this PDB function was overridden by the
core anyway (i.e. even before the previous commits).
In app/file/file-import.c:file_import_image(), the imported file is correctly
set (so there is no need to set it from plug-in, which anyway libgimp's
gimp_image_set_file() was not doing) and the XCF file is reset to NULL
(rendering the call to gimp_image_set_file() in a GimpLoadProcedure useless).
- Similarly, this is a useless call in export procedures because
app/file/file-save.c:file_save() overrides such call too. I could only see one
such case for JPEG export, which was quite useless.
- Finally in other types of plug-ins, setting a non-XCF file extension was
interfering with the save feature (similarly to commit e6e73e14c7). I only
fixed the screenshot implementations doing such a thing.
- I left a few usages which will have to be looked at more in details later.
This is not made to set the imported or exported file, but only the XCF file.
See previous commit to see what happens when this API is used to set non-XCF
file extensions (saving fails unless one edits the filename).
This commit is a fixup commit for MR !790 which had a few issues:
- The args for shadows and highlights adjustments are "shadows-ccorrect" and
"highlights-ccorrect" respectively.
- Also fixing generated code.
(cherry picked from commit e456ab019b)
This code is taken from Massimo's comment in #1786 and MR !834. It doesn't fix
a crash as this was already handled in !404, yet the missing prompt after
hitting "clear" was clearly not consistent with how one expect a clear feature
to work.
At least now, we've got a prompt back immediately after clearing.
Some PDF have transparency on purpose. Filling with white, without any question,
is counter-productive and prevents from working on such PDF files.
Note that we could add an option with a checkbox, leaving one to decide whether
to fill the background or not. But it feels over-engineering the issue. The PDF
is transparent, so that's what we load, and that's it. If one wants to add a
background, it's easy to add a layer at the bottom of the stack (and they can
make it any color they want, not just white), after loading the file.
I had a TIFF file which would crash while triggering an error, inside g_logv()
code (and according to the stacktrace, even probably inside some lower level
printf implementation code).
The reason was that I already processed the variable list with
g_strdup_vprintf() and printf didn't like this va_list being reused, then
segfaulted with some "Cannot access memory at address" error.
The alternate fix was to first copy the va_list in the first use with
va_copy()/G_VA_COPY, yet since we already processed the format data, I thought
it was useless to do this. Let's just directly use the formatted string.
Apparently GDK/Win32 sends the "grab-broken-event" signal before the "clicked"
signal. This has only been changed since GTK4 so far.
Anyway the bottom line is that GimpContainerPopup would process a handled on
"clicked", using the object destroyed when "grab-broken-event" happened as
callback data. The solution is to make sure that the object stays alive long
enough. So I'm changing gimp_editor_add_button() to connect to signals with
g_signal_connect_object() (since all usage of this function was used with
GObject callback data, it was not a problem).
See discussion in !815.
As a side change, gimp_container_popup_dialog_clicked() should emit the
"cancel", not "confirm". This part was taken from MR !815 by Lloyd Konneker.
is positive or zero. Sometimes the calculated `y` or `bg_y`
values are negative because the histogram value was divided
by zero (when max == 0.0).
Resolves: #9132 (Gnome/GIMP bug tracker)
Exports the following PAM formats:
GRAYSCALE, GRAYSCALE_ALPHA, RGB, RGB_ALPHA.
As with import, the main difference is the header and transparency.
Raw PPM export code is reused for the actual data.
PAM files are essentially PPM files with a different header format and
alpha/16 bit support.
Jörg Walter's 2.2 code was updated and implemented to read the revised
header format. The existing PPM loading code works with PAM files.
Largely inspired by commit dddb23c6. This also gave me a good overview of the
various missing features in GAction (compared to GtkAction) and how we'll have
to implement this in GIMP core. I now have a very clear path of what remains to
be done.
… don't include it from public gimpui.h.
As reviewed during !786, if this file is private, the name should show it
clearly. And of course, we must not include it from another public header, since
it won't be installed.
This also fixes building plug-ins with gimptool as reported by tmanni:
e00f2d7f50 (note_1650791)
Nothing was really clearly specified until now, which was kinda equivalent to
the string being in the OS encoding as used by GLib. Since this string will
usually be statically hardcoded in code (and not extracted from system), it's
just much easier to request UTF-8 for this specific case.
As per the changes in commit 005b3a05b8 and discussions in !800,
gimp_locale_directory() returns a string in the OS encoding for all but Windows
(UTF-8), i.e. the "filename" type in GIR annotations.
It relied on the now non-existing max-rgb plug-in, which was removed in commit
dd89f4a3d5. After some thoughts and discussions, the Predator script is fun, but
clearly not a mandatorily "needed" one here, which is why — instead of
re-integrating max-rgb —, I have decided to also remove Predator.
Both these script/plug-in are not totally dead. They were moved to the
gimp-data-extras repository and even ported to GIMP 3.0 API. They can be an
interesting use case for a fun extension to be installable through our future
extension platform. To be continued.
Rename "Crop to Selection" to "Resize Layers to Selection" since it's not
necessarily a crop. The layer dimension can also grow now.
Also specifying "Layers" because action titles can also be displayed
off-context, such as in the action search, so we must be more detailed with our
action titles. Similarly adding a "Layers" to "Crop to Content".
On Windows fopen () is limited to the current codepage,
GLib's g_fopen () instead accepts full UTF-8 by calling
_wfopen () internally (or a similar wide-char CRT routine).
We don't want to fail the build configuration just because we can't test for
runtime dependencies. In such a case, just assume it's good as we at least have
libheif and we can compile.
Fixes:
> ../meson.build:756:2: ERROR: Can not run test applications in this cross environment.
Even though, some format support might be missing, since codecs can be added at
runtime, it can always change later without having to touch GIMP. Yet we won't
be able to edit the desktop file when this happens.
See new comments in #9080.
Without this change, meson outputs this warning:
> meson.build:868: WARNING: add_languages is missing native:, assuming languages are wanted for both host and build
From libheif >= 1.14.0, the pkg-config variable will become bogus and always
return 'yes' so we now need to check for codec avaibility at compile time the
same way we look for these at runtime.
It may seem irrelevant to do these checks since these codecs can be added
anytime later, but it's still very good information for packagers to immediately
see that we have runtime package missing.
Do not call the undeclared exit function. Implicit function
declarations are likely not going to be supported by future compilers
by default, changing the outcome of this configure probe with
such compilers.
This plug-in has a partial GUI (a FileChooser dialog is launched).
However, you could only save the active gradient rather than choosing
any of them like the 2.10 version of this plug-in.
This patch ports the original UI so you can choose both the gradient
and file in interactive mode.
It's a test plug-in which doesn't actually need an image to work, so it's
annoying that it currently requires one (making testing more cumbersome).
Also cleaning up a bit the coding style.
Also make the start checks a bit more robust to broken core code by
double-checking that the palette is valid from the start, even though getting an
invalid palette should normally not happen anymore (at least I fixed one such
case with a palette with a NULL id in my previous commit; but it looks like our
core code is not perfectly robust and we should push the code to extensive
testing).
Note that the generated widget is currently ugly (no label and terrible UX), but
this is meant to improve soon.
When the core sends a NULL resource, which would be the default for object args,
hence is also what you get for the first call of a plug-in with a resource
parameter, libgimp was creating a GimpResource with NULL id, which is invalid.
It is much better to return NULL (since we made it so that NULL is a valid
value) and let the plug-in handle the NULL value as it sees fit for a given
parameter (they could just set the contextual resource for this type, or keep
NULL to mean "no resource selected").
This fixes failing to run plug-ins the first time (before any "last" values are
set). E.g. I had the issue when testing palette-sort.
Also I'm improving the error message when trying to use a non-installed resource
(it will now also print the resource ID and the error message). And the GError
was leaking in this case, so I properly free it now.
… moved to the implementation file.
When declaring with G_DECLARE_FINAL_TYPE(), the whole concept is that the struct
is made private (which also allows the type to evolve without breaking ABI if we
some day decide to make the class derivable). For this to make sense, the struct
goes in the implementation file, not the header.
For the rest, it's mostly alignment bugs and the like.
It is apparently how dependency names are supposed to be spelled to be taken
into account. The previous commits fixed some, but missed 2. I'm not sure they
will actually end up in the right-side list of the docs (it looks like when a
dependency is not actually found in the API, it isn't listed there), though it's
at least always listed in the left side, as I can see it.
And while I would prefer the upstream "display" name (i.e. GEGL and babl instead
of Gegl and Babl), better be consistent in how we list these dependencies in the
libgimp and libgimpui docs.
See discussion in !811.
Fixes:
> libgimp/gimpresourceselectbutton.c:510:9: error: a label can only be part of a statement and a declaration is not a statement
> 510 | GimpResource *specific_value;
As well as some coding style bug (space after '*').
This fixes the VAPI build. I am actually astonished the lib build seem to have
passed and that we didn't get double definition clashes.
The build error was:
[750/2424] Generating libgimp/gimp-ui-3.0.vapi with a custom command
FAILED: libgimp/gimp-ui-3.0.vapi
/usr/bin/vapigen --quiet --library=gimp-ui-3.0 --directory=/builds/GNOME/gimp/_build/libgimp --pkg=babl-0.1 --pkg=cairo-1.0 --pkg=gdk-pixbuf-2.0 --pkg=gegl-0.4 --pkg=gio-2.0 --pkg=glib-2.0 --pkg=gobject-2.0 --pkg=gtk+-3.0 --vapidir=/builds/GNOME/gimp/_build/libgimp --girdir=/builds/GNOME/gimp/_build/libgimp --pkg=gimp-3.0 --metadatadir=/builds/GNOME/gimp/libgimp /builds/GNOME/gimp/_build/libgimp/GimpUi-3.0.gir
GimpUi-3.0.gir:22111.7-22111.33: warning: Virtual method `GimpUi.ResourceSelectButton.draw_interior' conflicts with method of the same name
GimpUi-3.0.gir:26688.73-26688.73: error: The type name `ResourceSelectButtonClass' could not be found
GimpUi-3.0.gir:26695.73-26695.73: error: The type name `ResourceSelectButtonClass' could not be found
GimpUi-3.0.gir:26704.73-26704.73: error: The type name `ResourceSelectButtonClass' could not be found
GimpUi-3.0.gir:26712.73-26712.73: error: The type name `ResourceSelectButtonClass' could not be found
GimpUi-3.0.gir:26720.73-26720.73: error: The type name `ResourceSelectButtonClass' could not be found
Simplifies chooser widgets (e.g. GimpBrushSelect) by eliminating attributes (e.g. opacity) of chosen resource.
See #8745, but this commit fixes that by first refactoring the code.
Refactors GUI widgets (e.g. GimpBrushSelectButton and GimpBrushSelect etc.)
Refactor by "Extract class" GimpResourceSelectButton from GimpBrushSelectButton etc.
This moves common code into an inherited class (formerly called GimpSelectButton)
but the subclasses still exist.
The subclasses mainly just do drawing now.
Refactor by "Extract module" GimpResourceSelect from GimpBrushSelect etc.
Moves common code into one file, generic at runtime on type of GimpResource,
that is, the new code dispatches on type i.e. switch statements.
In the future, when core is changed some of that can be deleted.
The files gimpbrushselect.[c,h] etc. are deleted.
The module adapts the API from core to the API of callbacks to libgimp.
Note that core is running the resource chooser (select) widgets remotely.
Core is still calling back over the wire via PDB with more attributes
than necessary.
The new design gets the attributes from the resource themselves,
instead of receiving them from core callback.
The libgimp side adapts by discarding unneeded attributes.
In the future, core (running choosers for plugins) can be simplified also.
Fix gimp_prop_chooser_brush_new same as other resources.
Finish changes, and clean style.
Annotations
So procedures can declare args and GimpProcedureDialog show chooser
widgets
Fix so is no error dialog on id_is_valid for resources
Palette.pdb changes and testing
Memory mgt changes
Gradient pdb
Font and Pattern tests
Test brush, palette
Cleanup, remove generator
Rebase, edit docs, install test-dialog.py
Whitespace, and fix failed distcheck
Fix some clang-format, fix fail distcheck
Fix distcheck
Cleanup from review Jehan
It is better to add a comment rather than simply disabling these 2 calls without
explanation on macOS. This way, developers who'll look at this code in the
future will immediately know what's the reason and status for the "unicity"
concept of GIMP process on macOS. Basically there are 3 features:
- Opening files from another software (such as "open with" in file browsers)
which is handled differently in macOS and apparently works fine. It looks like
it works by handling system signals, connected from gui_unique_quartz_init().
- Opening files by running a new GIMP process which would pipe the filenames
into an existing GIMP process before immediately exiting.
- Running batch process in an existing GIMP process, also by running a short-run
GIMP process.
The last 2 features are simply now officially disabled in macOS because dbus is
not installed by default and seem like it may cause issues when it is.
See discussions in !808 and #8997.
DBus can cause instability on the MacOS platform, and regardless
MacOS handles application uniqueness already.
The batch version has also been modified as it only applies if
compiled as an application, since it returns FALSE if it is complied
as a console app.
These are not used anymore anywhere in our codebase! I'm sure some issues still
exist in various places, yet we can now consider that the multi-item awareness
project is finally over! Wouhou! 🥳
One big question which remains is whether I want to get back to the old naming
of "active" items, rather than "selected" items. The main reason to change the
wording globally was to be able to easily find remnants of non-multi-item aware
code. Now that it's all gone, I could very simply revert to the old naming.
This is in particular a big question for the public API for plug-ins, as the
"active" wording has been used for decades litterally. The only difference now
with how it used to be is that we could have several active items at once.
- Duplicate and Delete Paths are now both callable on several paths at once.
- Path Edit and Edit Attributes can only be run with exactly one path selected.
- Merge Visible Paths obviously always worked with more than one path.
- "Discard Text Information" work on all selected text layers.
- "Text to Path" creates as many paths as there are selected text layers.
- "Text along Path" still only works with exactly 1 text layer and 1 path
selected.
This is because gimp_drawable_edit_clear() would also clear the full drawable in
the special case when there is no selection at all. So as we were inverting the
"all" selection, we were ending up in this special-case.
RGB 0..255/0..100 and LCh/HSV settings are now remembered when closing
and reopening GIMP.
A few enums were explicitly cast to GimpColorSelectorChannel to clear
some compiler warnings.
This second GIMP_IS_ITEM() test was obviously for the iter2->data item. This
fixes handling cases when aligning/distributing a mix of GimpItem-s and guides.
I'm not sure if there are a lot of cases where we might want to use the layer
extents for items to align while using the contents extents for the reference
(or the other way around). It looks to me you either want one of the other for
all the items in the most common case.
So for now, let's apply this option to both the items to align and the reference
item. We'll see if anyone wants a separate option some day and has a good use
case to submit for this.
Trying to arranging both doesn't make sense and only end up in weird result. If
both the parent (layer group) and one or several child items are selected, just
arrange the parent.
This extends the work done in !778 to open the GEGL operation dialogue
automatically when selected from the menu, rather than requiring the
user to click on the canvas first.
Python 3.10 introduced sysconfig.get_default_scheme() and somehow Debian decided
it was a good idea to move from the 'posix_prefix' to the 'posix_local' scheme.
See: https://lists.debian.org/debian-python/2022/03/msg00039.html
The main issue with this scheme is that it adds a local/ subdirectory to the set
--prefix. As a consequence, with --prefix=~/.local/, scripts are installed in
~/.local/local/bin/ (instead of proper ~/.local/bin/), data are now in
~/.local/local/share/ and so on.
As expected, this broke a lot of CIs for a lot of projects, as well as a lot of
custom scripts, usage of Python in virtualenv (this later case seems like it is
fixed by special-casing it in Python 3.11), flatpak, etc.
Setting DEB_PYTHON_INSTALL_LAYOUT environment variable to "deb" solves this by
changing the default scheme.
This URL is also useful to understand the issue:
https://askubuntu.com/questions/1406304/virtualenv-installs-envs-into-local-bin-instead-of-bin
As a side note, Debian is not the only one which made the mistake. Fedora also
did the same thing (and they have also their own different environment variable
to handle this): https://bugzilla.redhat.com/show_bug.cgi?id=2026979
Adds import and export support for clipping paths in PSD files.
On import, path name and flatness value are saved in parasites.
Prior settings are loaded in the GUI on export.
Add a new type 'byte' to be able to handle binary data while still
retaining the utf8 char and string behavior.
Internally the file and string port and character handling have
been reworked to use the new byte-centric functions.
Also adds a new test script (test9) that tests byte, char and
utf8 string handling.
Only libgimpui depends on GTK+, display servers and other GUI-related
dependencies. There was a problematic include added in commit 0b56aa0d13 for
macOS, but the needed code (testing the macro GDK_WINDOWING_QUARTZ to use some
[NSApp activateIgnoringOtherApps:YES] API) doesn't seem to be present anymore in
there, so I think that removing this include (replace by including GLib for
other calls) should work fine. Of course, we'll know it when the separate CI
will test a macOS build as we still don't have in-Gitlab macOS jobs. :-/
This will allow to also check the list of runtime builds. We could see an
example in a report (#8993) where someone had the latest flatpak build of GIMP
but an older build of the runtime flatpak. So they had a bug because of a
dependency which got updated since then.
Add several missing help ids, remove those that are not used anymore,
and update "gimp-colorselector-water" to "gimp-colorselector-watercolor".
Also add a comment why some help ids are not used directly.
In the last few days, our deps-win64 job started to fail with:
> $ update-alternatives --set x86_64-w64-mingw32-g++ /usr/bin/x86_64-w64-mingw32-g++-posix
> update-alternatives: error: no alternatives for x86_64-w64-mingw32-g++
The reason lies in this change in Debian testing 10 days ago:
----
gcc-mingw-w64 (25) unstable; urgency=medium
* Upgrade to GCC 12. Closes: #1023679. It is no longer possible to tweak
the installation directory for different thread models, so the -posix
and -win32 packages are no longer co-installable.
* Drop “Built-Using” from “Architecture: all” packages.
* Since the POSIX and Win32 packages are no longer co-installable,
drop support for alternatives and use symlinks to provide the full
set of command names.
* Standards-Version 4.6.1, no change required.
-- Stephen Kitt <skitt@debian.org> Mon, 12 Dec 2022 09:00:34 +0100
----
So from now on, we'll only install the posix variant of the cross-compiler.
Hopefully it will work for all packages we build.
Adds option to export JPEG XL images in CMYK/A format.
Key and Alpha data is saved in extra channels, and the
simulation profile is saved as well.
Per the specification developers, the format does not
support 'naive' CMYK conversion, so a profile is required
for export. The option will be disabled if not set.
Checks if file has an extra key channel for CMYK. If so, it is combined
with the image's CMY image to create a CMYK buffer for import.
Color profile is stored as image simulation profile.
If alpha channel is present, it is now loaded as well for CMKYA images.
The URI will be: https://developer.gimp.org/core/maintainer/release/ (once we
merge the testing website to the main)
The new procedure also contains a wrapper step where we paste the checklist,
markdown-formatted, into a Gitlab report for better progress follow-up and also
onboarding testers into the release procedure.
The current code was wrong, hence was producing wrongly versioned shared
library files. This commit do it the same way as we do it on autotools build,
and additionally compute the library version (since "current:revision:age" gets
transformed into "(current - age).age.revision" by libtool, but meson doesn't
use libtool so we have to do this ourselves).
Now meson and autotools builds produce the same result at least. There are still
some points I'm wondering and which we should handle before GIMP 3.0 release:
* Since meson doesn't use libtool (and no .la files are created), should we
actually stick to libtool version scheme? It seems like some projects would
use semver instead. On the other hand libtool version gives a bit more info.
* Also it raises the question on whether we want the API version to be semver at
all or simply follow GIMP version? It used not to be much of a problem as we
wouldn't add features (hence new API) on micro version, yet now we can. So
GIMP program's version could not pass as semantic versioning. On the other
hand, having a diverging API version (whose minor version would increment
faster in particular, with regular micro version resets) would be confusing
too.
* If we keep libtool versioning, I'm thinking we should do it manually. It's
actually pretty easy with a good docs (or even just following GNU docs:
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html),
and simple to understand whereas the current code logic is very weird and we
end up with huge current and age values with complicated computation.
Note also that I raise the "Libtool versioning" section near meson.build top and
updated gimp_interface_age to be the same as on autotools currently.
- The <_p> or <_li> syntax for localizing AppData is the old code logics from
intltool.
- Mailing lists don't exist anymore. Move all usage on discourse.
- Microsoft Store is only for stable builds.
- Let's always merge `origin/testing` into `master` on gimp-web module (no
cherry-picking) as it's clearly the procedure we've been doing for quite some
time now.
GtkTreeView has an "interactive search" feature built-in, which basically kicks
in with the Ctrl-F shortcut by default. Let's hijack this feature and trigger
our own new search popover which is much more powerful (multi-item selection,
ability to use regexp or glob search by enabling these in Preferences, etc.).
This was an idea by Aryeom who wanted to be able to hit Ctrl-F to search for
layers.
These are typically debug outputs and we don't want them to appear on stderr of
release builds. They confuse people (some tester would report these on IRC when
we last release GIMP 2.99.14).
So let's not show these debug text on release versions.
Only the libwmf patches are still different. Apparently we may have fixed the
same bugs in different way on both branches. We should look later in details to
see if some patches are better than the other.
This adds a check to make sure icon is valid when displaying
the icons in order, to prevent duplicates showing there and in the
invalid list at the bottom
It's probably unneeded as the 2.99 installers are transient and anything
installed by GIMP 2.99 won't be in stable 3.0 anymore. Still, it's nice not to
have any weird warnings even in dev releases.
This explains such WARNING over a previous installation on Windows:
> (gimp-2.99.exe:11524): GLib-GObject-WARNING **: 21:36:36.664: Two different plugins tried to register 'ControllerDXDInput'.
The previous install was autotools-built, so it didn't have the typo.
When the clipboard contains raw image data or single layers, it's the same as
the normal "Paste" (and "Paste In Place" respectively). These actions are useful
if you want to copy a bunch of layers and paste them "merged" into a single
layers (since now the copy-paste of multiple layers will create multiple
layers).
It is somehow similar to the "Copy Visible" action except that it works on
selected layers only and work at paste time, making the action more versatile.
There are so many paste options and I feel that the "Paste into Selection*"
actions are advanved enough that they can go into submenus. So I move them into
"Paste as". The other reason is that I'm going to add 2 more options!
I hesitated to rename the "Paste as" submenu but we couldn't find a good naming
(except just "Paste" but it's redundant with the default action and "Paste…" but
this usually implies a dialog, not a submenu).
Last but not least, I renamed the various paste actions to contain the word
"Paste" in it. E.g. s/New Image/Paste as New Image/. The old naming made sense
when action labels were only displayed in menus. But nowadays they can be shown
in other more independant context, such as the action search (and just
displaying "New Image" in there is very misleading).
When dropping a buffer, we just consider it like common data pasting, hence we
leave the GIMP_PASTE_TYPE_NEW_LAYER_OR_FLOATING algorithm decide what type of
paste it will be.
There were a lot of incertainty of what should happen when we copy layers being
descendant of each other (i.e. when you select a group layer and some of its
children), then when you paste such data. So we sat down with Aryeom and tried
to come up with some consistent behavior which is somewhat expectable, but also
which would allow the most use-case.
Otherwise it was making very weird result when pasting the data, duplicating
some layers and whatnot, which was obviously a buggy behavior and never the
expected result.
We decided that if you select one leaf item, then even if you also selected a
parent item, it would be as though the parent was not selected. This is very
often what you expect anyway when you select a whole bunch of layers and would
work well if, say, you shift-click over many layers in sub-groups. Then you
wouldn't have to manually ctrl-click to unselect every group.
Then what if you were instead expecting to copy many groups? Then you could
shift-click the group arrow, closing all same-level groups. Once they are all
closed, you can shift-click the groups to only select group layers, not their
contents.
This way, both use cases are still quite doable easily with this default choice.
After further discussions with Aryeom, we had to make decisions about a few
problems. The main problem was: what happens when we copy a selection of a layer
whose bounds don't intersect with the selection?
The silent treatment of discarding the layer was not acceptable, because e.g. it
could happen on huge set of selected layers (like say you copy 100 layers with a
selection: you expect 100 created layers and if you realize you don't have them
all — e.g. you have 99! — after hours of work, trying to find the missing one
can be a huge time loss).
The status bar notification (or even error) did not feel right either because
this can typically be missed easily. Also it doesn't give a lot of feedback
(e.g. you might want hint to find the non-intersecting layers, in case it was
not supposed to happen).
An error box was even considered, possibly proposing to ignore the problematic
layers, or even giving easy ways to find them.
Finally what if we let the selection happen regardless the non-intersecting
layers? What should the dimension and offset of said layers be?
In the end, we went with the more consistent behavior of always creating new
layers of the exact same size as the selection. It can be considered as a rule
which would make the behavior predictable. For the non-intersecting layers, we'd
just have new layers with the dimension/offset of the selection bounding box,
and no contents. For other layers, they'd be also this same dimension, possibly
increasing the dimension of the source layers (though any new pixel is fully
transparent obviously). Aryeom wondered if some people might absolutely need for
their workflow that the new layers stick to the origin bounding box. But we felt
it was enough of a stretch that we'd try this way for now.
Note: of course if some day we get infinite canvas/layers, this whole discussion
could be less of a problem anyway! This was Aryeom's conclusion! Ahahah!
This is also work-in-progress for better copy-paste handling for multi-items.
Until now, I had decided that, if a selection existed, a copy would copy a
merged version of the selected items. But sometimes you want to have a piece of
each layer, each piece in its own layer. Also you may always merge the pasted
layers afterwards.
So now we will indeed create as many layers out as there are layers in. Being
able to copy a merged down version of all selected layers is still an
interesting feature though. We might add a dedicated "Copy Merged" action,
similarly to the fact we have a "Copy Visible" (which does the same thing but
for all visible layers, not specifically the selected ones).
Position of pasted image data was getting very bad lately, especially with the
multi-item selection logic which confused the hell out of the legacy algorithm.
So I reviewed it a bit, in light of the multi-item abilities, as well as the
recent no-floating-selection paste changes.
One of the particularly wrong paste position was when pasting one or several
pieces (through selection) of existing layers. The positionning was really bad
and sometimes even off-canvas (which was explicitly forbidden by the algorithm,
except it was broken now).
Now the behavior is much more reliable and consistent, by centering on viewport
or on target drawables. If there are several such targets, their bounding box is
used as target position (and the bounding box of all source drawables is also
used now). An interesting consequence of this is that copy-pasting quickly
without removing a selection paste "in-place" since the target this time will
use the selection bounding box.
Aryeom and I are doing some work on specifying copy-paste (based on existing
logic, we tried not to disrupt too much years of logic, but also keeping
consistency and new logic for recent changes, such as multi-items). It will all
be written down into the GIMP developer website, section "Specifications".
When several drawables were selected, it was pasting at the top of the layer
stack. Instead, paste over the top selected layer ("top" visually in the Layers
dockable).
There was the question of: what should we do when pasting over a layer group.
Should we consistently paste the new layers above the group or inside the group?
After discussions with Aryeom, we decided to stay consistent and paste above, at
least for now.
This changes the default selection pasting behavior to be a new layer,
rather than a floating selection. It also removes the
"Paste as New Layer" submenu options as they are now redundant.
The histogram is still not multi-drawable aware. In the future, it would be nice
to add ability to generate histogram for all selected layers (merged and as
separate images) as well as the whole visible image, therefore 3 possible cases.
But for now, it's alright like this (no more, but no less feature than before)
and at least we got rid of the last usage of functions assuming single item
selection.
- Option dockable is named "Align and Distribute" rather than "Alignment".
First, because it's not just about alignment; also because this way, it looks
like other software, such as Inkscape; lastly because it's more consistent
with other tool options ("Move", "Rotate", etc.).
- Add a tooltip to the Anchor Point widget to explain what it's used for.
- Rewrite various align/distribute button tooltips to make clearer that we are
aligning anchor points with specific edges (or distributing these anchor
points).
- Rename the first section to simpler "Targets".
- Some more rewording of other texts.
It's clearly broken right now. I can see it might have been used even to
progressively shift aligned items, but this was not used anymore. As for being
used while distributing, it doesn't make any sense anymore with the new logic of
not moving the extreme (first/last in coordinates) items.
I can see how an additional concept of offset can be useful in some situations,
but for now, let's get rid of this. We'll see in the future if someone asks for
it and provides valid use cases to work from.
There was one case in Inkscape which we could not do: distributing objects
keeping even gaps between them. Until now, we could only distribute keeping even
distance between anchor points (top, left, bottom, right or center).
With these 2 additional distribute options, I believe that GIMP is able to do
all the Alignment and Distribution options available in Inkscape (not the
"Rearrange" or node features, neither the text align/distrib; I just mean the
common align/distribute on objects), and even a bit more thanks to the anchor
point system (e.g. in Inkscape, we can't left or right-align to a reference
object/image center, or we can't center to a reference left/right/bottom/top
border; but we can do it in GIMP).
The icons are hopefully temporary, until we can make better ones.
- Use g_malloc* functions instead of malloc, so we don't continue on
failed allocations unless we test for NULL.
- Make sure we don't iterate past the known number of control points (ncps).
- Safely allocate, initialize and free points. Since points seems to be
used uninitialized, we use g_malloc0 to set everything to 0.
After discussing with Aryeom, we decided that "Distribute" should work within
the current horizontal or vertical bounds, as this is how it is usually done in
other software (e.g. Inkscape). For instance, if there are 4 items, the first
and last (coordinate-wise) stay untouched, and only the 2 intermediate items get
distributed evenly.
Since the Reference is not relevant anymore for "Distribute", I undo part of my
previous commit, where I was organizing the reference setting into its own
section of the Alignment tool options. This setting is back as part of the
"Align" section.
- Adding a separate pivot widget to allow choosing which point of the items we
align or distribute. E.g. until now, we could only align the right side of
objects to the right side of the reference object, left to left and center to
center. Now these are independent. Therefore I can align the left side of
objects to the right border of a selection or a layer, and so on.
- Only keep 2 "distribute" buttons (for now). Most of the distribution actions
were basically broken or extremely hard to understand. Also they were
apparently mixing concepts of alignments with distributions. Now let's
basically only keep the bases: horizontal or vertical distributions.
Everything is still possible using a mix of alignment and distribution
buttons, and it's much clearer.
- Since the GimpAlignmentType was used nearly only there (except for some usage
like to store dock side or filter preview split direction, but these
GIMP_ARRANGE_* values were unused there), I removed the various enum values
which we don't use anymore.
- The Reference settings gets its own subsection in the Align tool options.
Until now, it looked like it only applied to alignment, whereas it applies to
distribution too.
Note: this is still work-in-progress, mostly some initial dev work to put some
algorithmic bases. We had some UI and specification discussions with Aryeom
already and some things might still change a lot.
There were various cases when the reference's on-canvas handles were not
redrawn, or drawn at all:
- When the reference is an image, we now draw them. It may seem redundant as
it's the image bounds, but it's still useful to see what are the reference
bounds in a glimpse. Moreover in "Show All" mode, it's even more useful.
- Start the tool, hence draw the reference handles, in oper_update() if not
started yet.
- When the "align-reference" property changes.
- When the display (active image) changes.
When the reference is a guide in particular, no distribution is possible (on one
dimension, the size is 0, on the other, it's infinite) and alignment is only
possible in one direction (depending on guide orientation).
I find these options always a bit unwise when people have no idea how to change
their mind. Therefore adding a tooltip with the information (though maybe we
should even do it even more clearly and adding that in checkbox text too?).
For this to happen, I've updated the main question to be "Keep the Embedded
Working Space?" instead of "Convert to * Working Space?". Basically now we put
emphasis on keeping the image's color profile as being the proposed action.
Therefore "Keep" is the default answer, on the right.
Yet "Convert" stays on the right too. There is no "Cancel" button anymore
because it is not a question we can really escape even though "Esc" still works,
and it still corresponds to "Keep", same as Enter now. The reason is that "Keep"
is actually the non-destructive option. So if someone really doesn't want to
answer and make an explicit choice, we do it for them with the only
non-destructive choice possible.
Also I'm changing "Convert" mnemonic to 'c'. I guess that earlier devs might
have used 'o' because it is the usual mnemonic for "OK", so it was right when
the question was "Convert?". But since now the question is the opposite, there
is no reason to make it look like "OK". Let's just use the first letter, which
is easier to guess (and not taken by any other button here).
I've been hesitating because I don't think "Convert" was the right default
anymore with our anyRGB move. Until now, it was kinda implying that sRGB (when
no preferred color profile was set) was kinda the recommended space. It's not.
If a file already has another space, it's probably much better to keep it.
First because "Convert" is often a destructive change (even more if the target
is sRGB), so for people who don't necessarily understand all the ins and outs,
we were kinda promoting a destructive default behavior.
On the other hand (and that's why I was hesitating):
* "Keep" is also what happens when we hit "Esc" so some might complain that
there is no easy "Convert" key anymore (there is alt-c, but it's for sure not
as easy as Esc or Enter). Basically it makes the "Convert" option always a
much more explicit choice (yet it is likely for the best for people who care
about their colors).
* There might have been many people who would just use the default (Convert
until now) without thinking too much of what was asked, and that was working
good because they would just publish on the web or similar basic usage. If
they continue just accepting with Enter without reading and understanding what
is asked, now they could publish images with a color profile (and we know it
doesn't always work perfectly on the web).
In other words, it might be the best default for professional usage now, yet
it requires to understand a bit what you are doing.
It's really a hard call!
Thanks to a report by Stefan Cornelius, we became aware that the flame
plug-in does no checking for correct input when loading a pre-saved
settings file.
I reworked the parser to read one or more values based on the type of
token, making sure we also don't read past the end of our token buffer.
All int values have a min and max value set. If any unexpected input is
encountered, we will give a warning.
The flame plug-in can read stored settings from a file. The expected
input is that a ; signifies the end of input.
However, with user input we cannot depend on this to be true, so we need
to make sure that we do not read past the end of our input buffer.
To do so, we add a length check.
We were using the plug-in name with underscores, which is incorrect.
Since nobody ever complained about this, this doesn't seem to be used
very often.
We will use the const that defines the plug-in name instead.
I added this option in commit 38d6783299. It makes the script stateful, able to
remember all previously processed DLL, hence making the whole job much faster
and efficient.
Adds a toggle to let users load TIFF pages with FILETYPE_REDUCEDIMAGE
tags. The specs do not state that these are always thumbnails, and they
may have other uses. We assume that if only one page with this metadata
exists then it is a thumbnail; otherwise, the toggle option is
enabled on load.
This was the last remaining bit in #8124. Basically I needed to check how
localization of menu paths worked. I was thinking of maybe have 2 arguments to
gimp_procedure_add_menu_path(), one non-localized (for default menu paths) and
one localized by the plug-in (for custom menus). That would break all plug-ins,
but also looking at our code, it's complicated to do right.
Instead let's just keep current API and add an example in function docs. We'll
see how we can improve the API if the very hypothetical problem I am foreseeing
actually happens some day: say a word in English translates to e.g. "Filters" in
some other language, whereas English "Filters" translates to yet another term;
in such case, this new menu would still merge with the default /Filters/ menu
when localized in this language, so we'd have the weird situation where the
custom menu label would have passed through 2 translations somehow.
But let's see how it goes. If we really need, in the future, we can deprecate
gimp_procedure_add_menu_path() and add a gimp_procedure_add_menu_paths() with a
base_path and a custom_path, while the custom_path would be expected to be
already translated.
Fixes:
> free(): double free detected in tcache 2
The file is closed also after resource_load() runs. Anyway it's better to free
resource on the same level they were created, so I remove the fclose inside the
function.
For the same file, which was saving in ~50 secs in RLE (now ~12), and ~80 secs
in zlib. It now saves zlib-encoded XCF in ~35 secs on the same machine with 8
threads.
Contributed code was not wrong, far from it! But the whole memory management was
a bit on the hard-to-read side. For maintainability, I prefer some simpler code,
which contains a bit more allocation but it's reasonable and at least much less
indexes to play with.
Also instead of gegl_parallel_distribute(), then waiting for each set of batches
to entirely finish, I'm using a GThreadPool which I progressively fill with new
batch data. And finally I'm running the gegl_buffer_get() inside the threads (I
know that we have only reads on the buffer at this point; also GEGL has an
internal lock mechanism anyway).
These actually do not provide a huge additional speedup (compared to the initial
speedup by just going multi-threaded), most likely because the I/O are now the
bottleneck anyway (which is quite a good thing!).
- Coding style fixes.
- Removing gimp_gegl_num_processors unknown variable which didn't exist (coming
from another patch from suzu. See discussion in #4985).
- Removing the `cleanup()` attribute to keep our code as generic as possible
without specific compiler extensions. Just free memory manually as is expected
in C.
Testing on a 115MiB XCF file, saving went down (on my machine, as average on
saving a few times) from about 50 seconds to 15 seconds.
This first version is already pretty neat, though we can probably do even
better.
This makes these buttons respond to scroll wheels again, a regression encountered in GIMP 2.99.x.
Code location and fix found by Massimo Valentini.
Fixes issue #6929.
Instead of storing vectors as properties, they have their own structure, which
make them able to store and load all the usual and common properties of other
items. In other words, it makes XCF now able to store locks, color tags and
several selected paths.
It seems I forgot to fix some usage of core gimp_vectors_export*(),
which now take a list of paths (not a single path anymore since commit
9fc8260c7c), as these were used by PDB functions.
Missing functions were:
* gimp_image_get_selected_channels()
* gimp_image_get_selected_vectors()
* gimp_image_list_selected_channels()
* gimp_image_list_selected_vectors()
* gimp_image_set_selected_channels()
* gimp_image_set_selected_vectors()
* gimp_image_take_selected_channels()
* gimp_image_take_selected_vectors()
There are discussions of renaming GimpVectors to GimpPath, which would
also be consistent with the GUI and make the always-plural less akward
in API. We'll see. For now keeping named like this.
We should not check if all items are locked, but if one item is locked. It is
enough to forbid the translation from happening.
Otherwise it is currently possible to bypass position lock by using keyboard
arrows for layers or channels.
The action "select-float" should probably only work for a single selected
drawable anyway since a floating selection can only be stacked on one drawable
at a time.
Actions "vectors-fill*" and "vectors-stroke*" require a single drawable to paint
to. So action logic is unchange. I only replace gimp_image_get_active_drawable()
by gimp_image_get_selected_drawables() and counting the drawables.
Instead of using the layer borders, we use the bounding box for the contents.
This is similar to first run "Crop to Content" on every selected layer except
we don't actually need to crop. Therefore we can work on bigger layer than the
actual content while still arranging them based on content bounds.
So often the result of alignment/distribution feels wrong because it doesn't
correspond to the content we are seeing. With this option, we'll have the option
to choose the desired behavior.
The old interaction was quite horrible. I don't think I ever really got a good
use of it. It was so hard to understand what you were picking and so on.
Now that we can multi-select items, let's just use this as the base of what we
want to align or distribute. Clicking on canvas will now mostly be used to pick
an item as reference. From now on, only the reference object will get on-canvas
handle, making it very obvious how your alignment or distribution will work.
I leave only an alternative picking method (with Alt or Shift-Alt pick) to add
guides to objects to align or distributes, as these don't have a selection
dockable.
I'm also improving the selection of stacked layers by looping through them
(similar as the layer selection on canvas feature) so that we can select even
background layers which have a lot of layers showing above.
I am planning to improve this tool even further, but this is a first step to
make it actually usable within the new multi-item interaction logic.
Even though GIMP updated the name of the define for Create Template to
GIMP_HELP_FILE_CREATE_TEMPLATE, it did not change the id string.
In gimp-help this string was updated, causing help not found when asking
for help for Create Template.
This commit updates the string used for the help id to be the same as
used in gimp-help. It also removes the old define that is not used
anymore in GIMP.
This help id was used in the past but all references to it were removed
long ago with commit c53113d0cc.
Let's remove this define too since it causes a warning in gimp-help when
checking for help id's without documentation.
Loading an .xcf with a patterned outline caused GIMP to crash.
This is because PROP_GIMP was loaded at the end, so it was null when
text->gimp->pattern_factory was called. Moving PROP_GIMP to the
top of the property enum list ensures it's loaded first,
which resolves the issue.
This ports Massimo’s code to work in the latest version of GIMP.
It adds new outline-related properties to GimpText and GimpTextOptions.
These are controlled via the Text Tool Editor.
Cairo is currently used to draw the outline around the text.
Just add a no-op flush() as I think it's actually unneeded in the context of a
GtkTextView GUI. At least it doesn't cause issues with copy-pasted code or when
using external libraries using the sys.stdout.flush() interface.
- Don't forget to run gimp_ui_init() to get GIMP's styling in plug-ins.
- Process the "key-press-event" signal so that Escape key closes the window (as
it used to before the MR commit).
- Expand vertically the tree view, otherwise resizing the window leaves a lot of
ugly empty space, even though the tree view is still shown incomplete with a
scrollbar.
- Fix the Help button (which was doing nothing).
- Use full words for the "Refresh" and "Help" buttons, rather than icons. Text
is usually prefered for UI discoverability/understandability, unless there is
a space issue (i.e. too many icons for all of them to be words).
- Add a "OK" button too, and reorder the buttons similarly to how we usually
order them.
- Minor coding style fixes (alignments…).
Just "help" is not one of the standard icon names as per the Freedesktop Icon
Naming specification.
See: https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
Therefore when using this name, we usually don't have any icon (especially as we
don't provide any in our own icon themes).
Use "system-help" instead which is a standard name 'for the “Help” system
category'.
There is not only the ARCHIVE_OK and ARCHIVE_FATAL cases. There are also
ARCHIVE_WARN cases which should not break the installation (I think?). Since I
still want to pass the warning over to extension developers, I am printing it to
stderr.
As an additional fix, prevent such a warning when installing an extension over
itself. In such case, it looks like the archive_entry_size() would be 0, which
was triggering some "Writing to Empty File" warning.
We may return GIMP_PDB_SUCCESS with no image for generic file procedure, such as
is the case with .gex extension files.
file_open_image() already sanitizes the status returned by the plug-in, so at
this point, we should trust the returned status.
This fixes a crash when loading .gex files (GIMP_PDB_SUCCESS status yet a NULL
error).
Automake doesn't accept the "if else" syntax. Instead, we must add a new if/else
inside the first else block.
While I'm at it, I also add a G_GNUC_INTERNAL to the internal function
_gimp_pick_button_win32_pick(), though I don't think it's absolutely necessary
(yet explicit is better).
- app_activate_callback() moved with other private functions.
- Removing the `if (app)` test in app_activate_callback() as we don't
set it to NULL anymore. The app variable is always set.
- As a consequence of the previous point, change signature of
app_exit_after_callback() which doesn't have to change the value of
app anymore.
- Don't emit direcly the "exit" signal from app_activate_callback(). We
must call `gimp_exit (gimp, TRUE);` instead, which does more than just
emitting this signal. It also takes care of cleaning any remaining
images without a display. If we don't do this, we are leaking
GeglBuffer when opening images from command lines while quitting
immediately with --quit.
- Get rid of gimp_core_app_set_values() which was completely bypassing
the fact that all the properties of a GimpCoreApp were construct-only.
Instead make these proper properties. I use a trick used in other
interface, creating a gimp_container_view_install_properties() which
is called from child classes.
The point of GimpCoreApp is not just to share a common interface, it's
rather to weakly simulate some kind of multi-inheritance in GObject.
Since we want both GimpApp and GimpConsoleApp to inherit from a same
parent class while we also want them to inherit either from
GtkApplication and GApplication respectively (yet without linking to
GTK in this second case), we are stuck as far as normal GObject
inheritance goes. This is why we use an interface to which we add a
private struct through a GQuark trick. We want the property settings
and function implementations to also be part of this shared code.
- Get rid of all the abstract methods of GimpCoreApp of the form
get_*(). These are useless as we don't expect these to have different
implementation depending on the actual child class. Once again, our
main goal was to simulate multiple inheritance rather than actually
have an interface with various implementations.
- Make "no-splash" a property of GimpApp, because it's cleaner this way.
- Fix gimp_core_app_private_finalize().
- don't use #pragma once, it's not standard. Just use include guards.
- Fix includes: order was wrong, include from the source, not other
headers, etc.
- Clean various other details, coding styles, fix several more bugs and
more…
Reviewer's message (Jehan): This was a work-in-progress by Niels, which
we only keep in this state because Lukas worked over it. I have rebased
and fix-amended many broken part of this commit, because various things
had been changed in these areas of code since this commit was initially
written.
.ani files require metadata fields to be an even length. If the data
length is odd, an extra 0x00 is added for padding.
This patch updates the export and import code to comply with this
requirement.
Now text layers are proper types, which means that the binding API will also be
nicer (e.g. `txt_layer.set_text('hello world')` in Python).
This commit also adds the param specs allowing to create plug-in procedures with
text layer parameters.
Finally it fixes the few calls in file-pdf-save (apparently the only plug-in
using specific text layer API right now) with explicit type conversion.
After re-reading #534, I realized I missed the discussion about unsupported
markup by the tool. Then I tested and confirmed what Ian Munsie initially said
in a comment: unsupported markups are properly rendered in the text layer, yet
are simply dropped when editing with the text tool.
This is actually the ideal behavior as it means that with the API, you can even
go further than what is currently possible with the GUI. So it gives nice powers
to people who can script GIMP. We still need some warning in the function
documentation to tell developers about this weakness in the tool GUI.
It seems I had forgotten some hardcoded color in there. I didn't notice it until
now, because it was not that bad in the few instances where it was shown (for
instance the comment field in export plug-ins), but I really realized there was
a problem with the Python console which was not too practical (white writing on
kinda light background).
This complements the existing text_layer_get_markup function and allows
scripts to create and modify complex text layers.
It adds the <markup> root tag if it was not supplied and will run the
markup through pango_parse_markup() to check for errors.
Reviewer's (Jehan) note: this is a mostly untouched patch contributed in #534,
except that code moved around. I also fixed the header set in the .pdb, a link
to pango markup docs and added the meson changes.
Fixes:
> /usr/bin/ld: ../libgimp/.libs/libgimpui-3.0.so: undefined reference to `gimp_check_custom_color2'
I am actually unsure this fix is fine. It doesn't look like it should
work. And worse, I can't reproduce the fix by reverting it after.
The only other person who reported it was akk, with exactly the same
symptoms.
I noticed some buttons had a bluish border, showing the system theme leaking
over our default theme. So I'm just overriding this with a grayscale color.
These 2 new rules are especially useful in dialogs so that you know what happens
when you hit "Enter". The "default" action (.suggested-action in GTK CSS) is the
action we set to be the active one by default. E.g. if you open a dialog and hit
Enter immediately, without touching any widget focus, this is what will be
activated.
The GTK CSS .default action on the other hand seems to simply be the button with
focus right now, which can be changed through Tab or other ways. If both types
of styles are visible, the .default one is the actually activated action (not
.suggested-action), which is why I make its style a bit stronger (solid rather
than dotted and a bit more opaque).
Also I discover the shade() function to reuse a color and adding it
transparency!
Checked buttons had a background using the @selected-color. This was because of
a too broad rule on `.text-button:checked`. Basically it looks like the broad
rules are not good because they sometimes override more accurate rules for
specific widgets.
I also make a few more rules a bit more accurate. Also I extend some CSS rules
for check and radio buttons.
Adds an option to export as CMYK (mutually exclusive with the existing
Duotone export option). Header information (mode and number of channels)
are set, and the data itself is converted via Babl.
Layer channels are also hardcoded to 4, since GIMP currently doesn't
support CMYK channels.
We had some concept of slightly more extreme theme colors (i.e. darker in dark
themes) to color differently in some widget-in-widget cases.
For instance, we use this in the treeview list to separate it better from nearby
interface. But this extreme dark background may have been a bit "too dark", as
reported by Jacob. The goal is for this list to stand out, but maybe it was
standing out too much. Hopefully it's better now.
As a side change, I also add some borders to the top icon header (with "eye" and
"lock" icons) just above the list. I think it better explain the separation.
Just use an inverted logic for the selected text (i.e. white on black in light
mode, or black on white in dark mode). This is the usual logic for rendering
selected text anyway (except that we don't use non-grayscale colors, e.g. blue
background is common in system themes).
As diagnosed in #8649, using a guint32 for windows identifier may have been
right long ago (was it?), but is definitely not anymore. I can see that a XID is
an unsigned long nowadays (usually 64-bit on 64-bit Linux).
As far as I can see, on Windows, it would be a void* behind (which also
corresponds to the error message in #8649 description):
> typedef void *PVOID;
> typedef PVOID HANDLE;
> typedef HANDLE HWND;
Cf. https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types
I *think* that pointers would be 64-bit on Windows 64-bit, though I'm unsure
(after all, this is an OS with 32-bit long int on 64-bit arch!).
Anyway, it's just better to move to 64-bit window identifiers.
Since Clang 15.0.0:
> The -Wint-conversion warning diagnostic for implicit int <-> pointer
> conversions now defaults to an error in all C language modes. It may be
> downgraded to a warning with -Wno-error=int-conversion, or disabled entirely
> with -Wno-int-conversion.
This kinda reverts commit 6aebd30de1 ("app: remove
icon sizing preferences"), except that the code base is different enough since
this old commit was mainly for GIMP 2.10.x.
In any case, after initially thinking that GTK+3 handling for high density
display would be enough, we finally decide that adding back a Preferences-wide
setting for overriding the theme-set icon size is a good idea (additionally to
GTK+3 automatic support).
The base idea for removing the feature was that GTK+3 has high density display
support, through the "scale factor". Typically a high density display will
normally be set as using a ×2 scale factor so all icons will be double size.
Unfortunately it turns out it's not enough.
For instance, on very small screen estate, even with a scale factor of 1, if the
theme sets 24px toolbox icons, it may still take too much space.
Oppositely on huge screens, even with ×2 factor scale detected by the OS, the
icons may still feel too small (this is possibly what happens with #7023).
Furthermore there is also a matter of taste. Some people like small icons even
when they have the space. Others may want bigger icons, easy to click on.
Finally you can like a theme for its color scheme for instance, but it may not
have the icon size you want. Right now, we'd need to duplicate every theme in
small or bigger size. Instead of doing so, let's just have this global setting
overriding the theme rules.
Comparison with the 2.10 implementation:
- We still provide 4 sizes: small, medium, large and huge.
- We don't have the "Guess ideal size" setting anymore. Instead this is now a
mix of the GTK+3 scale factor logic and the theme-set or custom size. I.e.
that on a high density display with ×2 scale factor, we could have toolbox
icons up to 96 pixels (48×2)!
- We now try to have less custom code in widgets as we append the CSS rules to
the theme (similar to what we were already doing for dark theme or icon
variants). What happens in widget code is mostly to connect to changes in
themes and redraw the widgets which need to be.
- The custom size will now affect: toolbox icons, the FG/BG editor widget (in
both the toolbox and the color dockable), dockable tab icons, the main
dockable buttons, eye and lock header icons in item tree views, eye and lock
cell icons in the item lists.
There are still a bunch of areas where it is not taken into account, such as
plug-ins, and various dialogs, but even in custom-made interface in dockables.
Ultimately it might be interesting to have a way to sync more buttons and
widgets to a global size settings.
Lastly, I fixed a bunch of existing bugs where we were updating icon sizes with
gtk_image_set_from_icon_name() using the const icon name taken from
gtk_image_get_icon_name(). As this was reusing the same string pointer, we were
ending with freeing the icon name.
This was massively breaking GtkScale rendering. Or at least the marks (and mark
texts) added by gtk_scale_add_mark() were simply invisible.
I tried to figure why, staring at the GTK inspector and testing various CSS
rules to fix it without removing this line, but just couldn't make sense of it.
In the end, I'll just remove this line. It looks like in CSS (or just GTK CSS?),
it might be better to set rules on accurate widgets rather than too broad rules. 🤷
This is the needed improvements I was talking about in commit 00fbcbea0b. Right
now, when changing the icon size, the FG/BG color widget was not immediately
resizing. It needed a restart of GIMP.
Now it will properly react to "style-updated" signal, but also to "theme"
property of GimpGuiConfig.
The reset of the color icon pixbufs is also needed when GimpFgBgEditor size is
re-allocated.
When changing the theme, the style-updated signal is *usually* run, but not
always. For instance, moving from a theme with big icons to one with smaller
icons (or the other way around) sometimes work, and sometimes doesn't. I'm not
sure if it's to be considered a bug in GTK or if this signal depends on other
things. Anyway we have our own "theme" signal on the GimpGuiConfig and we know
exactly that we need to make sure that the icons are properly redrawn in such a
case. So let's just connect to this signal.
So what we read on the topic is to use (as base color) the gray which is
perceptually half-way between black and white. Unfortunately it can mean
different colors. For instance if using the sRGB TRC, the #808080 color is
sometimes cited.
Instead I went with the color LCH (50, 0, 0), i.e. with half perceptual
lightness in "CIE LCH(ab) float" babl space, i.e. #777777 in sRGB. It
corresponds to the 18.42% gray which is often refered to, so it seemed a fine
choice.
This replaces proposal in !683 because the contributor is not responding
anymore, and also it uses the common theme base CSS files used by all other
official themes.
Write both ICC and NCLX boxes for RGB AVIF to make sure that
all browsers render the AVIF images in same manner.
Use heif_init/heif_deinit in libheif 1.13.0+
Something I wanted to implement for a long time and today I finally took
the time after I had one more annoying case where I had to merge all
groups for exporting then undo for saving!
Now this won't be needed anymore as the plug-in will allow to export
only as pages any first-level layers (groups included, so you could
gather your page compositions in root layer groups). For me, it's the
only way I use this when making/editing PDFs with GIMP, but maybe some
people would still want GIMP to crawl into groups and subgroups and
export layers individually. That's why I make it an option, defaulting
at TRUE.
Note that I didn't port "file-pdf-save-multi" at this point, though I
did move to using GimpProcedureConfig instead of GimpValueArray
everywhere.
In any case, that's a lot of code removal and simplification already,
though some part of this plug-in is still a bit ugly.
We also get proper config storing between sessions now.
As for metadata, it unfortunately doesn't look like Exiv2 has PDF
support, so I didn't add metadata settings.
… gimp_procedure_config_save_metadata().
If you use gimp_procedure_config_save_metadata() or
gimp_procedure_config_end_export(), you don't really control the flags
and let the GimpProcedure API make somes choices for you, based on
various assumptions. One of them is that the procedure has specific
properties (named "save-*", either created manually or with the various
gimp_save_procedure_set_support_*() functions). So if you don't have
them, we should assume this format doesn't handle a given metadata
format and deactivate it.
For plug-ins with a different/specific logic, they are expected not to
use these helper functions. They would likely call lower level functions
such as gimp_image_metadata_save_finish() or the newer
gimp_image_metadata_save_filter(), where you control the metadata flags.
The dl*() functions are in libc directly. This probably applies to all
*BSD too. And from what I read, it should even apply to macOS, even
though a libdl is present there (is it bogus?).
So let's make the libdl check proper by only make it mandatory on Linux
(on Windows it was already unchecked too).
Fix the Linux Input test to correctly only depend on whether or not the
header is present. Having X11 target is not enough (e.g. it breaks the
build for NetBSD and probably on all BSDs).
This file was just moved as content/core/specifications/locks.md in the
pat/bootstrap branch of the gimp-web-devel repository.
This branch will soon be merged and become our new website. Removing the
now duplicate in our source repo.
- Use a relative path for GIMP_LOGO_PATH inside the gi-docgen generated
HTML, and not an absolute path taken from build dir (otherwise this
would break, for installed docs, but also for the tarball and the
developer website!).
- Also use either gimp-logo.png or gimp-devel-logo.png depending on
whether we are on a stable or unstable branch.
- Install these in images/ inside the GIMP docs folder, which
corresponds to the relative path given to GIMP_LOGO_PATH.
- The installed root dir will be $datadir/doc/gimp-2.99/, e.g.
/usr/share/doc/gimp-2.99/
- Inside this folder, the library references will be in libgimp-3.0/ and
libgimpui-3.0/ (instead of weird Gimp-3.0/ and GimpUi-3.0/). Note that
the root dir uses the application version (2.99) whereas the library
folder use the API versions. These are different in development phase.
- Archive the gi-docgen installed files, not taken from the build dir,
to avoid packaging temp files, such as the .toml files. Note that
`g-ir-docs` files are still taken from the build dir, as we don't
install them yet.
- Finally package all this in a directory before archiving in a tar.xz,
named the same as the directory (e.g. gimp-api-docs-2.99.13/ inside
gimp-api-docs-2.99.13.tar.xz).
We were using GIMP_UNSTABLE extensively to differentiate development
from stable code. But there is actually another level of development
code. Basically GIMP_UNSTABLE tells you are on the development branch,
e.g. for current branches, that you are on 2.99.* versions (vs. 2.10).
This depends on the minor version oddness.
GIMP_RELEASE will tell you if it's a release or a in-between-releases
code. This works with the micro version which must be even on release.
Any odd number means you are basically using random git code.
There can be any combination of GIMP_RELEASE and GIMP_UNSTABLE. For
instance 2.99.12 is a release of the unstable branch, whereas 2.10.33 is
development code of the stable branch.
I use this first in the update code as we were using GIMP_UNSTABLE for
both concepts but it made it harder to test. Now:
* GIMP_DEV_VERSIONS_JSON environment variable is only available on
development code, not on release (whether stable or unstable).
* The weekly check limitation is also only for releases (dev code just
check at every startup to quickly detect issues and regressions).
* Whether to look on testing website or public website json file depends
on the code being a release or not.
* Finally only whether to check "DEVELOPMENT" or "STABLE" sections in
the json file depends on whether we are on stable or unstable
branches.
This was not working due to a missing port in glib.
Potentially could be contributed upstream to GLib.
(cherry picked from commit b391f9f5c8)
Conflicts fixed:
app/gimp-update.c
Fixes:
> gcc: error: unrecognized command-line options '-mmx'; did you mean '-mmmx'?
> gcc: error: unrecognized command-line options '-sse'; did you mean '-msse'?
This is shown in the About dialog when a new version is available, but
also in the debug dialog (also when a new version is available).
Of course, for stable versions, we should still show the main download
page (which I double-checked current code does).
This meson warning was only showing when configuring a cross-compilation
project.
Fixes:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': meson.has_exe_wrapper. use meson.can_run_host_binaries instead.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
For meson, I want to be particularly careful and not follow the "Debian
testing" rule as it bit us by the past for babl.
But this bump is probably OK:
* Debian stable has meson 0.56.2.
* meson 0.56.0 was released on 2020-10-30.
* GIMP 2.99 is a dev branch with no end release date yet.
This should also fix this warning at configuration time:
> WARNING: Project specifies a minimum meson_version '>=0.53.0' but uses features which were added in newer versions:
> * 0.55.0: {'Calling "add_dist_script" with File, CustomTarget, Index of CustomTarget, Executable, or ExternalProgram'}
We missed it until now because it was only happening with tarball builds
where gitversion_h could be a files() object, unlike in git builds.
GIMP tried to open webp files as ani (animated cursor) files. The reason
for this is that for ani we had set the file magic as the first 4 bytes
should be RIFF.
However, RIFF is a container format, used by many different file formats,
among which is also webp.
This means that checking for RIFF is not specific enough.
Based on the info on http://fileformats.archiveteam.org/wiki/ANI
we will check the 4 bytes starting at offset 8 for ACON, which is
apparently the identifying part for animated icons.
Due to a typo in the config property "default-delay", loading of that
option and the ones after it, failed.
Because of this, default-chunks had an invalid value, which made our
export fail. After correcting the typo the export succeeds.
- Setting an exec_dir variable is an error. As meson docs says, if
relative, it is installed relatively to prefix anyway: "If this is a
relative path, it is assumed to be relative to the prefix."
On the other hand, it would make problems if someone tried to set an
absolute bindir.
Moreover it is a lot clearer now. When we want to install in the
binary directory unconditionally, then get_option('bindir') is the
meson way, hence the way to go.
- On the other hand, the `gimp-debug-tool` is installed either in bindir
for Windows or macOS and libexecdir for all other platforms, at least
that's how it's set in the autotools build. So let's keep both builds
consistent.
- Make a hopefully clearer description for enable-default-bin option.
Let's clarify this is just about creating unversionning links pointing
to versionned files.
- Adding an item in the "Optional Features" part of the summary listing
during meson configure, for better discovery.
For the ".exe" extension on Windows, I wished we had an $(EXEEXT)
equivalent on meson rather than trying to set it ourselves (are there
other platforms where we must set a different extension?). But I could
not find any.
and import as inches
When GIMP's display unit was mm, our PSD export converted the X and Y
resolution as if a conversion from mm to inch was needed.
However, PSD's resolution is always measured in pixels per inch, so a
conversion is never necessary.
Removing the conversion, resolves the issue.
created by Adobe Lightroom 5.1
Adobe products are known to write incorrect RichTIFFIPTC tags in TIFF
images.
Since libtiff correctly detects and handles this there is no real need
for end users to be warned. So instead of a warning we will only output
a message to stderr.
This is essentially the same check as done in gimp_image_set_resolution,
but doing it here means we can load the image instead of throwing an
error.
We still need to get replacement xres and yres values, because these are
used to compute layer_offset_x_pixel and layer_offset_y_pixel.
Image m2-d0f86ab189cbe900ec389ca6d7464713.tif from the imagetestsuite
is a fuzzed image with an invalid very high number for the channel count.
This causes GIMP to become unresponsive for a very long time. Possibly
trying to allocate memory for all channels or another cause related to
the high number of channels.
Let's go for a more "reasonable" limit of 99 channels like we also do
for Photoshop images and show a message when we find an image with more
channels.
When loading a TIFF image using a script/plug-in in non interactive mode,
we did not initialize the list of pages, causing a crash when trying to
access it.
So, always initialize this list when non interactive.
Due to a change in the format string in libtiff, warnings about unknown
fields were not filtered out anymore.
Adjust our filtering of warning messages so we catch this again since
end-users don't need to worry about this and we don't need the
possible extra issues.
This is purely fixing by meson rebuilds and some regexp fixes. I didn't
touch any semantic.
Basically the "&" XML entity should not have made their way to the
po files. I fixed our script in the previous commit, and now I just
rebuild the po files and clean the entity programmatically so that our
Windows installers for GIMP 2.99.12 release have valid text.
Here is what I did:
(1) I regenerated the pot and po files:
$ meson compile gimp30-windows-installer-pot
$ meson compile gimp30-windows-installer-update-po
(2) I opened all the po files in vim and regexp through them.
Get back the proper Report-Msgid-Bugs-To:
:bufdo! %s$"Report-Msgid-Bugs-To: \\n"$"Report-Msgid-Bugs-To: https://gitlab.gnome.org/GNOME/gimp/issues\\n"$ge|update
No translations were fuzzy in any po files before this change. I remove
all the fuzzy flags, but only if the msgid contains an ampersand, hence
leaving appropriate fuzzy strings in (the ones where the source string
changed since the last translation):
:bufdo! %s/#, fuzzy\n\([^&]*\)&/\1\&/ge|update
Then I replaced & in msgstr (msgid was fixed through the automatic
regeneration thanks to previous commit, but not the translations) with:
:bufdo! %s/&/\&/ge|update
(3) Finally I did a manual `git diff` review to verify all is good.
In particular, I had to fix a bunch of "E&xit". The string is probably
too short so gettext heuristic failed to consider it likely the same as
"E&xit".
… Windows installer localization.
There are kind of 2 separate bugs here:
- Direct i18n.gettext() to the proper data directory where to find the
ITS file. Otherwise `meson compile gimp30-windows-installer-pot` and
`meson compile gimp30-windows-installer-update-po` complained about
not knowing XML and falling back to C, which is obviously a problem:
> /usr/bin/xgettext: warning: file 'build/windows/installer/lang/setup.isl.xml.in' extension 'xml' is unknown; will try C
- Set gt:escapeRule to "no" in the ITS file, otherwise the XML entity is
kept as-is in the po file (i.e. "&" stays "&" inside the po
files), but it's considered as raw text when merged back to XML, i.e.
that the '&' is properly converted to a XML entity, so we end up with
a double escape "&amp;".
Now the po file will have a '&' which will still be converted to XML
entity at merge time. This is actually most likely better than asking
translators to handle XML entities themselves (with the possibility to
make typos and break the XML entity).
See https://savannah.gnu.org/bugs/?58643
- The mailing list URL is now a general discussion URL.
- Gather all discussion channels in a single section.
- Remove some outdated sentence about a web form for plug-ins (no idea
what this is, but clearly we don't have this anymore).
If we released first the modifiers, then the pointer button during
scrolling, we could end up blocked on scrolling. This makes sure the
button release is the finale scroll unlock, allowing modifiers to be
only used for starting the scroll.
It also fixes activating custom actions, by storing the action
description from the initial modifiers at press time, not release time.
This linear gradient really doesn't render any feeling of "background"
IMO. I only initially implemented it this way because the underlying
theme seemed to use such gradient effect on headerbar for background
dialogs, so I wanted to test this.
Anyway simply using the "disabled" color seem to work well. After all,
the semantic is similar too (if it's in the background, a dialog can be
considered inactive in some way). In any case, the meaning definitely
comes across now.
Don't use it only on menus. For instance, there were disabled checkboxes
(and their label) in plug-ins which were not showing different at all,
and it's confusing. Now both menu items, and other type of settings will
show similar "disabled" style.
Creates two new parasites to save the black point compensation status
and rendering intent simulation settings in GimpImage.
The parasites are saved and loaded as part of the image in the
.xcf file.
Something which is regularly asked is to use smaller icons. We used to
have a "Small" theme in 2.8, which got away in 2.10 with icon sizing (cf
issue #6121).
This is a revival of such a theme (except I call it "Compact" because it
feels more appropriate than "Small"). The theme is basically the same as
"Default" (through an include), just tweaking some size related CSS
rules.
Until now we were sizing the FG/BG area with hardcoded size ((40, 38)
which I'm not sure where it came from!). Now this allocation size will
depend on the toolbox icon size (I made so that the FG/BG area is more
or less the same size as former hardcoded values with large toolbar
icons).
I had to tweak a bit the size of the default FG/BG icons and the swap
icons, which were also hardcoded. They now also depend on the allocation
size, hence the icons size.
Note that this code still has a limitation: it won't resize when you
switch from a theme with one size to another size of icons. A restart
will be necessary. This is something we should improve.
… variant.
Now with my recent code, instead of creating 2 different themes, I make
it a single theme containing both a Light and Dark variant.
I move all semantic logic into common.css which will be included by both
variants after they set up their color definitions.
For choosing the basic gray to use for the dark variant, I first looked
up what is usually recommended. Most articles on the web about dark
themes would cite some "Material design" project (apparently originated
from Google) which makes guidelines for Android/iOS/Flutter and web
applications. Their guidelines recommend #121212 ("Dark Grey") as
background color. I tried, it's **really** dark. Maybe I'm just not used
to it, but it feels like it might be OK for small phone "apps" which
people might want to watch in the dark, but possibly not for a full
grown desktop software. I don't really know, I might be wrong and some
people might want to edit their pictures with such dark GUI.
Anyway for now, I settled for a base background #303030, which is
already quite dark, darker than Adwaita dark or than our 2.10 dark
variant, but at least doesn't feel like a black hole.
Instead of hardcoding the colors in CSS rules, make variables of them,
with meaningful semantic names. It will help with making consistent
design where a color means something and is reused in several places
(e.g. a color for "hovering" or "selecting").
I add some variants but not too much (e.g. treeviews had even lighter
background, with an inversion of logic, where selected items are on
darker background instead of lighter).
Colors in this theme are mostly the same before and after this commit,
except for a few parts where I felt that having more variants was
detrimental for consistency and maintenance.
As part of the changed colors:
- check and radio buttons' background just reuse the lighter background
color (as used e.g. in treeviews and entries).
- menus also use this lighter background color with the color inversion
(same as treeviews) for hovered items.
This commit also brings some improvements to disabled cases:
- Stylize also disabled tree view items (e.g. disabled actions in action
search were styled the same way as runnable actions).
- Stylize the same way disabled buttons drawn directly or with an image
widget.
The last use for this change is that it will help to create a dark
variant for the same theme using nearly the same code, hence get
consistent styling.
This way, what will happen is that:
- We can have a single "Default" theme which will have both the light
and dark versions.
- With our Default theme, when "Use dark theme variant if available" is
unchecked, we just follow the system-wide dark settings. (though I'm
unsure we actually do with current code; we do load our theme over the
system theme, which may be dark, but I don't think we'd load a dark
theme variant then)
- If the option is checked, we will load the specific dark variant,
bypassing system settings specifically for GIMP.
Technically for theme designers, all it takes to have a dark variant is
to add a gimp-dark.css next to gimp.css. `gimp-dark.css` is loaded
instead of `gimp.css` when the settings is checked.
Note: there is apparently a new freedesktop portal for setting the
prefered variant (and now it's apparently either light, dark or
default), which is now implemented by GNOME, KDE and Elementary at
least. It would be nice if we could grab this settings and use it if
available. The below link has code sample showing how to do it with
DBus:
https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/Dark-Style-Preference
- Indent all rules in Light theme with the same number of spaces for
style consistency.
- When GIMP was set in "Prefer dark variant", spin buttons and other
entries had too dark borders. Fix this.
- Fix the spinbutton entry's border radius which was at 0, but since the
buttons of the spin button are themselves rounded, it looks weird only
on the top and bottom left corners. So apply a 3px radius. I did this
in the System theme.
Makes the following changes:
*Toolbox Wilber is now visible
*Large black border removed from ScrolledWindow
*"Duplicate text" effect removed from labels
*Toolbox tabs are now stationary when changing selection
*"Add Tabs" menu background color changed to match Light theme
*Unnecessary border around Check Updates box removed
Optionally includes the previously saved
Duotone color space data on PSD export.
New load dialogue alerts user if duotone data was imported.
New export dialogue appears if the image is still grayscale and
the parasite exists.
If selected, the mode is set to PSD_DUOTONE in the header and
the original duotone data is written in the color space section.
These are issues which appeared to me only when GIMP was set to use the
dark theme variant. In such a case, I guess we see quite well CSS rules
coming from parent themes, such as the globally set system theme.
* Remove any background image (which may come from the system theme?) on
buttons.
* The headerbar was dark and when in the background, it had a dark
linear gradient (probably coming from my system theme). So make sure
the background color is right as a general rule, and add back a
(small) light gradient to indicate the background state.
* GtkListBox had a dark background. We don't have a lot of usage for
this widget yet, but a few (for instance in icon theme settings, or in
the modifiers editor).
* The GtkSwitch buttons were dark on dark. Set a light background. Also
when the switch is ON, I add a bit of color, not too strong, but
enough to indicate the checked status, because I find this widget
design not so obvious. Since I don't think we use switch buttons
anywhere else but in Preferences, this is probably not a big problem
as it should not affect color perception when working on the canvas.
Add the info about max dimension of WebP with WEBP_MAX_DIMENSION macro.
There is also a test about (picture->width / 4 > INT_MAX / 4), resp.
height, but this should anyway never happen as the C spec says the
smaller range for int is [-32767, 32767], which is an order bigger than
the current WEBP_MAX_DIMENSION (16383).
So we are probably fine assuming all VP8_ENC_ERROR_BAD_DIMENSION errors
will happen because of WEBP_MAX_DIMENSION.
Actually our X11 implementation is right, and the implementation from
the Freedesktop portal is "as far as it can do", i.e. that we get the
returned RGB value, which is unfortunately in display space. And it
doesn't return any space information together (we don't even know which
display the color comes from, in multi-display setups).
Therefore let's check if we are running GIMP on X11 and if so, let's
call this implementation first.
See this report on xdg-desktop-portal to get proper space info:
https://github.com/flatpak/xdg-desktop-portal/issues/862
We should set these explicitly, otherwise it will usually default to the
first of the enum, which is perceptual (which is usually not a proper
choice).
Relative colorimetric is usually the recommended default.
The GimpColorProfileComboBox widget requires the profile chooser dialog
to be explicitly constructed. It doesn't create it by itself.
I guess I hadn't tested clicking this "Select color profile from disk…"
combo item during review. I only selected visible profiles in the list!
This adds a Soft-Proofing pop-over menu when right-clicking the toggle
in GimpStatusBar. It lets users toggle proofing, using BPC and showing
out-of-gamut colors. It also lets users change the profile and
rendering intent.
Opacity and brush size are among the 2 most common tool options which
people might want to often change, though we should likely later add all
other common types of tool settings angle, aspect ratio, spacing, etc.
I am also unsure using the enum action is the right call because what it
does is just taking into account the distance from initial click to
compute an opacity. Instead it might be more interesting to increase or
decrease slowly or rapidly by going right or left from the initial
click. We'll see. But it's a first step.
The mouse controller had many limitations:
* It was not per-device.
* It was a long hard-coded list of events, which made its evolution
annoying and scrolling the list boring.
* It was starting at button 8, while the first buttons were supposed to
be hardcoded interactions. And it stopped at button 12, while some
device might have more buttons nowadays. See !386.
* The "Grab event" does not seem to work in many cases, according to
feedbacks.
The new GimpModifiersEditor will now handle any button (except the first
button, which is reserved for tools), you can even override or change
default canvas actions (panning, rotation, etc.). It should not be
limited with a max button number either (though I haven't tested with a
device really having a lot of buttons since I don't have any such device
but I did emulate huge button numbers on my stylus with xsetwacom and it
did work well; hopefully I'll get feedbacks). And now it can even run
custom actions.
So basically it should deprecate the mouse controller as the modifiers
editor can do everything the controller could, and more (unless I missed
anything).
Custom actions are basically any action (currently GtkAction) which can
be assigned a shortcut. Now they can also be assigned to an input device
button (with modifier or not).
* The relative brush size change was not implemented anyway. Maybe later.
* Also changing the defaults to GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE
which I think might be the most understandable size variant.
* Finally re-label "Rotate" to "Rotate View" as per Aryeom's feedback
because just "Rotate" is indeed confusing as it could mean several
different actions in GIMP.
Actually I am renaming GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE into
GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE, which allows to set the
brush size on-canvas, starting from center to border.
The new GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE now sets the brush size
from one border to another.
Space: panning
Ctrl-space: zooming
Shift-space: rotating
Ctrl-shift-space: constrained rotating
Note that these are still hardcoded, unlike the actions through
modifiers + pointer buttons.
There is really no need to make back and forth between a string and
int/enum representations, and it actually cause problems at times.
It's also a problem for the button representation where a modifier will
be represented as a key.
For now GimpModifiersManager returns the same modifiers as what was
previously hardcoded and we have no GUI yet to change the settings. But
the core of the new feature is in place.
This object's goal will be to manage customized modifiers per input
device button, which is why I add it to GimpDisplayConfig. It is in its
own new config file (`modifiersrc` in config dir) because it requires
GDK types access (well I could have done without, but it would have been
less semantic, hence not as good of an API). Anyway it is only useful
when running GIMP as GUI.
The GUI widget and the usage code to make this actually useful will come
in upcoming commits.
When no accelerator was set yet, display relevant information, and when
the button is toggled (waiting for shortcut input), display also
relevant info.
A widget to grab a shortcut provided interactively. It can also grab
modifier-only shortcuts so we will be able to use it for the new
on-canvas interaction customizability.
Maybe we'll use this later for the shortcuts dialog which should really
be improved some day and has a lot of known issues. We'll see.
Moving the "Space Bar", the "Snapping" and the new "Zoom" (MR !570)
settings there. The idea is that it will also be where we'll customize
more on-canvas related abilities, such as the new zooming behavior
preferences, but also possibility to customizing or disabling the
various canvas action, and finally customizing the new contextual
settings such as brush sizing or other.
… new action_pixel_size of GimpMyBrushTool.
MyPaint brush tool clearly shows the limits of my trick to have some
enum actions work with absolute values whereas others work with
per-mille values between the property min and max.
Indeed firstly MyBrush's "radius" value is logarithmic and can be
negative. Since the enum trick relies on the fact that negative values
are the semantic enumerated constants, it's broken in such case. The
second issue is that while it was acceptable to use int size for most
paint tools (even though they were double), here radius only goes from
-2.0 to 6.0; so using int values only would leave us with jumping brush
sizes.
So now I create a proper double action which simply takes pixel size and
use this from the on-canvas brush size changing. No weird trick, no int
or sign limitations.
I also add a new optional action_pixel_size in GimpToolControl.
Note: I'm also updating a bit the logic for the MyPaint brush outline
function gimp_mybrush_tool_get_outline(). Indeed after skimming a bit
through mypaint-brush.c code in libmypaint, I am not sure at all we need
to use the offset_by_random like this. And really this shown outline
seems more indicative than anything else when I see the actual size
printed by the various brushes. Finally here it was counter-productive
as I needed to get easily the logarithmic radius from the pointer
interaction on canvas.
These actions can be activated with a double value. These will be useful
to create new types of size action, which are based on accurate pixel
values instead of an enum hacked to set per-mille values between a
min/max.
Note that the other paint tool which is not as common as others is the
MyPaint brush tool. At first I thought the circle outline didn't work.
It does actually work, but the radius concept is simply very weird in
this tool so we have to move a lot. To be investigated.
Until now, it was only stopiing when releasing right click, but it's
actually more accurate when releasing the Alt key first as the button is
on the mouse/stylus (so releasing it can provoke small hand moves,
especially visible with stylus, I think). Now it stops whatever is
released first.
I started from mitch's patch (though code changed so it was not working,
yet I ended up with quite a different direction).
Modified from original proposition in #498:
* Do not mix opacity and brush size in a same action, one on horizontal
movement, the other on vertical. The problem is that it's hard to stay
perfectly horizontal or vertical, so you nearly necessarily change one
while changing the other and this would be frustrating.
* Do not just use modifiers, but modifiers + right click. The logics is
that left (or whatever is the first button) click is for the tool
actions. The middle click for navigation (panning, rotation, and even
layer navigation now). Right click for now is only for menu. With this
change, let's use right click for various settings-related changes
too. Also we already have people complaining with things like canvas
rotation happening unexpectedly even though it requires button clicks.
Imagine an action just made of modifiers! Many people would hit these
by mistake all the time!
* Focus on brush size only for now. Instead of just calling the action
repetitively with the "SElECT_NEXT" action as proposed in the original
patch by mitch, let's compute the actual size between the press and
release. This would allow to have a real visual hint and also would
make it a lot more useful and meaningful to be an on-canvas change.
Say you want to reproduce a stroke size on canvas. You can click the
center and expand to retrieve approximately the size without computing
it in pixels.
Limitations and future work:
* This is a first draft and I still want to test if it works well with
the "lock brush to view" and with scale factor > 1.
* I want to associate this with work done for #7034 so that visual hint
still appear even when we have no visual hint set.
* I am not so fond of with the way we use enum actions which doesn't
really make satisfying logics (I hacked a bit over it, but it's
getting ugly). I'm considering creating int/double actions to really
set some values with exact numbers through actions.
* Right now we need to stop the right click first. I want to be able to
stop the brush sizing with releasing Alt too.
* It would be nice to make this all more customizable, which is why I
called internal variable "mod1_setting". The goal will be to have
other types of actions possibly. Also it could be deactivatable for
people really not liking these or hitting these by mistake (while not
needing these). Same for the navigation shorcuts.
* Similarly the right-click menu could be deactivatable or switched to
other actions conditionally (through Preferences). It is doubtful how
useful it is (compared to using the same menus on top of the GUI)
though I don't want to just delete the option because some people
would clearly be used to it.
* I think we should start breaking down the whole tool events code a bit
more, in particular the function gimp_display_shell_canvas_tool_events().
* For more settings, a small on-canvas GUI could be of interest where
you could customize various values through sliders and buttons, and
also where you could put your favorite brushes or dynamics or whatnot.
It's not replacing the more complete dockable but could be a nice
quick version for fast editing.
Just duplicate the blurb into the help string. I'll leave it to someone
else to write a dedicated, longer help text if needed.
Also fixing the call s/Gimp.init/GimpUi.init/.
The Hungarian language file for the Windows installer was recently moved
from unofficial to the officially supported languages. However, a new
release including Hungarian by default is not available yet. This causes
our CI to fail because it can't find Hungarian in unofficial.
We change our ci script to download Hungarian from the correct location
for official languages, and adapt gimp3264.iss to reflect the correct
location.
According to the specs the extra mask (which they call real user supplied
layer mask) is used "when both a user mask and a vector mask are present".
I haven't seen an example that has the extra mask, so not sure which of
the masks would appear first.
For now assuming that the extra mask will be first. The advantage of
adding this here now, is that we won't try to add a mask channel as a
normal channel.
Uses the simulation rendering intent from GimpImage instead of
from GimpColorConfig. This affects the SamplePoint and Pointer dialogues
as well as the Color Info Window.
Adds a dropdown for Simulation Profile, Intent, and BPC
to the Create a New Image dialog.
This allows users to assign a soft-proofing profile when the image is
first created. It defaults to "None", however. Users can also set the
default simulation rendering intent and BPC status per image.
These options are also removed from the Preferences dialog.
Adds a simulation_bpc and simulation_intent to GimpImage to allow
plug-ins to access it
for CMYK import/export.
Four pdb functions were added to enable this access:
image_get_simulation_bpc (), image_set_simulation_bpc (),
image_get_simulation_intent (), and image_set_simulation_intent ().
Next, it updates menu options and code to support GimpImage's
internal simulation intent and bpc.
New 'simulation-intent-changed' and 'simulation-bpc-changed signal
are emitted via
GimpColorManagedInterface so that relevant tools
(such as the
CYMK color picker, GimpColorFrame, and future pop-overs)
are aware of these changes.
If we want to encourage meson usage in GIMP 2.99.12 as a test run, our
INSTALL file should target meson commands and options.
Also I took the opportunity fix a bit some parts which were outdated.
If we want to encourage packagers to test the meson tarball (better to
do this now with development releases than later on stable releases!),
we should name it prominently. Therefore I will rename the autotools
tarball as gimp-*-autotools.tar.bz2 whereas the meson tarball will be
named gimp-*.tar.xz.
Also renaming `sources` CI job to `sources-autotools`.
When zooming using scroll events it is possible to zoom out of gradient
bounds because the check for out of bounds zoom happens with the zoom
value before the delta is applied. The correct way is to limit the zoom
value after the delta is applied.
Zoom focus centers the point that we're zooming into at the location of
the mouse pointer.
Default zoom focus value is 0.5 which results in previous behavior.
Smooth scrolling requires that we keep the scroll (or zoom, as is in
this case) state as a floating-point number. The scroll deltas are often
less than one, thus storing scroll state as an integer will effectively
ignore most of the scroll events.
Apparently some layers in PSD files can have extra channels which we
did not account for when computing destination offsets, causing crashes.
So let's make sure we don't include the "extra" channels when computing
the offsets by introducing base_channels. We also move the alpha channel
in the spot of the first extra channel (even though it seems, based on
the one example we have, that the extra channel might be the same as
the alpha channel).
Commit a6aba929 deleted the old functions.
Misc drive-by fixes for gtk_adjustment step not < pages
Issue #8155 discusses alternative fixes, convenience functions for compatibility in ScriptFu.
There is one compat function defined already in ScriptFu, temporarily: gimp-image-get-active-drawable
which was written so that testing clothify-v3.scm could proceed.
* gimp-zip.in was apparently a very old script to package GIMP for
Windows into zip files. It has not been updated since 2007 and these
days, we package GIMP as an installer for Windows. I guess the need of
having just a compressed folder to move might be wanted for some, but
anyway this script is so old, it's probably completely broken now. It
would be much simpler to redo such a process from scratch (we have
very close jobs in the CI which could be better bases to work from).
* config.h.win32 seems to be an old manually-maintained config.h and it
has a big "WARNING! OUTDATED!" text at the top (also untouched since
2007). I guess it might have been used some time long ago. But these
days, we don't need a specific Windows-only config.h. The generated
one works fine.
`meson dist` don't imply a reconfigure or a rebuild which is actually
not great as it means a wrong order of commands may create tarballs with
outdated data (typically: build, then pull new code, then dist).
Of course for our official tarballs, it should be fine as we don't
generate tarballs manually anymore, but through the CI. Yet, just to be
on the safe side, force-trigger a reconfigure then a build (which would
likely be very fast anyway in the common use case where we just did a
build right before).
Additionally the INSTALL.in file is not copied anymore in the tarball
and INSTALL will only be generated in git repositories.
Resolves #8382
Also v2 scripts infer and set sensitivity to drawables
Add two test plugins clothify-v3.scm and test-sphere-v3.scm.
Temporary, to be removed when 3.0 ships.
Some refactoring (extracting methods, moving functions to new files).
Some drive-by fixes to script-fu-arg.c revealed by using GimpProcedureDialog.
Adds a soft-proof toggle button to GimpStatusBar. It's only active when
a simulation profile is set on the current image. It stays in sync with
the View menu soft-proofing option as well.
The `ninja dist` step fails with:
> ERROR: Repository has uncommitted changes that will not be included in the dist tarball
> Use --allow-dirty to ignore the warning and proceed anyway
> FAILED: meson-dist
> /usr/bin/meson dist
Astonishingly if I run a `git diff` (or git status) in the CI, I saw no
changes and the dist suddenly succeeded. When I remove it, it fails
again. And of course, locally it's alright. No way to diagnose!
Anyway it's not a bad idea to leave some diagnostic logs in the CI so
here we go, properly outputting the diff and exiting the job with an
error when there is a diff. Because anyway, there should be none. It
would mean that there is likely some issue in versionned generated
files.
Ironically, it is a test for the Windows platform but it cannot run on
Windows. First, because it expects a .so (which could be easily fixed),
but even more because from web search, it looks like the nm tool may not
exist on Windows (though I haven't checked).
Anyway we only ever ran it from Linux machines and up to now, it worked
just fine and was useful anyway. So let's go with it.
Also clean a bit remnants from older attempts to run this script.
Maybe let's try to distribute the meson tarball next to the autotools
tarball for our next dev release, and announce that packagers are
invited to test the meson build from tarball and report back.
Generated *enums.c now have an additional stamp no-op header include
(see last 2 commits). Sync this change into the autotools generation
scripts to prevent back and forth useless generation of these files each
time we switch from one build system to another.
They are nearly the same as initially, except that now they include an
intermediate stamp header which will be generated by the build system.
The only 2 enums which don't need these includes (and are not versioned)
are libgimp/gimpenums.c and libgimpthumb/gimpthumb-enums.c.
Our meson build system was not properly building the enums.c file,
because they are versionned.
I did a similar trick as what I did for the pdbgen, which is that I used
a wrapper script around the existing perl script, which sets proper
options and generate a stamp file in the end (which is considered by
meson as the actual custom target, not the C file since it is generated
in the source dir).
The most important part is that the stamp file is a generated header
source (not just a random text file) which is **included** by the
generated C file. This is what will force meson to regenerate the C file
if the header is updated, **then** build using this new version, not use
an outdated versionned version (which would make for hard to diagnose
bugs), through the indirection of the intermediate stamp header.
See #4201.
See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
Displaying it all the time when we fail the first attempt is confusing
as it is expected to fail in the meson build (since build libraries are
in different folders). Instead only output the error message when both
known paths failed, i.e. when we fail the script (and write down both
attempted path in the error message).
This explains why the defcheck script never complained for the 2
*_get_resource() functions removed in my previous commit. These were
exported in the libgimpwidgets library on the autotools build (and not
on the meson build).
Fix the discrepancy by not exporting these symbols on autotools as well,
as I don't think this is needed on public API.
This should now fix the distcheck build for autotools.
The defcheck.py file finds these errors:
> Problem found in /home/jehan/dev/src/gimp/libgimpwidgets/gimpwidgets.def
> the following symbols are listed in the .def-file,
> but are not exported by the library.
> - gimp_color_picker_cursors_get_resource
> - gimp_icon_pixbufs_get_resource
Indeed these don't exist. Unsure why the autootols check failed to
report these until today.
The check script now takes into account both the autotools and meson
file hierarchy (in autotools, built libs are in .libs/ subdirs).
Also it now properly fails on missing lib.
Adds a parasite to .xcf that stores the soft-proofing profile.
Existing color profile saving/loading functions now take in a
parasite name parameter so they can be used for either profile.
Some of our calls to run_command() would have failed with future
versions of meson if we didn't set the "check" parameter. In particular,
in various calls, we don't want to fail the whole build configuration
when the command does (as it's an optional feature check). In such a
case, it is important to be explicit as future will default to fail
then.
Fixes:
> WARNING: You should add the boolean check kwarg to the run_command call.
> It currently defaults to false,
> but it will default to true in future releases of meson.
> See also: https://github.com/mesonbuild/meson/issues/9300
Meson is apparently able to show different warning depending on the
meson version tests we do in specific code paths.
Since our global required meson is 0.53.0 but on some code paths, we
test for 0.57.0, we must use meson.source_root() on older meson and
meson.project_source_root() on newer one.
Fixes:
> pdb/meson.build:141: WARNING: Project targets '>=0.57.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
> pdb/meson.build:141: WARNING: Project targets '>=0.57.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
> po-tips/meson.build:5: WARNING: Project targets '>=0.53.0' but uses feature introduced in '0.56.0': meson.project_source_root.
The language files provided by the InnoSetup project (either the main
ones or the "Unofficial" ones, i.e. less maintained ones) at least
provides the name of the language, possibly in English, ideally
self-localized in its own language.
Unfortunately Kabyle didn't have any language file so we were using the
Default one, which ended up showing the lang as a duplicate (and very
wrong) "English".
With this commit, I add code to provide our own very basic base language
file, which would at least contain the language name. There is also a
concept of language ID to be verified in Windows-provided list.
Unfortunately it doesn't have any (actually it was id-ed 0x1000 like
many other languages, which looked therefore to be the code for an
unsupported lang). InnoSetup docs tells us to leave 0 then. We can add
the ability to set a specific code later in the template if we add other
un-provided languages and if they have their own lang id.
With this base infrastructure, we should be able to better support more
languages.
Unfortunately the weird encoding of a string to bytes to get the UTF-8
BOM worked on my local machine, but not on the Windows CI. I'm not going
to fight it and fallback to a shell script.
I am guessing it should work fine on all platform since we use basically
the same sed call in build/windows/gitlab-ci/installer-gimp-msys2.sh
already.
Inno-Setup absolutely requires it to recognize UTF-8 translation files.
This should hopefully be the final fix to #8338.
Note that this fix is full of workaround for meson bugs or limitations.
While it was a one-liner in autotools, added to the existing rule, here
I have to add an additional (non-relevant) target rule, then uglily work
around 2 bugs:
https://github.com/mesonbuild/meson/issues/1564https://github.com/mesonbuild/meson/issues/7696
I can't say I'm so happy about the resulting change, even though it
seems to work. If anyone can propose a nicer build rule, it would be
welcome.
Whenever we have an element without translation, we try to use the value
without a `xml:lang` attribute. That selector was wrong though, which
leads to https://gitlab.gnome.org/GNOME/gimp/-/issues/8338, which should
now be fixed.
These were originally to distribute cross-built binaries. Nowadays, we
just use the native-made installer, which is also closer to what people
will really get for release versions.
So let's just remove these. I keep the crossroad builds as these are
still useful to detect Windows build bugs quickly, but we don't need
these distribution steps.
This also takes care of failures in the job, but since it's mostly a
useless job nowadays, rather than wasting my time investigating this, I
simplify the CI.
The gnome-runtime-images have been recently migrated to Quay. This is already reflected in the template.
Please note this MR has been created semi-automatically. If it doesn't make sense, feel free to close it.
Similar to the previous commit, use the new
gimp_tools_show_tool_options() before blinking various tool options
widgets since these are good hints for wrongly set options and it's nice
to be able to point at these.
Create a new utils function gimp_tools_show_tool_options() because
showing the tool options is likely a common action. And use this when we
want to blink the selection mode box, for this particular case.
Note that I could not reproduce the CRITICAL here (i.e. even if the
dockable was not showing, it seems the widget did already exist anyway).
Anyway it's a nice idea to raise the tool options as the goal is to
explicitly show how to fix the issue here. And it should fix the bug for
people encountering it.
These changes make it possible to build against homebrew for mac
libraries. Homebrew stores it's libraries in seperate folders and so
blanket includes were not working.
PYTHONPATH is not needed and interferes with homebrew build.
Fixing !646. The call to gimp_image_set_simulation_profile() was only
happening for merged PSD mode (either explicit call or when
special-cases such as no layers).
This is the right place to store the CMYK profile in all cases.
Removes gimp_color_transform_process_pixels () calls
when a CMYK profile is present, and uses babl_format_with_space ()
instead for all cases. Additionally, possible errors are now recorded
during the conversion process.
If attached, the image's CMYK profile is stored in GimpImage
afterwards.
As noted by @Ofnuts, histogram-export still expected to receive
a single layer from GIMP. The parameters have been updated to
reflect receiving multiple layers/drawables, and the active layer
is selected. The parameter was left in case multi-layer support
is added in the future.
CMYK profile is now stored in GimpImage on load
(rather than being discarded) and it's used for export rather than
the default simulation profile stored in Preferences
libxml has a XML_PARSE_HUGE parsing option, which can be turned on with
the RSVG_HANDLE_FLAG_UNLIMITED option in librsvg.
We cannot just set this option by default because it is a security
hazard as a maliciously malformed SVG could use this to consume too much
memory.
Instead, let's just propose the option interactively when we fail to
create a rsvg handle. Unfortunately right now we can't single out this
specific error because librsvg actually returns an unrelated (false
positive created by the huge data) error. So we just propose the option
for any kind of handle creation failure.
Furthermore, the option is only available on interactive plug-in calls
so far. In particular, the PDB API doesn't have an option allowing a
script writer to run "file-svg-load" with the huge data option.
As for the thumbnail API, it is never meant to be used interactively and
not really as a common script function, so it won't have the huge data
option either.
gimp_color_config_get_simulation_color_profile() is returning a new
object, so we had 2 code paths giving either allocated data or not.
Therefore simply ref the passed softproof profile in the second code
path, and don't ref it anymore when caching it (especially as it might
also be NULL at that point).
Now that images can contain their simulation profile,
we can use gimp_image_set_simulation_profile() to retain
the CMYK profile when a TIFF image is loaded.
It will then be accessible in GIMP's Image menu.
Adds support for saving 8 and 16 BIT CMYK/A TIFF files using the
image's simulation profile. If no profile or a non-CMYK profile
is set for the simulation profile, naive conversion is used instead.
The Makefile.am was apparently updated by hand in !662.
Also fixing plug-in label and doc localization, since this changed
recently and must now be localized directly on plug-in side.
langinfo.h is not on all systems apparently and/or the locale item we
test for may not be available everywhere. Actually even on Linux, after
testing more deeply, I could create cases where nl_langinfo() would not
return a result (if the locale is broken through environment variable
for instance). setlocale() seems to always return usable value so far,
so I fallback on it. As a last resort, I look at environment variables
(even though these may contain invalid contents.
As for Windows and macOS, I try to use more platform-specific methods.
In macOS in particular, as I understood from reports, GIMP follows
correctly the language preference order, which means we should not look
at a single (top) lang, but at the whole list of prefered languages as a
single settings to determine whether the language was changed or not.
Should fix on Windows:
> fatal error: langinfo.h: No such file or directory
and on macOS:
> error: use of undeclared identifier '_NL_IDENTIFICATION_LANGUAGE'
These files seem to have appear ever since the recent gettext changes in
commit f663d26ab5.
In particular, the call to autoreconf seems to be creating these.
This reverts commit 82f9ae1ab7.
This is not needed anymore. Cf. previous commit which implements the
force-requery differently and much more widely based on actual language
being stored and compared between runs.
Since localization is fully handled plug-in side now (see #8124), we
need to make sure the query functions are run again for all plug-ins
when the UI language changes (otherwise we might end up with
localizations from the previously used languages).
We were already reloading plug-ins when explicitly changing the lang in
the Preferences, but this new implementation is much better as it's
generic. In particular, it will also handle the case when the system
language changes (or when you play with locale environment variables).
This removes rate limiting of ruler and statusbar updates which were
required to get acceptable performance on mac for drawing on the canvas.
This requires the latest changes on in Gtk 3.24 to be incorporated.
Continuing the changes in #8124, let's have properties labels and blurbs
both localized on plug-in code, i.e. with gettext calls directly in
GIMP_PROC_ARG_*() calls.
Note that it was already the case for blurbs (longer description,
tooltip) as I couldn't find code where we'd localize it further down the
line. But we were running gettext on nicks (shorter description, label)
inside GimpProcedureDialog code. Let's not do this anymore.
This will make the whole localization much more clear and obvious. There
is no "later localized" case anymore. Now let's localize everything
directly when the arguments are created.
This is the consequence of previous commit. Plug-ins' label and
documentation are now localized before sending these data to GIMP core.
In other words, we replace N_() macros with basic gettext calls.
Plug-in localization was always partially plug-in side, especially for
things like custom GUI. But labels or blurb in GIMP (such as in menus or
action search) were localizing GIMP side.
It had many drawbacks:
- To get menu localization, a plug-in had to set up gettext, even though
they might want to use something else for their GUI (after all, giving
facilities for gettext is a good idea, but there is no reason to force
using this system).
- There was a complex internal system passing the localization domain
name, as well as the catalog file system path to core, then through
various classes which we can now get rid of.
- There could be domain name clashes, if 2 plug-ins were to use the same
i18n domain name. This was handled in now removed functions
gimp_plug_in_manager_get_locale_domains() by simply keeping a unique
one (and gimp_plug_in_manager_bind_text_domains() would just bind the
domain to the kept directory). In other words, one of the duplicate
plug-ins would use the wrong catalog. We could try to make the whole
thing more complicated or try to forbid plug-ins to use any random
name (in particular made easier with the new extension wrapper). But
anyway this whole issue doesn't happen anymore if localization is
fully made plug-in side, so why bother?
I tried to evaluate the advantages of the core-side localization of
plug-in labels/blurbs and could only find one theoretical: if we wanted
to keep access to the original English text. This could be useful
(theoretically) if we wanted to search (e.g. in the action search) in
both localized and English text; or if we wanted to be able to swap
easily en/l10n text in a UI without reload. But even if we were to ever
do this, it would only be possible for plug-ins (GEGL operations in
particular are localized GEGL-side), so it lacks consistency. And it's
unsure why special-casing English should really make sense for other
language natives who want text in their lang, and search in their lang.
They don't necessarily care about original.
So in the end, I decided to simplify the whole thing, make localization
of plug-ins a plug-in side thing. Core will only receive translated text
and that's it. It cuts a lot of code out of the core, simplify runtime
processing and make plug-in creation simpler to understand.
The only think I still want to look at is how exactly menu paths are
translated right now. Note that it still works, but it's possible that
some things may be worth improving/simplifying on this side too.
Why: puts most methods for SFArg (a struct) in one place, for ease of maintenance.
Prepares to fix issue 8328. Prepares to make SF use GimpProcedureDialog.
Mostly moving code, with no intended change in functionality,
except fixed an property.nick for an arg is now what a script author provided,
instead of generated.
All internal to libscriptfu. No changes to the exported API or to i18n.
Lightly tested, since more substantive changes coming for issue 8328.
ScriptFu>Test>Sphere is the test case.
g_warning() (as well as g_critical() and g_return_*()) are reserved for
core code bugs, and therefore triggers a debug dialog with a backtrace
to report.
Here I encountered such duplicate because ts-helloworld.scm was moved
around from scripts/ to plug-ins/ since commit d5a83429b4 and I hadn't
done a clean uninstall (so of course someone with package installation
should not have such a debug dialog). Yet it could actually happen for
various reasons, such as third-party plug-ins actually registering
identically named actions. Such reasons are not core code bugs and we
don't want to trigger a debug dialog (and have people report bugs to us
which are not actual bugs and which we have no power to fix) each time a
plug-in developer uses a too generic action name.
So instead let's just print to stderr for now. I also add the
information on which plug-in was discarded (otherwise if you actually
have 2 different plug-ins doing different things, you wouldn't know
which one is the visible one and which one can't be called).
Note that I hesitated with a g_message() which would pop-up a
user-facing error and would help them better handle their plug-in
conflict. But I'm not sure it's ideal in current state of things either.
It might be much better handled when we will have moved to recommending
extensions wrapping plug-ins.
Adds a simulation_profile to GimpImage to allow plug-ins to access it
for CMYK import/export.
Two pdb functions were added to enable this access:
image_get_simulation_profile () and image_set_simulation_profile()
Next, it updates menu options and code to support GimpImage's
internal simulation profile. Menu items are moved from View to Image's
Color Management section.
New 'simulation-profile-changed' signal is emitted via
GimpColorManagedInterface so that relevant tools (such as the
CYMK color picker, GimpColorFrame, and future dockable
dialogue) are aware of these changes.
Why:
1) users can install .scm scripts to plug-ins dir
2) Crashing scripts do not crash extension-script-fu
Scripts (.scm files) have a shebang and are executable
and in a same-named subdir of plugin dir.
Interpreter/scripts create PDB procs of type PLUGIN unlike extension-script-fu
which creates PDB procs of type TEMPORARY, owned by extension-script-fu.
Unlike other interpreters, the interpreter is-a plugin outright,
not by virtue of the script subclassing GimpPlugin and using GI.
More details in /plug-ins/script-fu/interpreter/README
The get() API are sometimes nicer in C code because it's just simpler to
loop through C arrays, but they end up with similar API to the list()
variants for binding, or with a useless size return value (since most
higher level languages have length-aware array types, which is what
GList are transformed into).
So let's use the list() variants as the main ones and skip the get()
variants. I hesitated to rename the list() variants to get() with
`(rename-to)` annotations but since I am unsure if the get() bindings
are absolutely useless, I don't think it's the best idea. Maybe on some
other language usable as GI binding, the get() variant might be
different again and nicer to use. So if we shadowed these by renaming
list() ones, the day we change our mind, we'd have to rename get() ones
too (which would be very confusing), or else break bindings' API. To
avoid this, I just skip the get() ones altogether in bindings but leave
their name available in the bindings.
(1) On recent meson versions, it fixes this error:
> extensions/goat-exercises/meson.build:108:0: ERROR: i18n.merge_file keyword argument 'output' was of type array[str] but should have been str
As docs explains, 'output' only accepts one item in i18n.merge_file().
This bug also happens on older meson (but there the reported error is a
lot less useful as it doesn't mention local meson build code).
(2) `setup.isl.xml` is a temporary intermediary file used to create the
Windows installer. It must not be installed.
(3) `gimp30-windows-installer.mo` itself is only used to create
`setup.isl.xml`. It must not be installed as well.
(4) gimp-tips.(its|loc) files (same for gimp-tags ones) should not be
installed. They are only temporary data.
(5) Fix environment variable: s/GETTEXT_DATA_DIRS/GETTEXTDATADIRS/
Fixes:
> /usr/bin/msgfmt: cannot locate ITS rules for ../../../data/tips/gimp-tips.xml.in
(6) Fix various bugs in the *.setup.isl files creation in autotools
build (typo, wrong files used, order of options in `xsltproc`
apparently meaningful, and so on. I guess the autotools build was
not as well tested as the meson one :P).
(7) Fixing the unit test verifying language lists consistency.
(8) `setup.isl.xml.in` must be added to the distribution.
intltool has long been dead upstream. Let's not poke the dead corpse,
please.
This commit is quite large, but that's mostly since trying to support a
hybrid of both gettext and intltool with both Meson and Autotools was
really hard, so I stopped trying.
Due to gettext relying on quite some things being at the exactly right
place in the autotools build (like `ABOUT-NLS` and `config.rpath`) we
really needed to cleanup the `autogen.sh` to only call `aclocal` and
`autoreconf`. No more strange magic; I tried to do it without changing
too much in the file, and things just broke. If people want to do
something more custom, they can just change the script directly. This
change also uncovered some problems in our `configure.ac`, like using
deprecated macros.
The following major changes happened:
* meson: Changed `custom_target()` to `i18n.merge_file()` for all
supported file types
* Added `.its` and `.loc` files for the GIMP-specific XML formats, so
that gettext understands them
* For the `.isl` (Window installer stuff) file, there's no easy way to
do this in gettext, so instead we start from an XML file (again with
its own ITS rules etc), translate that with gettext, and then use
`xsltproc` with a bit of magic to output the .isl file for each
language
* the `po*/Makefile.in.in` files are migrated to `Makevars` files,
which gettext natively understands.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/8028
Instead of having a single "Planar RGB" format in the list, let's add
this as a generic parameter. Not only does it make the feature
symmetrical to "file-raw-save", but it also bring the ability to all
multi-channel formats. So now, we can load RGB, RGBA, GRAYA, whatever
the bit depth and the data type stored in planar configuration.
… "endianness".
The list of formats being a single list was actually interesting
UI-wise, in the case where you aren't sure of the data layout (but say
you know at least the dimensions), you can easily and quickly scroll
through the combo list (e.g. with keyboard arrows).
But when you knew your data, it was a pain to use. And as a general
rule, so many choices in a list is not the best interface.
I broke the option into 3 options, and in particular adding a
"data-type" which would tell what type of values are stored (integer,
signed or unsigned, or float) and an "endianness" to tell the byte
order. The idea behind is that these don't change the layout of
components and their size. It means that we can still do the
scrolling-randomly-through-formats trick in some fashion because we
might likely be able to detect shapes when we get at the right layout,
even though we are still set to use the wrong data type and/or the wrong
endianness.
… loading support as raw data.
Barely any new code (and actually a bit chunk of removed code) as we are
using generic code paths now.
"file-raw-load" procedure now supports all possible formats which can be
exported by the "file-raw-save" procedure (and more).
Only thing remaining now is looking how to simplify the GUI because this
overlong Pixel format combo box is quite a pain.
The "revision" field in the json file is supposed to be int. But I just
realized that it was set as string a few times, e.g. in Windows
installer revision 1 of GIMP 2.10.32. As a consequence, the revision 0
build was not able to detect the new revision.
I have now fixed the data in gimp-web repo (commit e7690e36), yet just
in case this ever happens again, I make the parsing code more robust by
accepting string revision, then properly converted to int.
Since we can now export these, let's add import support.
I copied the function halfp2singles() from babl code (as-is, without
formatting according to our coding style on purpose as we might just
want to switch this again later on).
I add the Little and Big Endian variants, but not the signed one for
now, because I am unsure how common it is. We have signed grayscale
variants, but it might be specific use cases there.
While adding these new loading support, I factorize the code when
possible by making all full-bytes RGB/Grayscale code more generic and
using the same code paths. In particular, raw_load_gray_8_plus() is now
removed as raw_load_standard() will handle all full-bytes use cases
where the input and output formats have the same components in same
order.
Also RAW_RGB and RAW_RGBA are renamed to RAW_RGB_8BPP and RAW_RGBA_8BPP
respectively.
We regularly have package issues which are discovered soon after
release. Let's try a new step in the release process where we would
build packages in advance just for testing.
- rename raw_load_gray16() into raw_load_gray_8_plus() and make it
handle all full-byte grayscale data. Move 8-bit grayscale data to use
this function as well.
- As a consequence of the previous point, we can also easily support
32-bit grayscale images (little/big endian, signed/unsigned).
- Make preview image code more generic as well.
Also I improve a bit code from previous commit in raw_load_rgb565(). The
allocated and read code didn't need to be the size of the full line
stride. Just the tile rectangle width was enough.
Rather than allocating 2 huge data buffers of the whole image size (one
in RGB565 and one in RGB-u8), just iterate through the file only
creating one single small temporary data buffer for single input line in
tiles returned by the iterator. This will be much better,
memory-efficiency wise.
Create new plugin file script-fu-server-plugin.c
with code extracted from script-fu.c, which is an omnibus plugin
implementing PDB proc extension-script-fu and other PDB procs.
Why:
1. extension-script-fu is smaller and doesn't doesn't link to socket libraries.
(GIMP always starts extension-script-fu and it stays running.)
2. packagers/admins can omit script-fu-server executable from an installation,
if they think letting users serve net ports is not secure.
3. crashing script-fu-server does not crash extension-script-fu,
which requires restart of GIMP
The changes are mostly a simple refactor, extracting code.
No functional change apparent to users.
Low risk of introduced bugs.
Extremely few users use script-fu-server anyway.
Added some logging.
While at it, use G_DECLARE_FINAL_TYPE
Should have paid more attention. I left 2 warnings in the file:
> plug-ins/common/file-raw-data.c:1949:22: warning: variable ‘procedure’ set but not used [-Wunused-but-set-variable]
> plug-ins/common/file-raw-data.c:1970:48: warning: ‘bpp’ may be used uninitialized in this function [-Wmaybe-uninitialized]
Even though the scale entries have maximum values based on the file
size, it's still too big for many formats (multi-byte ones) when
thinking in terms of pixels.
Moreover if growing the offset or any dimension, comes a point where the
other dimension needs to shrink. So let's compute max pixels and update
other values depending on this.
Note that it's still quite easy to crash the dialog with big dimensions,
triggering X Window System errors about unsufficient resources in
GimpPreviewArea code. This will have to be handled accordingly.
… GimpIntStore for value filling.
GimpIntComboBox was not taking ownership of the value store whereas the
newer GimpIntRadioFrame was taking ownership. As a more common practice,
I decided to leave ownership to the caller (which will therefore have
the responsibility to free the data) in the main class and property
widget APIs.
On the other hand, let's steal ownership of the store objects in the
gimp_procedure_dialog_get_int_*() functions as these are really used for
very quick and easy creation of dialogs by script writers. It would even
allow to create a GimpIntStore inline within the widget creation
function, if one wanted to.
- Add various relevant arguments to "file-raw-load" PDB call: width,
height, offset, color-representation, palette-offset palette-type and
palette-file. This will make the procedure actually usable for
scripts.
- Use procedure config so that we get configuration storage as all other
ported plug-ins.
- Update the source to use passed-in config object with these new
arguments rather than global variables.
- The load dialog now uses the GimpProcedureDialog which means a lot
simpler and nicer to read/debug code (we don't need all the code for
argument syncing).
- "file-hgt-load" code now uses a HgtSampleSpacing enum, which makes
code nicer to read, with semantic constant names.
- Do not show the dialog anymore for HGT load when sample spacing
detection worked correctly. Indeed, offset and profile selection were
making sense for random raw data, not for HGT file which we know how
to process.
- Improve detection logic for sample spacing: in interactive mode, we
always try and detect and show the dialog when spacing detection
failed; in non-interactive mode, we only detect when "sample-spacing"
argument is explicitly set to HGT_SRTM_AUTO_DETECT.
- The argument "image-type" of "file-raw-save" PDB call is renamed to
"planar-configuration" to sync with the natural language label. Also
it now uses a separate RawPlanarConfiguration enum rather than using
specific values of the RawType enum (which made that the possible
values were 0 or 6, which was a weird API in GIMP 2.10).
The plug-in still cannot load all possibly exportable formats (after
commit 01e0675f67) and I'm still wondering about whether
"color-representation" argument in the load call should not be broken
down into several arguments (it has both advantages and disadvantages).
This will be handled in further commits. For this first step, I needed
to clean the load code.
… GimpProcedureDialog.
- gimp_prop_file_chooser_button_new() now works also with properties
G_PARAM_SPEC_OBJECT having a value_type == G_TYPE_FILE (additionally
to GIMP_PARAM_SPEC_CONFIG_PATH properties).
- gimp_procedure_dialog_get_widget() will now create a
GtkFileChooserButton in open mode for such a GFile property.
- New gimp_procedure_dialog_get_file_chooser() API to create
GtkFileChooserButton for GFile properties in other modes.
Current limitation: GtkFileChooserButton doesn't have a label. This
should be fixed, probably by creating another custom widget with would
be a labelized file chooser button.
Another part for the fix: now that it is possible to export any of the
color model and bit depth supported by GIMP core, we should make the
dialog settings clearer. In particular, don't just always show "RGB"
structure sample.
If an alpha channel is present, also show RGBA samples, and if it's a
grayscale image, show "Y" or "YA" samples. Actually when it's a
non-alpha grayscale, just make the option insensitive as planar and
contiguous will be the same thing.
Only port the export dialog so far. We'll see later for the load dialog.
This uses the new gimp_procedure_dialog_get_int_radio().
While doing this, I also better name "Image type" to "Planar
configuration", which is how DICOM standard and TIFF call the same
option. Within this settings, "Standard" is renamed "Contiguous" as a
more correct naming than a very vague "standard".
Similarly I rename "Palette type" to "Palette's configuration".
This is a first step to make RAW export clearer in the path of fixing
issue #7091.
A proper class for a frame containing radio buttons. This object has a
"value" property and will therefore be very easy to use in various API
binding a config property to a widget property.
A GimpIntRadioFrame is also what gimp_prop_int_radio_frame_new() will
return now.
gimp_prop_int_radio_box_new() on the other hand is being removed. It is
used nowhere and is unneeded. If someone really needs a non-labelled
group of radio buttons, they can also create a GimpIntRadioFrame, remove
the label and hide the borders. At least they will still be able to
easily bind it to a config property.
Changes are mostly to the dir structures and build system for ScriptFu.
Some changes to the outer plugin source to call the library.
Why: so that other executables (future gimp-scheme-interpreter,
or a future separated script-fu-server) can exist in separate directories,
and share the library in memory (when built shared.)
Whether the library is built shared and installed on its own
(versus static and not installed)
is a compile time option (both automake LibTool and meson abstract it away)
The default is shared and installed, say as libgimp-scriptfu-3.0.so.
Installed alongside other shared libraries (e.g. wherever libgimp is installed)
to simplify packaging.
A preliminary refactoring which helps enable MR gimp!647
See issue #1307.
There doesn't seem to be anything blocking us to publish to the
Microsoft Store, now that there is this new "traditional desktop
application" process allowing us to publish using our existing
installer. So GIMP 2.10.32 should normally be our first published
version there.
I forgot this one, which simply can have its localization disabled. As I
understand, it's mostly for script writer so was never localized. Maybe
it could still be interesting to localize the procedure name and docs,
but for now let's leave it how it always was.
We only set tiff_mode for images with bps < 8, but we also use it for
8 bps grayscale images to detect if MINISWHITE needs to be converted.
So, let's always set tiff_mode for PALETTE, MINISBLACK and MINISWHITE.
generated by matlabs blocproc function
Based on the suggested solution by Massimo, we should not compute the
remaining pixels per line but only at the end of the whole block, be it
tile or scanline.
I have not been able to find bw or palette examples that use load_separate
instead of load_contiguous, so that case is not tested. But, it also
doesn't make much sense to have planar when you have just one plane.
In a previous commit 1, 2 and 4-bit B/W images were converted to grayscale.
However, it seems that there is more of a use case for these images to be
handled as indexed, even though technically they can be considered
grayscale.
Also, the only way to export these images again in the same format, is to
have them as indexed.
So, let's change this back, so that these kind of images will be opened
as indexed. With a reminder that in the future we could add an option
at loading time where the user can choose whether they prefer it to be
loaded as indexed or grayscale.
We use grayscale mappings, that we moved in the previous commit, to
add a palette to these grayscale images.
In preparation of using some of them earlier, we move the variables
used for grayscale mapping of 1, 2 and 4-bit per pixel images to the
top of file-tiff-load.
The '\n' newline is transformed into a space (0x20) when building
natively on Windows. And unfortunately g_key_file_load_from_file() does
not like this.
The autotools rule works properly on all platforms according to my
tests.
Note that at first, I thought it was a LF vs. CRLF issue, and tried to
special-case Windows, but I realized it's just that 'echo' command
seemingly transform newlines unexpectedly in its Windows form. I didn't
want to waste too much time experimenting alternative calls, especially
as I have to test through CI (so each test is very costly, time-wise).
Instead I go the alternative way of using a pre-generated conf file.
This will allow to use the official Windows installer directly in the
Windows Store, as per the new proposed workflow by Microsoft.
Nevertheless our GIMP for Windows has a built-in update check which
would check if a new version exist and warn people (advising them to go
on the website and download the new installer to update). We obviously
don't want this on the Windows Store which has its own update channel.
It would be confusing.
Therefore I added a feature to disable the built-in update check (not
even showing in Preferences) by tweaking a single package variable. The
installer now comes with new option /DISABLECHECKUPDATE=true which will
add said variable.
The urlmap file allows gi-docgen to generate links for namespaces that
are also generated by gi-docgen. For example, with this commit, a
reference to `GObject` will now be properly linked to the GObject
documentation.
GIMP was saving the last changed/saved date to IPTC tag DateCreated,
which should only be used for the original creating date of the image
and thus should not be changed by GIMP.
After discussion in the cited issue, there is no tag in IPTC that we can
use, so we remove saving modified date from the IPTC metadata.
Instead we add two XMP tags, one for modified date and the other for the
date that metadata was changed. Since we do both when exporting, both are
saved with the same date/time in ISO 8601 format.
This also fixes another issue where we were not storing the timezone offset
for Xmp.tiff.DateTime. Since this has the same format as the other
XMP tags, we fix this together with this issue.
… in the gimp-release file.
This will be useful to disable the update check for the Windows Store
even though we use the same build as the installer. All it will take
will be to append the line `check-update=false` to the file
`share/gimp/2.10/gimp-release` and it will behave as though the update
check is disabled (even though it is actually built-in).
More safety checks for detecting broken xcf files, also based on examining
issue #8230.
After reading an offset where layer, channel, etc. data is stored, we
add a check to make sure that offset is not before where we read the
offset value. Because the data is always written after the offset that
points to it.
Improvements in loading broken xcf files, based on examining issue #8230.
Besides checking for a minimum width and height, GIMP also has a maximum
size we can and should check.
In the case of the image itself, we change invalid dimensions to a size of
1 in hope that the individual layers etc will have the correct size.
For layer, we will also try to go on, but for channel and layer mask, we
will give up.
gimp_channel_is_empty returns FALSE if channel is NULL. This causes
gimp_layer_invalidate_boundary to crash if the mask channel is NULL.
With a NULL channel gimp_channel_is_empty should return TRUE, just like
the similar gimp_image_is_empty does, because returning FALSE here
suggests we have a non empty channel.
I guess I missed this one as I was not building it locally.
Fixes:
> In file included from ../plug-ins/common/file-jp2-load.c:86:
> ../plug-ins/common/file-jp2-load.c: In function ‘jp2_class_init’:
> ../libgimp/stdplugins-intl.h:42:22: error: ‘set_i18n’ undeclared (first use in this function)
I hesitated a lot whether we should just drop the whole localization of
plug-ins' label and description (blurb) within the core. Actually the
commit messages I wrote a few days ago were moving towards this logic.
It really looks to me like plug-in localization can happen fully within
plug-in themselves. As far as I can see, the only advantage which the
current logic has theoretically is that if we needed, we have access to
both the original strings and their translations (e.g. it could be
useful for text search). Nevertheless I am not sure if we will ever make
use of this, and this is limited cases as all filters turned GEGL ops
don't have such ability anyway.
Nevertheless since previous contributors clearly put quite a lot of work
on this code of localizing the plug-in's label and description within
the main binary, I want to give myself a little more time to think and
study the whole thing because doing anything rash.
In the meantime, what changes is that by default now, a plug-in without
a local gettext catalog is simply not localized. In particular, the core
process doesn't try to localize it using the default catalog, a.k.a.
GETTEXT_PACKAGE"-std-plug-ins" ("gimp30-std-plug-ins"). It just doesn't
make sense and the worst which could happen would be to get unexpected
and wrong translations.
Now by default, plug-ins will try to find a catalog in their main
folder, named as this folder. If it fails to find it, a message is
printed to stderr and localization is disabled (rather than falling back
to a default catalog). It is up to plug-in developers to either install
a catalog, or implement set_i18n() to give the right catalog, folder, or
disable localization with gettext, as handled by libgimp.
gimp_procedure_set_static_help().
The indentation was wrong, probably because of changes to function
names. Fix the generation scripts and regenerate the PDB C files.
We changed the logic of _gimp_plug_in_domain_register() which is now
only called when a domain is explicitly registered (which is not the
case by default anymore). Let's update the function documentation and
also make it clear that third-party developers in particular should not
play with it if they want their plug-ins to be properly localized.
Since these are demos, for the sake of showing how the localization
works, let's localize the goat-exercises with a locally installed
catalog.
Note that actually use the gimp30-std-plug-ins catalog, simply I copy it
in the plug-in folder and rename it as org.gimp.extension.goat-exercises
domain.
As a consequence:
- The C plug-in does not need the INIT_I18N anymore, which was
specifically for the centrally installed catalog and cannot be used by
third-party plug-in developers (so it's not a good demo code).
- I now use GLib.dgettext() for Python instead of the gettext Python
module, because the later won't "catch" the catalog declared in
libgimp.
- The other Goat exercises are now localized correctly, unlike before.
- Just setting GETTEXT_PACKAGE is apparently enough for the Vala
plug-in.
- Lua is untested. Hopefully the code will work.
Hence avoiding the stderr messages. These are going to be localized with
centrally installed catalogs "gimp*-std-plugins", "gimp*-script-fu" and
"gimp*-python".
We now handle core plug-in localizations differently and in particular,
with kind of a reverse logic:
- We don't consider "gimp*-std-plugins" to be the default catalog
anymore. It made sense in the old world where we would consider the
core plug-ins to be the most important and numerous ones. But we want
to push a world where people are even more encouraged to develop their
own plug-ins. These won't use the standard catalog anymore (because
there are nearly no reasons that the strings are the same, it's only a
confusing logic). So let's explicitly set the standard catalogs with
DEFINE_STD_SET_I18N macro (which maps to a different catalog for
script-fu plug-ins).
- Doing something similar for Python plug-ins which have again their own
catalog.
- Getting rid of the INIT_I18N macro since now all the locale domain
binding is done automatically by libgimp when using the set_i18n()
method infrastructure.
Clearly the old logic for localizing plug-ins was "core plug-ins first":
* In particular, we were defaulting to the "gimp*-std-plugins" domain,
asking plug-ins to override it with libgimp function
gimp_plug_in_set_translation_domain(). Obviously any third-party
plug-in would have to call this function since their strings are most
likely not the same as GIMP core plug-ins.
* Moreover this was only for the localization of menu items, which means
we had to duplicate work anyway (simplified for core C plug-ins only
with the INIT_I18N macro).
* Also plug-ins had to manage the location of the Gettext catalogs,
which is simpler for core plug-ins with gimp_locale_directory(), but
more annoying for third-party plug-ins which can be installed
basically anywhere (assuming their message catalogs are in their
directory, not centrally installed on the system, especially for
non-UNIX-like packages, with relocatable GIMP, no central package
system and so on).
* Finally in this logic of centrally installed catalogs, we were
requesting that the domain name is unique, which makes sense in a
Linux world with well maintained packages to avoid name clashes, not
in a world with people making plug-ins without knowing too much what's
done by their neighbour.
So now the new logic is:
- By default, GIMP will search for a folder called locale/ on the same
level as the plug-in executable. The Gettext domain will be the name
of the executable folder (and it doesn't matter too much if it's not
unique in such configuration).
- This can be disabled by overriding set_i18n() to NULL or
reimplementing it. All our core plug-ins will do this since they will
continue to use the centrally installed "gimp*-std-plugins" domain (or
"gimp*-python" for Python plug-ins).
- When not disabled while the folder is not available, warning messages
will be outputted to stderr, so that plug-in developers can easily
detect what is missing and how to handle it (and how to easily support
internationalization of their plug-in).
- gimp_plug_in_set_translation_domain() is removed and a future commit
is going to get rid of _gimp_plug_in_domain_register() because we are
going to get rid of the core-side localization of menu items (with
logic explained in the upcoming commit).
- Set the "gimp30-python" Gettext domain and bind it to the proper
locale directory as installed by GIMP.
- Localize various strings with gettext.
- Remove calls to self.set_translation_domain() in
do_query_procedures(). This is technically wrong right now but I am
going to get rid of the menu item localization for plug-ins done by
the core.
We were using parameter iter in metadata_dialog_add_tag and
metadata_dialog_add_translated_tag.
However, iter is only ever set inside metadata_dialog_add_tag by calling
gtk_list_store_append. So, there is no need to pass this parameter around.
For this reason, let's remove parameter iter from the above two functions
and replace with a local variable.
In other cases we need to free value, but in this case it was used and
trying to free it caused a GIMP to crash.
Let's duplicate value, so we don't need to special case our g_free.
There was one case where horizontally and vertically were mixed up in a
call to gimp_display_shell_scale_image_stops_to_fit.
The more usual order of parameters is first horizontal and then vertical.
So, let's fix the actual functions that have the illogical order
of vertically, horizontally instead of fixing the one call.
This brings it in line with the order in other functions and makes it less
likely we mistakenly mess up the parameters.
Besides that gimp_display_shell_scale_image_stops_to_fit also was not
declared as a local function, so we add that too.
Also fixed quotient to only take two arguments. Applied minor
optimization in execution of quotient, remainder, and modulo.
From revision 122 of the TinyScheme repository in SourceForge.
Instead, make outer script-fu-server register callbacks with inner scheme-wrapper.
Why? the inner scheme-wrapper should not know about the outer script-fu-server.
The change will allow a future, smaller scriptfu shared library,
that does not contain networking code.
We want a scriptfu library shared by separate script-fu-server,
future gimp-scheme-interpreter (!647), and script-fu executables.
This change does not alter observable functioning of the script-fu-server.
Except that I also changing the logging by script-fu-server,
so that I could test the changes.
I put a test plan in the comments.
With large image sizes a 32-bit int is not enough for the intermediate
computations, which byte per pixel, width and height are.
So, just like the function below it does: gimp_gegl_pyramid_get_memsize,
we will cast these to gint64.
Thanks to Massimo Valentini for finding the cause.
I added this call originally, mimicking the C plug-ins. Yet in Python,
this function is deprecated since Python 3.8 and removed in 3.10.
Looking closer in the docs, it looks like Python's gettext module works
differently.
While all the *gettext() functions return strings in the locale's
encoding in C, unless overriden by bind_textdomain_codeset() (therefore
we need this call, in order to have locale-independent string encoding),
this is not the case in Python, whose gettext() call is already
locale-independent. The gettext.bind_textdomain_codeset() function only
applies to the specific l*gettext() functions which are deprecated too.
Fixes the warning:
> goat-exercise-py3.py:37: DeprecationWarning: bind_textdomain_codeset() is deprecated
Bugs introduced in commit 8eb7f6df9e:
- The type test was wrong.
- The UTF-8 validation test was also wrong since it was still working on
a GimpArray even though the data was now a GStrv.
Also I stop at the first invalid UTF-8 string element, otherwise later
valid strings may hide previous invalid ones.
This bug was mostly invisible since we don't have any core PDB API with
GStrv parameter so far, only GStrv return value.
Even if the container is empty, then we return a GStrv of length 1 (i.e.
an array of length 1, terminating with NULL).
In particular, it improves gimp_container_get_filtered_name_array() as
well, and in turn various list-returning functions in libgimp. This
makes the API more consistent after changes from commit 8eb7f6df9e.
Note that a NULL return can be acceptable for error cases, but an empty
list because this is the expected result for the request should be an
empty GStrv, not NULL.
In particular, since commit 8eb7f6df9e, even if it returns an empty
array of procedure, it still means an array of size 1 (with the unique
value being NULL).
This also fixes the public API gimp_pdb_query_procedures() which returns
a GStrv using gimp_pdb_query() internally.
Finally don't keep track of the array size, just recompute it with
g_strv_length(), which will be much less bug-prone.
Since GStrv are NULL-terminated arrays, there is always one additional
pointer (NULL).
This is a detail, but still, wrong since commit 8eb7f6df9e which
replaced GimpStringArray by GStrv usage.
When overwriting the same file when exporting, we didn't check if the
image previously had a thumbnail. If the default setting in Preferences
is to add a thumbnail, then it would add one where it shouldn't.
Since thumbnails get saves as part of the EXIF metadata, we need to check
that to see if there was a thumbnail in the original image.
However, we were always removing the thumbnail from the metadata on import.
Let's delay removing this metadata until we need to, which has the
advantage that the metadata in our viewer is more complete.
When exporting starts, we add a check in gimp_image_metadata_save_prepare
to see if there was a thumbnail in the EXIF metadata. If not, then we
disable the thumbnail flag.
In gimp_image_metadata_save_filter we remove the thumbnail metadata when
the user doesn't want to save a thumbnail, or when the image format
does not support EXIF.
Removal of the snprintf define was also part of the UCRT Windows patch
in MINGW. Although it builds fine without this change, there is no need
anymore to redefine snprintf. In addition, I seem to remember that
_snprintf had a shortcoming.
So let's remove the Windows specific code, since it works fine without it.
The UCRT environment is a successor to the MINGW environment on Windows
with a more modern C runtime library.
Building under UCRT we get this error:
../../gimp/plug-ins/file-raw/file-darktable.c:420:7: error:
function '__p__environ' is initialized like a variable"
To fix this we use the relevant part of patch 6 from:
https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-gimp
when Offset and Dimensions Bigger than File Size.
If we didn't read the exact amount of bytes, the whole image would be
filled with white.
Let's change this, so we read as much bytes as we can, and fill the rest
with white.
Added GError parameters to all static file write functions, check for
failed writing and return an error if that is the case.
Additionally, at end of file make sure the last dummy byte is written to
make chunks an even size.
This will work around such errors from the g-ir-doc build:
> devel-docs/g-ir-docs/pages/python/Gimp-3.0/Gimp.checks_get_colors.page:46: parser error : EntityRef: expecting ';'
> gimp_checks_get_colors (gimp_check_type (), &color1, &color2);
> ^
Similar to commit 7123b6c466, it cannot really be considered a proper
fix, barely a workaround for g-ir-doc-tool not even able to produce
valid XML. Here we have ampersands which it should have espaced into XML
entities.
Anyway this will do for now (until we just decide to drop the g-ir-docs
tools?).
In the original gimp-2-10 branch where this feature was originally
worked on, we had to keep gimp_checks_get_shades(). But on `master`
where we will reset and break API, let's get rid of this function which
should not be used anymore.
The animation playback now follows user preferences for checkboard
rendering.
Also fixing a small bug there, as the GIMP_CHECK_SIZE_SMALL_CHECKS was
the wrong type (it needed a check type, not a check size parameter).
Since we changed it, the version must be incremented too. It means that
third-party developers will have to rebuild their plug-ins.
Fixed Conflicts from !274:
libgimpbase/gimpprotocol.h
- Slightly nicer layout for the checkboard color widgets.
- Also set the 2 color widgets insensitive when the check type is not
GIMP_CHECK_TYPE_CUSTOM_CHECKS.
- Default the custom colors to the same colors as the basic default
grayscale. I mean, red and blue defaults are fun and all, but that's
like radioactive colors burning the eyes! Ahahah!
- Unlike the gimp-2-10 commit (cf. !274), on the main dev branch, use
the new GimpLabelColor widget.
Fixed Conflicts from !274:
app/dialogs/preferences-dialog.c
Right now, the various Gimp*Preview classes have code initializing their
transparency colors correctly. Some plug-ins, such as tile-small are
directly using a GimpPreviewArea and need to be initialized directly by
the plug-in.
I also realized that several plug-ins (such as gradient-flare) are
rendering their own alpha checkboard, despite using a GimpPreviewArea
(maybe was it code from a time before this class had support for alpha
checkboard rendering?). So this would have to be improved later.
- Some coding style fixes (alignment, etc.).
- Adding missing "Since: 3.0" annotations. We are still wondering
whether this should go in 2.10, in which case, it would become
"Since: 2.10.32" annotations. See discussion in !274.
- Changing gimp_checks_get_colors() signature: merge the 4 color
arguments into 2 (inout) arguments which seems a bit nicer in C,
whereas binding handles such arguments correctly. The other
alternative would have been to at least change the order to have out
arguments in the end.
I also hesitated to get another API in libgimp, which would have been
config-aware (just returning the 2 check colors, depending on user-set
Preferences), then having GimpPreviewArea handling 2 colors (without a
GimpCheckType input). But actually, doing this, we'd remove the nice
menu popup where one could choose a generic check type (not everyone
wants to play with specific non-gray colors) in Gimp*Preview widgets.
So in the end, I left this whole thing as-is.
Instead I document the function with code sample to initialize
properly the GimpPreviewArea (since libgimpwidgets/ are independent
with no knowledge of the core config) in order to respect user
preferences.
- Hide the color properties in gimp_preview_area_menu_new() because
anyway gimp_preview_area_menu_new() does not support GimpRGB
properties right now (so all we get are warnings). It's still possible
to select custom colors on GimpPreviewArea, simply we are stuck at the
ones set in Preferences globally for now (unless a plug-in creates
custom GUI to set these).
Fixed Conflicts from !274:
libgimp/gimp.h
libgimpwidgets/gimppreviewarea.c
Reviewer (Jehan) note: cherry picked from MR !274. Still deciding
whether this will be pushed to gimp-2-10 branch too.
Fixed Conflicts from !274:
app/dialogs/preferences-dialog.c
app/display/gimpdisplayshell-draw.c
app/plug-in/gimppluginmanager-call.c
libgimp/gimp.c
libgimp/gimp.h
libgimpwidgets/gimppreviewarea.c
libgimpwidgets/gimppreviewarea.h
libgimpwidgets/gimpscrolledpreview.c
- Changed all static read functions to have a GError parameter, use a
parameter for the value read, and return a gboolean that will be FALSE
when reading from file failed.
- Check the return values of all read functions and set GError when
needed.
- Added more error checking, like comparing real filesize with what the
header tells us, check for valid speed and number of frames.
- Added some gdebug statements for easier debugging.
- Don't assume that all FLI/FLC writers followed the specs and wrote an
even number of bytes per chunk.
- Skip "frames" that do not have the FRAME type (in most cases this is
a PREFIX chunk).
Improvements to the FLI loading and exporting plug-in:
- I added a GError parameter to all public read/write functions.
- All public functions now return a gboolean result to show if they
succeeded or failed. Before most functions were void. For the non void
returns (the two fli_write_color functions) I added a gboolean
parameter.
- Do cleanup if we fail to read a frame. If at least one frame was read
successfully, we will keep the incomplete image/animation.
- Change name of layer to include the delay in ms.
Why: MR !389 changed the signature of PDB procedures to return GStrv instead of (int, GimpStringArray)
This changes handling of results from a call to such a changed signature, in a Scheme script.
The symptom was a cryptic TinyScheme "Error: car: argument 1 must be : pair"
Most changed procedures are named like "-list".
I did a cursory grep to look for other instances.
Updated porting guide doc.
The unsigned long type in this plug-in is always used for reading/writing
32-bit unsigned integers, so let's change it to guin32 to not get
confused.
Changed unsigned short to gushort, unsigned char to guchar.
Why: in v3 the signature for gimp-edit-foo PDB procedures changed to support multilayer selection.
This finishes the task for ScriptFu scripts in the GIMP repo.
This is not a complete list, since some calls were changed incidentally by prior commits.
You can grep for "edit-copy" etc. in script-fu/scripts to find instances.
This also makes incidental changes, to script calls to plug-in-tile,
which now also has a changed signature to support multilayer.
The changes are simple code transformations.
The changes to gimp-edit-paste calls are more complex,
a mixed bag of a few lines transformed to more lines.
I did not try to understand the larger logic of the changed plugins.
I did not test the changed plugins functionally.
I used a harness to call each changed plugin with improvised parameters,
only checking that the test plugin did not throw runtime errors,
not checking that they produced correct images.
As noted in the issue, this might be undone if the original signatures
for gimp-edit-foo are restored as convenience functions.
Remove `gimp_display_shell_keyboard_grab()` and ...ungrab(), as there
doesn't seem to be any good reason to grab the keyboard away from the
compositor. More annoyingly, in some systems it will pop up a dialog
on each first click whether the user is okay with inhibiting shortcuts.
Why: this commit fixes PATTERN using code that commit 708f3228 fixed for BRUSH.
Importance:
There doesn't seem to be any issues it resolves.
No code in the GIMP repo seems to call this procedure.
I don't know whether third party plug-ins rely on this procedure.
Anyway, fix it so a brute force test works.
Since the new AppStream URL types are only available since appstream
0.15.3.
Thanks to Eli Schwartz for notification of the availability of the
'version' option, even in find_program().
See the commit 28467cb on the gimp-data-extras repo where I moved this
data in. Not sure why this metadata file was ever pushed to the main
repo as it is obviously for the data-extras package (or else I am
missing some information!).
The old 2017 report where it was originally added:
https://bugzilla.gnome.org/show_bug.cgi?id=763398
appstreamcli on CI fails with error:
> E: org.gimp.GIMP:394: release-time-missing date
I didn't have such error on my local build, because it is a new check
only recently added. The CI appstreamcli errored-out this way.
It forces us to add a bogus release date since we don't know it yet. I
chose May 29, because we usually release on Sundays, and it might soon
be time to make a dev release (so who knows, we might get lucky and it
might happen this day), though it should not be taken as a promise or a
real plan just now. I just needed to fill something in, in order to fix
the CI.
I opened a report to ask that appstreamcli proposes a relaxed check mode
where we can test on the <release> tag before knowing the future date:
https://github.com/ximion/appstream/issues/398
appstreamcli returns an info message:
> I: org.gimp.GIMP:3: cid-missing-affiliation-gnome org.gimp.GIMP
Checking the message, it happens because the application ID does not
start with "org.gnome." (but "org.gimp.").
Double-checking AppStream docs, a note says:
> You should only identify with an umbrella project if you use all their
> infrastructure and policies, for instance string freezes dates,
> bugtracker and source control instance.
GNOME Foundation is indeed an umbrella for us for the infrastructure and
obviously part of its policies. But we are still independant and don't
depend on GNOME's freeze dates, or release dates, or design rules
(though we try to follow what makes sense), and so on. So I guess it
means we should not set this metadata tag? 🤷 Let's drop it.
See: https://freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-project_group
Adding a TODO as date was passing through with appstream-util in relax
validation mode, but there is no such mode in appstreamcli.
Anyway since I have manual check steps for the AppStream files in
devel-docs/release-howto.txt, I never missed setting the date right (so
far! Knocks on wood…) in the AppStream metadata. Therefore let's drop
this trick for now and see how it goes.
It should fix the appstream unit check, but only when using appstreamcli
0.15.3 or over (this version is already on Debian testing).
See issue #8140.
This was missing ever since commit 505a78e715 but we weren't seeing this
by using meson. I opened the report #8145 for us to handle this
regression of the build system.
As told to us, this is the reference AppStream file testing tool, and it
understands more of the spec.
Also since commit 73e2e701da, appstream-util chokes on newer url types
from the spec. These tags are now supported both in appstream-util and
appstreamcli source code, except that appstreamcli had release 0.15.3,
available in Debian testing, whereas there were apparently no recent
appstream-glib/util release (and none since 2020). So for these various
reasons, let's go with the appstreamcli tool.
The only downside is that appstream package (where appstreamcli lives)
is not available on MSYS2, but since it's only an optional test tool for
XML files which should be common on all platforms, it's probably
acceptable.
This change is part of multilayer select feature of v3.
Only fixes ScriptFu plugins, not Python or C.
Only fixes calls to file load/save procedures and other plugins already multilayer capable.
Any future PDB procedures changed to have multilayer signature will require changes to all callers.
The new code is verbose: "drawable" => "1 (vector drawable)"
Issue 5919 proposes a change to the PDB that would make this less verbose:
"drawable" => (vector drawable)" (without the number of drawables)
Tested that changed procedures will interpret without syntax errors, on one path.
Did not test each changed procedure for functional correctness.
We have some examples of DDS images that have two 16-bit channels that
we could not load.
This commit adds checks to see if we need 16-bit channels, and conversion
of the input to a correct 16-bit red, green, blue or alpha channel.
To be able to use certain variables we use in our DDS loader earlier,
we move the computation of these variables up.
We also add checks to see if the mask needs to be for 8 or 16-bit, since
there are DDS images with 16 bits per sample.
GIMP could crash if the information regarding old path properties read
from XCF was incorrect. It did not check if xcf_old_path succeeded and
kept trying to load more paths even if the last one failed to load.
Instead we now stop loading paths as soon as that function fails.
In case we have a failure here we also try to skip to the next property
based on the size of the path property, in hopes that the only problem
was this property.
This was a long standing issue where the image was not printed at the
position as selected in our print preview.
The problem being that we do not take into account the dpi of the print
context we are printing to, but instead always assumed 72.
This is the fix that was suggested by Massimo.
When you change a settings in Preferences which requires a restart of
GIMP, the current list was pretty ugly. I am still not fond of the popup
but at least now the list formatting is slightly better:
- Use a unicode bullet point character in UTF-8 encoding (since
gtk_message_dialog_new() expects UTF-8 input) on each list element,
instead of just writing them without any kind of formatting.
- Use the "nick" of the changed config, not the name. The "name" is an
internal string which is really not meant to be viewed by people,
while the "nick" is more like a short human-readable name or title,
exactly what we want to show here.
Some strings might be generated during query() call, in particular all
strings related to procedure parameters. The core will only know the
localized version at query() time, so you could end up in situation with
the core showing you the wrong language. This can be reproduced in the
Procedure Browser when it shows localized procedure data: when you
change the language and restart GIMP, if the plug-ins aren't re-queried,
then it will still show the localization of query time.
Note that it doesn't matter on plug-in side, i.e. anything in the run()
call is properly localized, included the plug-in GUI using the same
procedure parameters for widget labels or tooltips. Only the "vision" of
the core is stuck at what it got when the plug-in was last queried, and
until the next update of the plug-in.
Small text tweaks done too:
- Some question marks removed to be more consistent in the tooltip
style.
- The "save-transparent" only applies to *completely* transparent pixels
(not partially transparent).
Let's not try to align anymore the label text with the value (numbers
inside the GtkEntry) text. Our previous offset computation was wrong
anyway, but even correctly aligning the text, there could be cases where
the label's actual font was bigger than the number's font.
I had the case with GIMP set in Korean. The number text was 11-pixel
high but the Hangul text on 16 pixels in plug-ins using a GimpSpinScale,
most likely because the font used for numbers didn't have Hangul glyphs.
So we ended up with very ugly scale title on the bottom of the widget,
even out of the progress area. Instead, we just make sure that the label
is exactly in the vertical middle of the widget, disregarding the entry
layout's offset.
Also changing "RGB->YUV" by using a real Unicode rightward arrow encoded
in UTF-8 since GTK functions (such as `gtk_widget_set_tooltip_text()`)
explicitly uses UTF-8 encoded strings as argument. This renders much
more nicely than an ASCII-made arrow.
As mentioned by Massimo in issue #6618, part of the problem there is an
integer overflow when using large size images when computing the offset
in pixels.
Let's fix our part of the problem by casting to guint64.
Besides that, also use casts to correctly compute progress for very
large images.
So it turns out that the "notify::src-drawables" property signal in
particular can happen during gimp_paint_tool_paint_interpolate() called
from gimp_paint_tool_paint_thread(). Though the function
gimp_clone_options_gui_update_src_label() was run in the main thread in
simple cases, being called this way through a paint thread happens when
very quickly changing the source while painting, which is what Aryeom
does (when I see her using the clone tool, she would sometimes change
the source very quickly several times in barely a few seconds).
Yet GTK and GDK calls must not happen in non-main threads. It used to be
acceptable when protected with gdk_threads_enter|leave() calls but doing
this is deprecated. The now sanctioned method is to call the GTK code in
an idle function since these are guaranteed to run in the main thread.
This was most likely explaining why crashes could quite randomly happen,
though I'm not sure why I never had those (even though I could reproduce
the GTK calls happening in non-main threads, but without crashing GIMP)
and why Aryeom gets these much more often suddenly. Maybe some recent
dependency change which would trigger these more easily or other
context-dependant changes (as most non thread-safe code, bugs and crash
often happen in race conditions, so are harder to reproduce reliably)?
We already had import support through littleCMS. We now use fully
babl/GEGL which makes our code more straightforward and identical,
whichever the input format.
The export support is totally new. It comes with a checkbox to propose
selecting CMYK export and a label displaying the CMYK profile which will
be used.
Now this whole implementation has a few drawbacks so far, but it will be
a good first sample for future CMYK-related improvements to come:
* The export profile I am using is what we call the "simulation
profile" from the GimpColorConfig. This corresponds to the default
"Soft-proofing" profile as set in Preferences. In particular, this is
not the actual soft-proofing profile for this image which might have
been changed through the View menu because this information is
currently and unfortunately unavailable to plug-ins. It is not the
"Preferred CMYK Profile" either, as set in Preferences.
TODOS:
- We really need to straighten the soft-proof profile core concept by
storing it in the image and making it visible to plug-in.
- Another interesting improvement could be to create a
GimpColorProfile procedure argument which would be mapped to a color
profile chooser widget, allowing people to choose profiles in
plug-ins. For an export plug-in in particular, it could allow to
select a profile different from the soft-proof one at export time.
* When we export, if no profile is choosen, babl will use a naive
profile. It would be nice to store this naive profile into the JPEG if
the "Save color profile" option is checked (same as we store a generic
sRGB profile when no RGB profile is set).
* When we import, we just import the image as sRGB. Since CMYK gamuts
are not necessarily within sRGB (some part of the spectrum is usually
well within, but other well outside), other than the basic conversion
accuracy issue, we may lose colors. It would be much nicer to be able
to select an output RGB profile. Optionally if we could create a RGB
color space which is made to contain the whole input CMYK profile
color space, without explicit choice step, it would be nice too.
* I am using babl's "cmyk" format, not the expected "CMYK" format.
"cmyk" is meant to be an inverted CMYK where 0.0 is full ink coverage
and 1.0 none. Nevertheless when loading the resulting JPEG in other
software (editors or viewers alike), the normal CMYK would always
display inverted colors and the inverted cmyk would look fine.
Finally I found a docs from libjpeg-turbo library, explaining that
Photoshop was wrongly inverting CMYK color data while it should not.
This text dates back from 1994, looking at the commit date which
introduced this paragraph. In the 28 years since then, could this
color inversion have become the de-facto standard for JPEG because one
of the main editor would just output all its JPEG files this way?
See: dfc63d42ee/libjpeg.txt (L1425-L1438)
… plug-in code.
In particular, we should not hardcode this in core code anymore. The
behavior is otherwise exactly the same, except that we made the core
code generic as it should be.
The CLI options now know which procedures are batch procedures or not.
First it means that it won't just randomly try any procedure name one
may pass and will properly output an error if you pass a non-existing
interpreter procedure.
Secondly, there is no default interpreter anymore (unless only one
interpreter exists). If you don't set an interpreter procedure with
--batch-interpreter or if you pass a wrong one, it will output the list
of available batch procedure, thus helping you understanding how to use
the --batch option.
Call gimp_exit() rather than emitting the signal ourselves. This way in
particular, the still-opened images are properly freed and we avoid
GeglBuffer leaks from images we might have created in a batch script, or
the images loaded in command lines.
If you call GIMP with batch commands and ask it to quit immediately, you
are likely interested by failure information. For this reason, let's now
report exit code other than success, but only in such case. In
particular, even if the batch commands fail, but GIMP is not set to exit
immediately, we continue reporting SUCCESS run at the very end (when
exiting interactively).
Note that I hardcode a few exit values, as standardly found on Linux
(but not using headers which may not be found on all platforms; in
particular, Windows apparently doesn't use any standard code other than
0 for success, from what my searches return).
Additionally, when several commands are requested, GIMP will now stop at
the first failing and will return its error code, and print a message on
stderr to easily report the failed command for easier debugging.
Fixes:
> [33/48] Generating Gimp-3.0.gir with a custom command
> ../../../../../../../dev/src/gimp/libgimp/gimpimageprocedure.c:228: Warning: Gimp: missing ":" at column 41:
> * @run_func: (closure run_data) the run function for the new procedure.
> ^
Instead of asking for the script to call gimp_quit() which is not too
proper (because this is actually meant to exit the script, not GIMP
itself. Scripts should not have the ability to basically kill the main
GIMP process), let's add a `--quit` option which does what it says: it
quits GIMP immediately (after having processed any task on command line,
such as running batch scripts).
See discussions in issue #7376.
This should fix various hard-to-reproduce cases of:
> (gimp-2.99:50596): Gimp-Core-WARNING **: 00:42:45.324: gimp_finalize: list of contexts not empty upon exit (2 contexts left)
>
> stale context: (null)
> stale context: PDB Context
We had these warnings happening randomly at exit and not always
reproduceable with the same steps. I had it reproduced much more easily
when working with CLI scripts exiting GIMP immediately. The context were
actually properly unref-ed but simply we had to wait a bit for events to
be processed before destroying the main GIMP object.
The PDB context name was overwritten when syncing with the parent
context, e.g. the "User" context. Therefore "stale context" warnings,
for instance, were misleadingly telling the "User" context was leaking.
On Windows our Lua goat extension crashed when run. After some digging
it appeared that incorrect annotations were the cause.
The destroy annotation was clearly an error when loking at the gir API
documentation. However, it also crashed on `(closure run_func)`, which
seemed to be as it should.
After comparing what other libraries do and testing, it seems that the
documentation for (closure CLOSURE) is incorrect. See the discussion
in the above mentioned issue.
The correct use here seems to be to use it as annotation of the run_func
where CLOSURE points to the user data. So, that's what we implement here.
Performing zoom and rotation at the same time is inconvenient because
most of the time the user will want either zoom or rotation. This can be
solved by recognizing a "significant enough" zoom or rotation change
initiated by the gesture recognizer and then ignoring the other gesture.
GIMP stopped trying to read the XCF as soon as an invalid parasite was
encountered. However, in this specific case only the parasite data is
invalid, while the rest of the image is not corrupt.
Instead of terminating when we see a corrupt parasite, we skip to the
offset after the parasite. This may still be corrupt, but we can handle
that correctly, see e.g. the XCF in bugzilla issue 685086, which was
the reason of some of the previous changes.
Additionally:
- We add some logging to make it easier to handle future issues in this
area.
- We add tests for a NULL parasite name, and for reading a different
amount of parasite data than we expected. In both cases we return
NULL instead of a parasite.
Adds the new configuration option "drag-zoom-speed" to adjust the rate
at which mouse movement can zoom the canvas, ranging from 25% to 300%
of the base rate and applying to both drag-to-zoom modes.
This option can be found in the preferences dialog as:
Image Windows -> Zoom & Resize Behavior -> Drag-to-zoom speed
Adds a new configuration option "drag-zoom-mode" to choose whether to
zoom by distance of movement (newly added) or by duration of movement
(previous behavior) when zooming via dragging the mouse, defaulting to
distance.
This option can be found in the preferences dialog as:
Image Windows -> Zoom & Resize Behavior -> Drag-to-zoom behavior
Changes the behavior of gimp_display_shell_scale_drag() to factor in
the distance dragged, rather than just scaling a flat +/- 10% for each
detected movement event. The factor by which to change the scaling is
also altered from 10% at each movement event, to 1% compounded for
each pixel of distance dragged.
This makes zooming via Ctrl + Middle Click or Ctrl + Spacebar behave
more consistently and less jittery versus the previous method, while
offering more fine grained control.
with many Xmp.photoshop.DocumentAncestors tags
This is similar to #7464, but in this case the XMP metadata was already
included in an XCF image.
We check for the occurrence of Xmp.photoshop.DocumentAncestors and stop
handling values when there are more than a 1000.
It would be easier to just check length for all tags and always
ignore when there are more than a 1000 values.
But in that case we would need to be sure there are no valid reasons for
tags to occur more than a 1000 times. So let's just limit it to this
specific tag.
JSON does not support comments and their support in Flatpak is possible
through use of json-glib[0]. This is problematic in fully utilizing
flatpak-external-data-checker because its JSON writer does not respect
existing comments. To solve this, make use of Fltpak's specific
behaviour where a "//" key is explicitely ignored while parsing[1].
[0] flatpak/flatpak-builder#363 (comment)
[1] 0e98b7ae19/src/builder-utils.c (L1250)
OpenEXR and mypaint-brushes offer next major versions. GIMP is probably
not ready for the changes in OpenEXR and mypaint-brushes are not yet
finalized. Put their versions under constraints so that automatic PR
creation for dependency bumps can be enabled.
For the build tool, we really don't need a recent GLib. Checking the few
function docs, GLib 2.2 is fine, which (looking at git logs) means any
version after 2002. At this point, it's nearly unneeded to add a minimum
required version, but let's be thorough.
Anyway really no need to block a build if we have an old build GLib,
which is completely enough, as long we have the recent host GLib.
As suggested by jeremyd2019 and Biswa96 of MSYS2 project, defining the
MNG_USE_DLL macro would trigger libmng header code to fix the calling
convention. This way, even the old detection code now works with Windows
32-bit.
The reason why we still stick to this old detection code is that the
pkg-config is likely not everywhere (e.g. in Debian package libmng-dev,
there is no `.pc` file). So the pkg-config test is good but we still
definitely need to keep our fallback more old-school test for this
dependency.
See this comment in particular:
https://github.com/msys2/MINGW-packages/issues/11136#issuecomment-1084627263
Note: I am unsure yet how to apply the same trick on the autotools test
because AC_CHECK_LIB() would allow us to tweak the cflags to define a
macro, but we also need to include libmng.h header, otherwise the
calling convention tweak is not run. It doesn't look to be feasible with
the autoconf macro, or at least I haven't found how yet.
The main problem was that file-mng would fail to build on Windows 32-bit
even though the lib was detected. Actually this is because there are
several possible calling conventions and this can be handled by defining
the proper macro. This macro is well defined in the pkg-config file, but
our build was not using it.
So let's change the test to use pkg-config first. If this fails, we
fallback to more basic method of finding the library. Additionally we
augment this fallback test with a function check (as we do already in
autotools) so that our configure test is reliable: we verify that the
lib is there **and** that symbols are visible. Otherwise we'd end up
with a successful configure test followed by a broken build (as until
now in meson).
See the nice explanation here and in next messages:
https://github.com/msys2/MINGW-packages/issues/11136#issuecomment-1083711452
It looks like the gi-docgen build is broken on Windows (though the CI
does show neither stdout nor stderr output, just a failure without
message). This should be fixed, but it's not necessary for the installer
at least.
Note: on autotools, the gi-docgen step works fine on Windows.
We didn't need to do this on the autotools build, simply because the
configure step is much more elaborated there, and was checking for the
header file as well as well as a working mng_create() API. But since
libmng was broken, the test failed, so we didn't need to disable it.
By the way, we should check when the `.pc` file was added, because if it
was after the required version, then the meson test is very wrong. It
should not have been different from the autotools file.
The `link_with` arg only accept library targets which are the libraries
we build ourselves, whereas dependency objects (such as returned by
cc.find_library()) must be in the `dependencies` arg.
Yes me too, making a difference here kind of stun me a bit and I don't
get why it's needed, but so be it. Since this code dates back from the
original commit, I assume it means the directx option just never worked
with meson on Windows.
Fixes:
> ../meson.build:847:2: ERROR: Entries in "link_with" may only be self-built targets,
> external dependencies (including libraries) must go to "dependencies".
The meson build still has a bunch of issues and build bugs compared to
the autotools build, nevertheless the last blocker issue was dealt with
a few days ago (PDB source generation).
Moreover since the meson build on Windows especially makes such dramatic
difference, in terms of build speed, this is a big improvement for
Windows contributor's comfort, and as such is one less barrier of entry.
Anyway I believe that most Windows developers build GIMP with meson now
so sticking on autotools on this platform is just counter-productive.
This is why it was decided to now make meson the recommended build
system on Windows, as a further step toward a move to meson. It is still
not the recommended build system on the other platforms yet.
This fixes the following warnings:
```
[2153/2321] Compiling C object app/widgets/libappwidgets.a.p/gimppanedbox.c.o
../app/widgets/gimppanedbox.c: In function ‘gimp_paned_box_dispose’:
../app/widgets/gimppanedbox.c:171:17: warning: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’ [-Wsign-compare]
171 | for (i = 0; i < G_N_ELEMENTS (paned_box->p->dnd_highlights); i++)
| ^
../app/widgets/gimppanedbox.c: In function ‘gimp_paned_box_drop_indicator_draw’:
../app/widgets/gimppanedbox.c:370:17: warning: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’ [-Wsign-compare]
370 | for (i = 0; i < G_N_ELEMENTS (paned_box->p->dnd_highlights); i++)
| ^
```
The --debug option so far would only output debug info. I want both the
run to actually occur and the debug to be printed, at least in some
cases. So I make this a choice option with 3 variants (no debug, debug
only and run + debug).
Similar to the change I pushed to gimp-help repository:
intltool-extract does not consider the `;` isl-syntax comments because
we tell it it is in the ini format. So let's have our source in actual
ini format (POTFILES does not like to look for translated strings in
constructed files, only from source files), then create the .isl files
from it in 3 steps (first, transform the comments in isl format; then
merge all language in a single .isl file; last generate one .isl per
language).
There were already a bunch of comments in the setup.isl.in file (though
not showing in the po files until now). I checked if they seemed
relevant, fixed some, completed others, duplicated the ones which match
several strings, etc.
(This improvement to allow comments for translators in the installer po
files was requested by Piotr Drąg on the gnome-i18n mailing list)
Some tools have been moved. `aclocal` (and likely other tools, but this
was the first one making an error in the deps-win*-native CI jobs) is
now in `automake-wrapper` package, which itself is a dependency of
`autotools`.
Cf. https://github.com/msys2/MINGW-packages/issues/11114
Fix the dependency by making the stamp an actual (yet empty/no-op)
header file which is included by all generated source file. This way, we
ensure that meson rebuild .o files when the .pdb sources are changed.
This is the second solution proposed by eli-schwartz here:
https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080053413
This was introducted in commit 65eff6f150, i.e. together with the
initial port. I have no idea why this is here and if it is about the
stamp-pdbgen, why would we want to remove it. The PDB is a major piece
of our codebase and the simplicity to generate new PDB procedures is a
core feature.
The build now successfully build the PDB files into the source folder
itself. Unfortunately it seems I can't get meson dependencies to work
properly, once more! I added a "sources" argument to the relevant
library() or static_library() but it still uses old versions to build
these. E.g. if I add an error on purpose to a pdb file, the next build
still passes, yet the second-next fails (as it should have before).
Note that I even tested a declare_dependency() with just the "sources"
arguments, because it says "sources to add to targets (or generated
header files that should be built before sources including them are
built)" (so I assume it means that it should be trigger a rebuild,
otherwise it's useless) but it's just not working. I'll investigate
more.
Still going with this for now, because at least generating the PDB
source was a big miss until now. But we should
To work around the issue, I just wrote a stupid sed script. Of course,
it means that if we encounter again the issue on some other docs, we'll
have to update it. In other words, it's neither robust nor a proper
long-term fix. Just a temporary hack.
See: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/425
Also fixing this issue, I encountered another bug, this time in meson,
which changes backslashes in slashes on 'command' arguments, in a
completely uninvited manner! The only workaround to this is apparently
to call an external script, which is ridiculous for such a basic stuff.
But well… here is why I implement this with a script, instead of
directly calling sed in the meson 'command'.
See: https://github.com/mesonbuild/meson/issues/1564
After some investigation, I am a bit unsure of why this happens exactly,
but I have a case that the device's axis number listed is not right and
this only becomes apparent after the stylus gets close then further from
the tablet-display. This fixes it, though I think we should look more
closely and reorganize a bit this whole part of our code, which seems
unecessarily complicated and duplicating some data already in GTK/GDK,
like the list of axis, etc. (though maybe it was necessary back when
this was first implemented before more logics got moved to GDK?)
Fixing broken coding style and factorize the code to avoid redundant
calls, in a separate commit as the contributor hasn't responded for
nearly 2 years. Also no need to get the character count as -1 offset is
equivalent to point after last character (or alternatively we could have
used gtk_text_buffer_get_end_iter()).
I had raised some more questions on a possible better implementation (or
maybe not), but since the discussion never happened, let's just push
as-is. It still improves things and the whole text editor should be
revamped some day anyway.
The MR commit (i.e. previous commit) fixes the specific case when
changing font size with no text selected (changing the size of the whole
text).
Some coding style fixes, also one warning fix, and a lot of shuffling
around to reorganize the code. Basically removing the prototype listing
at the file start is a big error. This file is huge and without a
minimum of organization, it's a huge mess to understand what's what.
Basically a class file must always start by the class_init(), then the
init(), then the various object methods (constructed() or finalize() if
any, etc.), and possibly other parent classes' implementations. These
are the entry points, it's normal to start here (not from leaf
functions!).
Then we get the public functions which are other entry points (calls
from other parts of the code). And only after, private functions such as
signal or action callbacks, and utilities at the very end.
This requires a well organized prototype listing, which works as a menu,
and prevents the implementation order to depend on call order (this gets
us completely random order and imply usually that top functions are the
less important ones, such as utilities, just how it was before this
commit).
Anyway I'm not sure why I spent time on this because we deprecated this
plug-in, but if we still want to push nice updates (like MR !519), we
should at least do it well and clean. Also it's a good first example for
plug-in rewrite in modern no-GtkAction code.
The initial attempt of this commit was to remove the `GtkAction` usage,
but grew a bit wider than that. The following happened:
* The dialog became a proper GObject, rather than being a big chunk of
static variables that were hopefully initialized before you used them.
* The dialog now uses `GAction`s to implement actions, and converted
some signal handlers to actions as well.
* The plug-in run procedure now uses `GtkApplication`. This is one hand
necessary to be able to set accelerators for actions, but on the other
hand is more future-proof, as GTK4 removes `gtk_main()`
It's not a direct dependency and doesn't prevent GIMP from any of its
core logics, but HTTP is a used enough format nowadays that we want to
consider it as mandatory nowadays.
From what I know, `gvfs` might be for Windows only though. This would
explain issues we have with remote URL on other platforms.
Our main issue is that GIMP does not accept indexed images with linear
backend. MR !460 was an attempt to fix this, but some weird pixel data
conversions were happening so the result was very wrong.
We could try to investigate this and add support for linear RGB palette
colors, but it's unclear how necessary it is (i.e. is there any indexed
image format for which we'd want this? PNG is not one such format as
will be explained below), especially that palette are u8 only right now
and linear RGB u8 is not the best idea anyway.
In cases reported in #6886 though, our code would say the input is
linear mostly because it had a 1.0 gAMA chunk (or we could have a case
with a linear profile too). But then we don't need to set such data as
being in linear RGB. Just set it as non-linear RGB (R'G'B') with the
associated linear profile and that's it.
Setting a linear backend to an imported PNG would only be useful if PNG
had some flag explicitly asking for this, bypassing any profile TRC. But
as far as I can see in its spec, there is no such thing.
The code can be 0, but not the domain. Let's use G_FILE_ERROR as all
these errors are about problematic file contents.
Fixing these warnings:
> g_error_new_valist: runtime check failed: (domain != 0)
Committer's (Jehan) note: with clang version 12.0.0 on macOS Big Sur,
it seems that warnings such as the following are outputted:
> plug-ins/file-psd/psd-load.c:447:32: warning: variable 'block_len' is uninitialized when used here [-Wuninitialized]
> block_len = GUINT32_FROM_BE (block_len);
> plug-ins/file-psd/psd-load.c:2312:34: note: initialize the variable 'comp_mode' to silence this warning
> guint16 comp_mode;
Recently it was not possibly in master to open online help (F1).
This is also mentioned in issue #7915. However, on macOS there are likely
also other problems, which is why I'm hesitant to close that issue with
this fix.
(help.exe:57964): LibGimpBase-CRITICAL **: 15:24:38.792:
gimp_value_array_index: assertion 'index < value_array->n_values' failed
(help.exe:57964): GLib-GObject-CRITICAL **: 15:24:38.792: g_value_get_boxed:
assertion 'G_VALUE_HOLDS_BOXED (value)' failed
This was most likely caused by 8eb7f6df9e
Changing this to use args 0 and 1 instead of 1 and 2 fixes the problem.
Instead of replacing various needed macros with random hardcoded values,
just make them mandatory and exit with explicit error when a needed
macro is missing.
Since 2afa019c70,
the Meson configure step will fail when building from tarball (missing `.git` and `gitversion.h` is present)
because `gitversion_h` variable will contain a `list[file]` but `custom_target` does not like that in its `depends` kwarg.
GExiv2 0.14.0 was released last September. It has been on Debian Testing
since October. The MSYS2 repository for Windows also provides this
version now, and I have bumped the version used in gimp-macos-build. So
let's upgrade the requirement (for the dev branch only) so that we can
finally get rid of all the remaining annoying warnings relative to this
library.
This new function is an alternative to existing
gimp_image_metadata_save_finish, when you want to save metadata
yourself and you need only filtering processing.
It returns filtered metadata allowing the caller
to save the finalized metadata via other means
(via native format’s library for example)
This API can be used to support metadata saving of image formats
not directly supported by gexiv2/exiv2.
I tested it against various merge requests and the more I go, the more I
wonder if it will ever be *really* useful. It detects so many false
positive of totally acceptable code. I tweak the style rules, improve
some things but then make other things worse.
Actually the logic of having one "best" case with the penalty system is
flawed IMO. We should really have rules of what is acceptable and should
not trigger changes vs. what is not acceptable styling.
For instance what such a system cannot detect is when we organize some
things on purpose, for instance for semantic reasons. If it's just "best
rule" based, it cannot work, but with an "acceptable style" logic, the
on-purpose organization of code will just pass as long as it doesn't
break the coding style.
Anyway let's see…
Since commit 4cf38d784f, when loading an indexed image, we would first
initialize a palette with 0 colors, then set it to the right colors.
Babl outputs the following message when initializing to 0 colors:
> ../../src/babl/babl/babl-internal.h:214 babl_log()
> attempt to create a palette with 0 colors. using default palette instead.
Let's only set the palette to Babl when it has colors.
We take a step back from the original MR which was proposing the "single
dot" cursor as a new "Pointer mode" option. I was really unsure this was
the best solution, especially reading again the whole original report.
It means that now nearly all of the original patch has been rewritten
another way, but let's leave the contributor commit as a start point to
get to where we are, and as acknowledgement of the contribution.
The reporter was annoyed by the crosshair when none were requested and
probably mostly for painting tools only (at least examples were about
brush or pencil, etc.) while showing outline. It looks to me like the
real issue was maybe when we were showing the big crosshair when using
the 4-arc fallback outline, for instance when using a dynamics changing
size. If so, this main issue is already fixed by my commit 64dc26064b.
No need of a new option for this, especially if the option can be as
confusing as a barely visible dot-cursor (I can already imagine the bug
reports of people tweaking random preferences and unhappy because the
pointer became invisible, while they don't know how they did it).
Instead I would say that when people specifically uncheck both "Show
brush outline" and "Show pointer" options, showing a huge crosshair
feels quite counter-productive. This is where I think that our small
unobtrusive cursor (probably a better name than "Single dot" by the way,
as it's not a single dot anymore) might be of use, the ultimate case
when someone really want a cursor as inconspicuous as possible, while
still having a visible feedback of the pointer position (even with
display-tablets, parallax issues make such a visual feedback important
to target where one paints).
So let's try this first and see how it goes.
- Rename "Mouse Pointers" frame to just "Pointers". It's not just about
mice but all input devices.
- Move the "Pointers" options from "Image Windows" to "Input Devices"
tab in Preferences. It looks to me it's more about how you configure
the device pointers than anything really image window-related.
- Move the paint tool options in their own frame "Paint Tools" to really
differentiate the generic pointer options from the ones specific to
paint tools. This frame is added side by side to the "Pointers" frame
to hopefully underline they are related.
I'm still annoyed by the fact that if you uncheck both the "Show brush
outline" and the "Show pointers for paint tools", it will actually show
a big crosshair in such case. I can understand the logic (not to end up
in a case with absolutely no indication of your pointer position). But
then shouldn't we rather forbid unchecking them both at once? It would
be clearer IMO. On the other hand, are they people who like this big
crosshair and use this?
Other thing I was annoyed about was whether you would not want to have
the "Single dot" only on paint tools. But as Aryeom told me, maybe let's
just try it like this and see if people ask for a double option (pointer
on paint tools vs. pointer on other tools) as it is already very
complicated settings as it is. I mean, at some point, I even thought
about a per-device pointer. I also studied the possibility of detecting
whether you are on a display-tablet (when you are more likely to want an
unobtrusive pointer) or not (then you may be very annoyed each time you
can't even spot easily your pointer on screen). But GTK doesn't give
this later information, and as Carlos reminded me, even a display-tablet
can be mapped to another display, so even if we could detect a
display-tablet, it would not mean it is reliable information for making
a decision on whether we want a light pointer.
Committer (Jehan)'s note:
We know the goal is for it not to be too visible, but here it was really
hardly visible at all. Also now we can actually surround the hot spot
position.
As for the color, if the cursor is black only, it becomes extra-hard to
see on dark background images (or even totally invisible on full black
background). All cursors are drawn with B&W color on purpose.
Setting Aryeom as author, because I was trying colors on one side (then
it looked like micro-lines), or bigger checkerboard (looked weird) or
some other design where it looked like a circle in one case and a cross
in another. Aryeom proposed this much better design instead, which stays
symmetrical, small and not-weird/too widely different whatever the
background color.
… in previous commit.
Also fix some coding style bugs.
Finally change s/"Single Dot"/"Single dot"/ to have the same label
syntax (only capitalize the first letter of the label) as other labels.
Cf. #7034 and !466.
If someone explicitly asked not to get a pointer, yet to have the
outline, we should not force a crosshair on them while the fallback
outline is a perfectly visible mark (4 arcs around the pointer's
position, well delimiting the brush size).
… whether the program is really ready to accept various commands.
In particular, on macOS, one could drop an image to the app icon in the
dock while starting up (visible splash). Then if the profile convert
dialog appears *behind* the splash, it would block loading until an
action is taken (unfortunately as it's hidden, people may miss it and
would think GIMP froze), as reported by cyril and reproduced by lukaso.
I can't test myself, but I'm hoping this will fix the issue (similar to
commit a86ed68870 where we had a similar issue with dbus file opening
on Linux).
Since the "Dynamics Off" is set when the brushcore is started, when we
were running gimp_brush_core_eval_transform_dynamics(), we were using a
previous dynamics output.
Also it's better to shortcut the computation anyway when we know the
dynamics is not for use.
As raised on social networks, the big label grows the horizontal size of
the dialog. Make the label wrappable and give it a smaller wanted size
(otherwise, just making it wrappable is not enough and the dialog is
still too big when first appearing, because of how GTK handles such
widgets :-/).
Actually I realized that using BigTIFF is not the only valid alternative
here. We can also try to use a better compression algorithm (or any if
"None" were selected) and try again to export as ClassicTIFF.
So don't check the option ourselves and don't set it insensitive. Let
one choose fully what they prefer to do.
… because we reached max TIFF size.
We detect the specific TIFF error (by string comparison so it's a bit
weak IMO yet it doesn't seem like libtiff provides anything better;
let's trust they don't change their error strings), then we reopen the
export dialog, pre-checking the BigTIFF checkbox newly created (and
making it insensitive). We still fail with error if an error happens the
second time (even for the same error).
Recent libtiff supports loading BigTiff automatically so we didn't have
anything to do there (as long as a recent libtiff was used). For
creating a BigTIFF though, we simply needed to add a "8" flag to
TIFFOpen/TIFFClientOpen when creating a new image (i.e. using "w8"
mode) as explained here in the "Implementation Strategy" section:
http://www.simplesystems.org/libtiff/BigTIFFProposal.html
What this commit does:
- Explicitly bump our libtiff requirement to version 4.0.0 or higher
(which is where BigTiff support appeared).
libtiff 4.0.0 was apparently released on 2011-12-22 and is available
on all current distributions, so it's probably not a problem.
- Switch to detect libtiff with a pkg-config test (added in libtiff
commit faf5f3eb before 4.0.0 release, so it's fine) instead of
function checks.
(Note: meson was already detecting for libtiff-4 with pkg-config,
which was obviously wrong since it should have mimicked autotools, but
well… then changes were minimal on meson)
- Add a new "bigtiff" boolean argument to the "file-tiff-save" PDB
procedure, FALSE by default. I set this as the first argument as I
figure that choosing the format you want is quite a major choice.
Unless I misunderstood something, since BigTIFF is really designed to
be an evolution of TIFF with a "minimum change strategy", i.e. mostly
using 64-bit instead of 32-bit offsets, everything which is possible
in TIFF will be in BigTIFF (and oppositely as well, except of course
having huge files) so there is no need to have 2 separate procedures.
- Adding this new argument to the GUI dialog as a checkbox.
- Tweak the load and export procedures' documentation strings to make
clear we support both TIFF and BigTIFF.
Note: interestingly there doesn't seem to be a separate mimetype for
BigTIFF so nothing to update on this side.
- Tweak the procedure labels too to mention BigTIFF. Since BigTIFF is
still a different format (though very closely resembling) from TIFF,
unlike some others which are just extensions embedded in a TIFF file
(like GeoTIFF we recently added), I figure it deserves to be
explicitly cited.
… cursor position label.
This should now resolve any weird jumping around of the cursor label,
hence the GUI. Of course, it could actually still happen when going
really off-canvas (though the max computation takes into account
reasonable off-canvas moving, which is totally possible, especially now
that we can view off-canvas so people can just work there and the GUI
should definitely not do weird stuff there as well).
This issue was not confirmed to happen on Linux and Windows, but was
making ugly label resizes on macOS by just moving the cursor on canvas
normally. See video in:
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/572#note_1389445
Ironically enough though, it started to happen even on Linux/X11, at
least, after commit 1baeffc913, which was the commit meant to fix this
on macOS!
This max size computation algorithm should work well enough for any
normal on-canvas usage, and even some off-canvas (yet close enough)
usage.
Note: this code only takes into account the pixel position case, for a
first implementation, which is why it's not pushed immediately in this
form.
Since we increased our minimum version of gexiv2 to 0.12.3, several
functions used in the metadata-viewer plug-in have been deprecated.
Replace these functions with the "try_" versions, which include an
error parameter. If this returns non NULL then we print the error
message to the console.
It's better to start early as these need to be translated too and are
now even visible in GIMP itself.
Note that I wrote 2.99.11 in the version attribute, but only to be able
to test this easily during development. It will have to be edited to the
right version at release.
Since we are pre-processing anyway the AppStream metadata file (because
appstream-glib doesn't pass unknown XML attributes, cf. a previous
commit), it does feel silly now to continue loading the file at runtime
too. Let's just pre-process more data into the constructed C files, i.e.
get the introduction paragraphs and the change items too.
The only other remaining advantage of appstream-glib was that it was
handling the localization but since we also have these localized strings
in our gettext files, we can as well translate with gettext as any other
strings and it works just fine.
It will also get rid of any packaging issue, forgetting to package the
metadata file (as we had on the Windows installer, and still have on the
macOS package). Now it will just always work because data is internal.
The changes include:
* A popover will be displayed on tool buttons and relevant property
widgets.
* Now the welcome dialog gives focus up to its parent window because
really the whole focus styling issue in GTK is a bit maddening. The
colors are all faded, the popover widgets are barely visible, and so
on.
* Timing is tweaked a bit to give more time reading the popover tips.
It's still the same visually but it will be useful for 2 reasons: first,
it makes nicer code to show/hide only this one box instead of 3 frames;
second it will be used for the release note demo feature so that we can
blink the full line art settings box.
… blinking it.
This will be necessary to demo new features available only in some
situations. E.g. a new option in line art detection mode of bucket fill
would require said mode to be enabled.
First I strip now every pieces of text. What it allows it to span the
script elements for instance on several lines, indent them and all that.
The second thing is that since all the dockable start with "gimp-", we
may as well allow use shorter names (both are allowed). Same for tool
(which we special-case), all the tool buttons ID start with "tools-"
since we reused the action names. So let's just allow the shorter
versions.
Finally I create a new gimp_blink_toolbox() which is a specialized
gimp_blink_dockable() for the toolbox in particular. I also move there
the whole code about selecting the right tool.
Make a different bullet points for items with demos and items without,
and add an info text explaining you can click on items with the right
bullet point to get a demo.
Hopefully it will fix the following CI errors:
> make[4]: *** No rule to make target '../../tools/generate-welcome-dialog-data.py', needed by 'welcome-dialog-data.h'. Stop.
I thought using relative paths was fine too here, but I might have been
wrong (even though it worked locally).
The gimp_widget_set_identifier() doesn't really need to be there since
we don't install the gimpwidgets-private.h header. But I guess it makes
sense that we still need to add it for our internal use at least.
This should fix the CI.
Even when using a GtkListBox, it's just prettier and clearer when having
a text list with dots IMO, especially since some text might wrap on
several lines. Let's just go with that.
The idea is to add some "demo" attribute to a list item inside the
<release> tag, since we already decided that (for now at least) we'd
keep a strict "intro + list" logics, as we did until now.
This demo attribute uses an internal format to specify successive
widgets to blink (like a demo path towards a feature). For now, what it
allows is:
* raise the toolbox, select a tool and blink the tool button.
* raise a dockable, blink any widgets in there.
Now it is still limited and needs to evolve. In particular:
* What happens if the blinked tool button was explicitly removed from
Preferences? Should we re-add it for the demo? And once done, should
we remove it again? Then should we select back the tool previously
selected?
* What happens if the dockable widget is not visible? Should we allow
changing the settings to be able to demo correctly the new/changed
settings? Should it be temporary? If temporary, it can be annoying as
you'd still have to look attentively the demo to find back the path to
the new settings. If not temporary, some people may dislike we touch
their settings.
* What if docks are hidden? Should we unhide them, then hide them back
after demo time?
Also regarding the implementation: originally I wanted to just grab the
demo attribute directly from the AppStream metadata file, but I realized
that appstream-glib cleans out unknown attribute from the XML. I could
then simply parse the file with a generic XML parser, but I found
simpler to pre-parse it into a header built within GIMP. I still use
appstream-glib at runtime as it takes care of localization for us
(though in the same time, we also have the localization in the main po
files, so maybe we could just embed the release note strings as well).
See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
I add it in libgimpwidgets because we need to also use it on propwidgets
created from there, but it's actually only for core GUI usage, so it's
actually in a private part of the library.
Though it's actually doing quite a basic thing, it is nicer and more
foolproof than a manual g_object_set*() everywhere. Moreover it will be
nicer to grep.
… a given order, not at the same time.
This will be used for the release item notifications to show people
where new or changed features are, but in an ordered blink scenario. For
instance: select a tool first, then blink some tool icon, open the tool
options and finally blink the specific new/changed option. I am hoping
it would help awareness of changes (just words on a web news may make
some features a bit foreign when not used to look in details in advanced
options).
… in specific case when there is already a toolbox.
Even if there is already a toolbox in single window mode (hence it needs
neither to be created nor raised, as there is a single window), we still
want to return the dockable widget which can be used for other things.
What it means is that we will be a bit strict over our <release>
formatting which will have to always be a <p> introduction followed by a
list of items. This is what gimp_appstream_to_pango_markups() expects.
Since so far, this is how all our <release> tags were formatted anyway,
this is not too much of a problem.
Note that I keep the less strict gimp_appstream_to_pango_markup() and
use it for extension's appstream description as we will have no control
over these.
The main reason for this new rule and new display of our release notes
is that I am going to add the ability to click independent release items
so that people can get "blinking" indications of what changed when
relevant.
It should help with scrolling the dockable to make the widget visible,
as I don't see a generic and simple scrolling API for GTK scrollable
containers.
In my own testing, it did work if the dockable was already opened. But
if it was just created by the blink API, then giving focus immediately
doesn't properly scroll. I am not really going to investigate now, but
this should be fixed eventually.
This function will help us raise attention to various widgets in
dockables by blinking them similarly to how we blink locks or visibility
icons.
I associate this with the fact that property widgets identifier will be
the property name, so we get identifiers for free when creating widgets
through the propwidgets API.
… on the line art source.
Also now the default tooltip itself will be more appropriate rather than
reusing the "fill-transparent" property blurb (maybe I should have made
this its own property in fact).
This is the same thing as setting the max gap length to 0, except that
it would mean constantly having to play with the gap length and possibly
losing settings you carefully tweaked. Instead with this additional
settings, we hide the gap length settings when automatic closure is
disabled.
Also it makes kind of a nice parallel with the "Manual closure" settings
which can also be enabled/disabled similarly.
Since we can't select a source, the source tools would fail stroking
with an error. It was usable when stroking a path or selection as we
can have the source tool started while running these. Since only one
tool can be started at once, this is not possible when running bucket
fill tool (it would require some logics change on tools).
This change has 2 parts: add an "insensitive" column to
GimpContainerComboBox (allowing to mark some cells as insensitive), then
use this new attribute in the GimpBucketFillOptions to show all source
tools as insensitive.
There are clearly 3 types of settings:
1. How the line art is detected.
2. How do we additionally close line art.
3. How to handle fill borders.
Additionally I am rewording some options:
- "Allow closing lines in selected layer" -> "Manual closure in fill
layer"
- Adding the "Maximum gap length" into an "Automatic closure" frame to
hopefully make a parallel with the "manual" closure settings.
- "Allow completely transparent regions to be filled" -> "Detect opacity
rather than grayscale" (only within the context of the line art bucket
fill) because the main idea of this option is really here that we
detect lines as being opaque pixels, rather than detecting lines are
being dark pixels.
Finally don't hide the manual closure frame when in a configuration
where it won't be taken into account. Only make it insensitive. Having
options disappear is not so nice. Usually you want to gray them out to
have people realize they are simply not always usable.
Currently the option is quite simple. What should happen to make it more
usable:
* Right now, it uses the last stroke options (e.g. as used in a
previously run "Stroke Selection" or "Stroke Path"). We should have
some dedicated GUI in the bucket fill options.
* The bucket fill options GUI should really be redesigned. The more we
add options, the less understandable it is.
* There is a question whether we want to just use whatever brush size is
being set or if we want to have it vary and follow the line art width
(since we have proper distance map, we could use this to tweak the
stroke per-coords).
As usual, this feature was suggested by Aryeom who was still very
saddened that despite all the fancy features in this tool, it is not
able to produce nice rendering. So she proposed that the tool could
stroke the fill region borders.
Many features can only be run on items belonging to an image, and in
particular attached. It makes sense, but in the same time, there are
often some types of processing you'd like to do in background on
temporary items, not visible in GUI, and without any undo steps.
You could work on buffers directly, but sometimes it's also nice to
attach the semantics of the various items, and reuse logics (in
particular class method implementations) already existing. So I am
adding a concept of "hidden items" which is where you'd put items in
some temporary processing state when you don't want them to go anywhere
visible publicly.
For some reason, our flatpak is moving the appstream file elsewhere,
after installation (since all our scripts explicitly install it under
metainfo/).
So in flatpak, it is in /app/share/appdata/ (i.e. $DATADIR/appdata/).
This is not right and should not be done by the flatpak system, but
let's still verify this other location as it is legacy so it would not
be totally impossible that some distributions do something similar when
packaging GIMP.
See also: https://github.com/flatpak/flatpak/issues/4775
As Jacob reports in #6445, on a big-size monitor, the dialog is just too
big, this can be seen in particular with all the space left between info
text. Trying a new logic where I simply leave the dialog to be
allocated, then once I get its size, I generate an image roughly this
same size. This should avoid overly big images.
Thanks to Liam for the fix/feedback on IRC. There was a typo (s/if/it)
and some better wording proposition.
s/You can call if again/You can show it again/
Thinking again, this is simply the version of the config files, mapping
to the application version. Even though it's not really a user-visible
string (except in config files themselves), I find this a much more
elegant name than the ugly "last-run-version" (which is not even true
anymore once startup passed; it's only the last-run version info at very
beginning of the startup process).
This will be used by the update check to verify you are running a new
version since last time. In the future, it might even allow to handle
some types of config migrations if ever we update some things in-between
micro releases. Until now, we could only detect minor updates through
the config folder name (and even this was limited as the config folder
can be specified, in which case we would not even know what version the
files were for).
Maybe we could start also warning in cases of downgrading too, which can
break some configuration files (though there is not much we can do about
it other than warn as there is no time machine!).
Last point: if the new config value "last-run-version" doesn't exist, it
simply means the config folder was run for a GIMP before this point in
time/commit. So we just show the welcome dialog.
MacOS and Wayland need the hotspot in surface coordinates
* X11 needs the hotspot in pixel coordinates (not scaled)
* Windows doesn't handle scaled cursors at all
* Broadway does not appear to support surface cursors at all,
let alone scaled surface cursors.
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/545#note_1388777
We were already avoiding re-processing a same DLL within the same run
(this can happen when 2 dependencies have themselves a common
dependency). But the dll_link.py script was stateless regarding previous
runs so we might be checking again the same DLLs multiple times (even
though we were not copying them again).
Let's make the script stateful with a new parameter to give a file where
all the previously processed DLL names are stored. I am hoping it would
improve the efficiency of the packaging-win32-native which is suddenly
extra slow (it always times out, even after raising the max job time;
now we time out after 2h30! The 64-bit packaging job just takes 1h,
which is too much already, but still much more reasonable).
I'm going to reuse this code in other parts of the file so make it a
utils function.
While doing so, I'm also improving a tiny bit the formatting of lists.
- Adding some people in "documenter" role which is a bit small section,
despite various people improving things: Jacob (he is now gimp-help
maintainer!), Niels (for recent documentation of API), Lloyd and
Akkana (for helping in the devel-docs).
- Fixing "Daniel Novomeský" orthography.
- Adding Lukas Oberhuber (obviously for the recent work on macOS and
more).
- Adding Patrick David (not sure why he was not even there already!).
With all the work on gimp-web, tutorials and providing images, I added
him in "artist documenter" section.
I realized the "recent-contributor" template was checking
`last-active >=2 and minor version >= 8`. Because of the second part of
this test, anyone with a last a last-active value of 3.0 was ironically
not included as recent contributors!
Meanwhile, I am bumping the definition of recent as 2.10 and over
(rather than 2.8 and over), for GIMP 3.0 release. Last thing, I am now
sorting by descending last-active (so contributors in GIMP 3.0 are shown
first).
… %GIMP_TYPE_SPIN_SCALE in gimp_procedure_dialog_get_widget().
The dedicated function is for when a plug-in wants to use a scale range
multiplied by a factor. Otherwise using the generic function is fine.
Gets drawing in the canvas speed on retina displays up to the speed
of FullHD displays on macOS, making 2.99 usable on macOS.
Generic change:
Changes the cursor_label to delay the drawing phase to the idle
queue, from immediate draw on all platforms.
Before the fix in 32049afd (using a deprecated function in Gtk3)
any draws on this label forced a full canvas redraw. This is due
to a quirk in how GtkLabel functions.
The redraw occurred because GtkLabels resize themselves and everything
around them by sending a resize message any time they receive new
text. These resizes then trigger the full canvas resize which triggers
a full canvas redraw that cannot be optimized by either Gtk or Big Sur.
MacOS changes:
Only redraws the cursor position label and each of the horizontal and
vertical rules (cursor tracking widgets) 3 times a second max for a
total of 9 redraws a second (ideally out of 60, though I don't believe
under any circumstances that GIMP achieves a 60fps).
Each of the cursor tracking widgets gets its own timeslice, and so
will not redraw when the other cursor tracking widgets are drawing.
This is required because Big Sur is merging all draw rects into
one large rect, dramatically slowing down draws.
This timeslicing ensures that draw rects are maintained at the smallest
possible size. So the typical redraw is a small rect around the
brush. However, 9 times a second, the rect will include one of the
3 cursor tracking widgets (rulers and cursor label).
Additionally, the code tries to minimize resizing the width of the
cursor label by checking if the widget is too small for the text,
then setting the char_width to a greater size so that resizes won't
be that common.
This improves the appearance of the widget as it no longer
constantly jumps about in size on each cursor move.
Here is a discussion of the issue:
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/572#note_1389445
Reviewer's (Jehan) notes:
* The whole issue about GtkLabel resizing is no more after 32049afd. It
is normal for a widget to request a resize when needed. We just don't
want the statusbar to resize and triggering canvas redraws.
* Changing cursor position text into an idle function generally makes
sense.
Also it reverts commit 6de9ea7022 which had a bug I hadn't realized
when I accepted it: when we test for time, we don't know yet if it
will be the last position change, hence we could "refuse" the last
update. Therefore displayed cursor position would end up outdated
on macOS. This new implementation doesn't have the problem (the last
idle update always happens after the last move).
* The change about giving 1/3 timeslices to side canvas components
(rulers and statusbar) is a complete hack to work around the fact that
macOs doesn't report properly each damaged rectangle. Instead it
returns a huge bounding box. The workaround here is to expose these
area separately.
We have not been able to find a proper solution yet. This is the only
reason why I accept this code, for macOS only, to at least have
something usable there.
See discussions in MRs gimp!572 and gimp-macos-build!86. With these 2
MRs, Lukas reported GIMP 2.99 to perform even better than GIMP 2.10 on
Monterey, though it could not be tested on Big Sur unfortunately.
* Lastly the set_width_chars() thing is also an ugly hack which I will
try later to revisit (see !581). I only accepted it (with mandatory
macOS-only macro) to have an acceptable state for release after seeing
a screencast where the label size indeed "jumps around" on macOS.
… gimp_prop_widget_set_factor() to libgimpwidgets.
Now that GimpSpinScale is in libgimpwidgets, it's time to move the
associated prop too, to make it a prop widget with such a widget easily
creatable by plug-ins.
While doing so, I update both these functions logic, binding properties
together with the g_object_bind_property*() APIs (as we do already in
some other recent prop functions) rather than connecting to signals
ourselves. It makes for much simpler code.
Now the warning is:
WARNING: Invalid fragment for 'Gimp.Config': it should be struct
It implements the [iface@Config] interface and therefore has all its
^~~~~~~~~~~~~~
This warning feels wrong as we use GimpConfig for the name of the
interface, yet in the .gir file, I see `<record name="Config" …>` yet
`<interface name="ConfigInterface" …>`.
I suppose gi-docgen would want us to use [iface@ConfigInterface] if we
want to link the interface. But looking at the gir file, all interesting
interface methods are associated to the Config record. So let's just go
with the [struct@Config] proposed by the warning.
In any case, something feels wrong or broken here, but we need to fix
this for the CI. I hope Niels can look at it at some point.
Fixing these 2 warnings in the CI which end up fatal:
WARNING: Invalid fragment for 'Gimp.Parasite': it should be struct
Serializes the object properties of @config to a [class@Parasite].
^~~~~~~~~~~~~~~~
WARNING: Invalid fragment for 'GLib.MainLoop': it should be struct
it has a GUI and is hanging around in a [class@GLib.MainLoop], it must call
^~~~~~~~~~~~~~~~~~~~~
Basically disabling commit 4f9b7373e6.
After some new patches for GTK3 I wrote, and removing the settings on
NSViewUsesAutomaticLayerBackingStores, Lukas reported that it works like
never before, faster than 2.10 even. Note that this could only be tested
on Monterey, nobody tested on Big Sur with this specific combination
yet.
In any case, we decided to remove this settings and add the new GTK3
patches.
See: https://gitlab.gnome.org/Infrastructure/gimp-macos-build/-/merge_requests/86#note_1384727
The default for color properties (GimpRGB) is now to be editable. So
let's remove the formerly specific call for this.
Also fixing a clashing mnemonics ('c' both for '_Color' and '_Cancel').
Now using the new GimpLabelColor as new default for RGB properties. It
makes more sense that the default is editable widgets. Also it has a
label, which is better default widget.
Also gimp_procedure_dialog_get_color_widget() now only returns
GimpLabelColor widgets.
I was initially considering a second widget, but it makes actually much
more sense to make the editability a property of the GimpLabelColor. It
also mean it can be switched on or off depending on situations.
I tried to have a not too overwhelming API, so we just ask for the label
and initial color at construction. We keep sane defaults for the rest
and let people tweak the result by getting the color area widgets
themselves (if they need to force-showing flat colors or change the drag
buttons in particular).
Another thing I wondered about was the initial size of the color area.
Without a size request or being in some container expanding its
children (which may also be ugly), it ends up too small. I can imagine
such widget being used especially when you want to display several
color rectangles next to each other with a label each. So I just set it
this way. Anyone is free to request a resize after constructing the
object.
Last but not least, the position of the label was especially of interest
here. For my idea of a list of colors, I could definitely imagine color
blocks aligned with vertically-oriented labels above or below. It might
be worth adding an API for this later on.
This would allow to enable, configure or disable drag ability of a
GimpColorArea ater its creation.
I tested that it works correctly in binding. For instance in Python:
> area.enable_drag(0)
> area.enable_drag(Gdk.ModifierType.BUTTON1_MASK |
> Gdk.ModifierType.BUTTON2_MASK)
… correctly disable then reanable the drag with buttons 1 and 2 (in
particular, I wanted to verify there was any reason why the property was
G_PARAM_CONSTRUCT_ONLY. Turns out there was no good reason).
I was interested by such API because having long list of parameters in
various APIs is very annoying. It is much nicer to have simple
constructors with decent defaults and proper API to modify a widget
afterwards in order to cater to special needs.
There were some complaint about the height of these scale.
The min-height was clearly too high. I also made the buttons a bit more
compact by removing a bit of padding.
Finally I add a CSS name to the class, in order to avoid using the
parent class name ("spinbutton"). This makes for clearer and more
customizable themes (ability to style the GimpSpinScale without styling
GtkSpinButton too).
The label was simply completely invisible because of broken progress
computation. Now it is visible at least when the progress fully cover
the label, but a part of the label is not drawn when the progression is
smaller than the label. I still have not figured out how to fix this,
though I am starting to wonder if we should not just drop this 2-color
fancy drawing of the label. Clearly the fact we can't get the exact
progression gadget dimension is biting us.
Another issue I noticed when playing with RTL layout is that when
editing the value, it gets printed on the right side (together with the
label) which gets messy. This is also something to figure out, hoping we
get an API for this on the GTK side.
Also I am setting "auto dir" to FALSE on the Pango layout, making sure
it follows the widget direction, whatsoever. In particular, even if the
contents is not RTL characters, we should keep a RTL layout to avoid
completely broken layout.
The logics to get the progress position is not proper because the text
area (as returned by gtk_entry_get_text_area()) is actually slightly
smaller than the progress area. Unfortunately it doesn't look like there
is an API to get the exact progress area. This commit improves a bit the
situation by starting the progress rectangle when excluding the
intersection of 2 rectangles in pango at the start of the text area (not
at 0).
It's still not perfect as the progress width will be anyway a bit too
small and we don't have the data to compute it properly, but it's better
than it used to be. I also set several variables to double instead of
int to be more accurate, though this part doesn't help much.
Finally I used the ink extents rather than the logical extents. Since we
are here to draw, this is the ink extents which is really needed.
Note: for the bug to be visible, you need to have a different text color
for the progress and non-progress part of the scale.
Also I'm unsure about the right-to-left logics which seems very broken.
There is really nothing specific to the core application, it is quite a
generic widget, so it would be nice for plug-ins to be able to use this
widget.
As I review and tweak various aspects of GIMP UI, I also write down
specifications for these subparts. Here is one for the locks behaviors.
We worked on these specifications with Aryeom and tried to make the most
useful and also somehow obvious logics for these locks, in particular
the cases when applied to layer groups which can have wider ranges of
meaning (on leaf items, it is much simpler). The various previous
commits are implemented based on these specifications.
XCF 17 includes the new visibility locks and the ability to add position
and alpha locks on layer groups.
I am going to push the various commits implementing these different
features together which is why we gather them as a single XCF version.
We want it to work whatever the level in the item tree. We only care
about whether the items are selected or not.
Also fixing the AppStream release tag for the description of this
feature.
Unlike other locks, visibility lock is less useful for locking a whole
hierarchy of item and their children. On the other hand, being able to
lock a group visibility while editing the children visibility is quite
useful.
It can be argued that layer groups can't be painted on, and that's
probably the original reason, but it's really just the same as "Lock
pixels". It is interesting to be able to lock alpha channels on a layer
group to simply lock all its contents alpha channels.
Since we are now allowed to move groups (which is the same thing as
multi-selecting all its children and moving them), it makes no sense
that this lock is disabled.
This works the same way as "Lock pixels" in that a locked grouped also
forbid moving children. And there was already some logics so that you
can't move a layer group if one of it's children is locked. So this lock
really works both ways and is a bit special.
Finally I cleaned up a bit the multi-layer selection logics and
messaging, as well as which lock to blink (similar to the previous
commit) for the "Lock position" case.
In particular, if painting on a layer whose parent's pixels are locked,
we were blinking an empty lock spot, which is confusing. Now
gimp_item_is_content_locked() will also return the proper item (when
relevant, i.e. when returning TRUE) which is locked. It may or may not
the same item as passed in (it may also be a parent item in particular).
Fixes:
> make[3]: *** No rule to make target '64/dialog-question.png', needed
> by 'gimp-core-pixbufs.gresource.xml'. Stop.
It looks like a bug in autotools on Windows because there is no reason
why it would fail. The missing PNG should be caught by the '64/%.png'
rule. Anyway after testing, it fixes the gimp-win(32|64)-native CI jobs.
As Massimo notes, the issue is not about the callback being broken in
bindings, but simply that bindings fail to handle random data without an
associated size. So let's just add the size. I confirmed testing API in
the Python binding that it now works fine.
See discussion in !572, #7840 and #7690. Note that this was reported on
macOS where the consequences were pretty dire, but it actually also
happens on other platforms, at least on Linux too (as confirmed in X11
with the GTK Inspector set to show graphics updates; on Wayland this
debug option doesn't work, but I assume it is the same).
I am not perfectly happy with this change either, because it is based on
part of the API which has various deprecated parts (hence doesn't exist
anymore on the main dev tree, i.e. it might have to be reviewed in GTK4;
of course, it's unsure, maybe the whole resize propagation to parent
containers is just better handled there and the problem won't exist
anymore).
In any case, it is cleaner than the proposition for this part of the
problem in !572 which is problematic (patching GtkLabel with a new API
which won't trigger resize even when actually needed, hence which likely
won't ever get accepted upstream because it's not right).
Let's sync with the proposal in !571 after discussing with Jacob. The
shorter naming is fine and the '-info' suffix feels a bit redundant
anyway. Also since this arg never even existed in GIMP 2.10 (until !571
which is soon to be merged), there is really not even a historical
reason.
NULL is not a proper value for GStrv yet we cannot escape it in the PDB
since we generate default values for non-passed arguments (especially in
interactive case where most procedure arguments aren't set). And for
such boxed type, it will be NULL.
So when we see a NULL GStrv parameter, let's not ignore it (which will
just crash the plug-in). Simply transform it to a GStrv of size 0.
GLib has a specific type of NULL-terminated string arrays:
`G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`.
By using this type, we can avoid having a `GimpStringArray` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GStrv`, we allow other languages to pass on string lists as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with string arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
While we do have quite a few gimp_pdb_run_procedure*() functions now, I
always felt that one based on a config file was missing, even more as we
are getting further and further into using config objects in plug-ins.
In C, the gimp_pdb_run_procedure() function is without a doubt the
easiest one. But such variable arg functions are not available on
bindings, and having to deal with GValue and GimpValueArray is a real
pain.
Also using a config file has the very great advantage that we don't need
to care about order. For instance, if I need to set the 10th argument of
a PDB call (and leave the rest to default values), I don't have to set
all 9 previous arguments. I can set only this one if I want. This
advantage is useful also for C code by the way.
For the record, here is how you could load then export an image with the
"file-png-*" PDB procedures in Python:
> c = Gimp.get_pdb().lookup_procedure('file-png-load').create_config()
> c.set_property('file', Gio.file_new_for_path('/path/sample.png'))
> r = Gimp.get_pdb().run_procedure_config('file-png-load', c)
> d = Gimp.Display.new(r.index(1)) # Give it a display to work on it.
Now exporting:
> img = r.index(1)
> c = Gimp.get_pdb().lookup_procedure('file-png-save').create_config()
> c.set_property('image', img)
> c.set_property('file', Gio.file_new_for_path('/path/exported.png'))
> layers = img.get_layers()
> c.set_property('drawables', Gimp.ObjectArray.new(Gimp.Drawable, layers, False))
> c.set_property('num-drawables', len(layers))
> r = Gimp.get_pdb().run_procedure_config('file-png-save', c)
… object arrays.
We were not supporting duplicating object pspec for no good reason. Well
maybe the reason was that libgimpconfig does not see these types which
are in libgimp. But then the trick is to compare by name.
As for object array, they are present as subtypes of GimpArray specs.
Yet most GimpParamSpec*Array-s are subclass of GimpParamSpecArray but
GimpParamSpecObjectArray are their own GParamSpecBoxed subclass (same as
the Gimp*Array-s are just typedef-s of GimpArray but GimpObjectArray is
its own boxed type).
So I had to move the object array test as its own case to fix support.
Finally do not ignore anymore any type in gimp_config_class_init(). When
we create a GimpConfig, we want to know when a type is not implemented
as parameter (and if it's a well known type, we need to implement it).
Since the parsing failure I was experiencing was normal (not a bug), and
since I was not seeing error being passed down to deserialize(), I
assume this assert was always wrong. I hadn't realize that the GError
object was in fact populated by deserialized through g_scanner_error()
calls which were setting the GError passed at creation of the scanner
through a handler.
So there was indeed a bug in one of the functions called by our
deserialize() implementation. There was one failure case where the error
was just reported with g_warning() instead of g_scanner_error().
Now that it's fixed, I brought back the asserts (previous commits)
because the error object is actually always well populated.
As discussed with mitch on IRC, these asserts make no sense. They can
happen if we fail to parse user-side data. Also currently deserialize()
does not even pass the GError down so we would always assert on failed
parsing.
What must be done instead if change the signature of deserialize() and
all its implementations, with a GError arg. Then this GError will
properly bubble up to the caller for appropriate handling.
MR !565 was only a partial implementation as it was assuming all cursors
had the same hot spot coordinates in the file, which is false more often
than not (since usually it's several sizes for the same image, hence
coordinates move). I should have realized this before merging.
With this new commit, we actually loads the hot spot coordinates per
cursor, stores them as per-layer parasites, then exports with per-cursor
coordinates.
Also it makes the procedure API use int32 array (should be int16 but we
removed the support, now I think it may have been a mistake) which shows
the ugliness of our array support once again with additional size args
per array (even if it's the same size). Also I realize that our support
of arrays with config object is not good. This is also something we'll
have to look at.
… assert the existence of GError.
This is even worse as deserialize() method does not even take a GError
parameter anyway so this assert will always go off when a
deserialization failed (which happened in my case as I was working on a
plug-in API, hence gimp_procedure_config_load_last() actually failed to
load a previous version of the plug-in-settings when I changed a
procedure arg's type).
Just fail the deserialization normally and let the calling code handling
this case. Nevertheless it is kind of useful to bubble-up the error to
calling code, so I add a TODO in the interface header (hopefully to see
and improve this before we release GIMP 3.0).
- Fix return value in error case: s/GObject.Error/GLib.Error/ and anyway
in this form, the error should be a string. Using the easier form
procedure.new_return_values() instead.
- "file-png-load" uses a GFile now (like all load procedures).
There were some comments claiming we don't care about thumbnail creation
errors, only thumbnail saving. It's not true. Thumbnail creation errors
are probably even more important (in this specific usage). For instance,
trying to debug a thumbnail load procedure, I had no clue on the error
even though our system was able to report the issue. It's not cool for
plug-in developers.
Now we will check the thumbnail creation error, write down the error
message on stderr and clear the error for the fallback round (using the
normal file load proc). Then if it errors out again, we will keep this
error as the finale one because it's probably more important if we can't
even open images than the unrelated thumbnail saving error. We will
still return the saving error if the load proc failed without error.
Our Symbolic icon theme comes from the art-libre theme now archived by
the GNOME design team. It had various authors, including originally
Jakub Steiner and Barbara Muraus, then jEsuSdA, Klaus Staedtler,
Alexandre Prokoudine and Aryeom Han. Various other people tweaked the
icons and may have contributed. See the git log for details.
The Color icon theme is more of an original work by Klaus Staedtler, as
I understand it, with some additional icons by Alexandre Prokoudine,
Aryeom Han and other contributors. See the git log for details.
This makes licensing clearer for these specific subsets of the project.
We were getting a critical when selecting multiple drawables (either
changing layer selection while the tool is ON, or starting with multiple
selection). We should not have assert code here, just handle the case
gracefully with a normal error message when trying to fill on several
layers at once.
The line art algorithm is useful but not always accurate enough and
sometimes it can even be counter-productive to fast painters.
A technique of advanced painters which Aryeom uses and teaches when she
wants to close an area without actually closing the line art (i.e. the
non-closed line is a stylistic choice) is to close with a brush the area
on the color layer. It has also a great advantage over the line art
"smart" closing algorithm: you control the brush style and the exact
shape of the closure (therefore something you'd usually have to redo
with a closure made by an algorithm as you would likely not find it
pretty enough).
This new feature takes this technique into account. Basically rather
than relying on the closure algorithm, you would close yourself and the
tool is able to recognize closure pixels by the color proximity with the
fill color.
Final point is that this additional step is made after line art
computation i.e. in particular the target drawable is not added to the
sources for line art logics. This allows to stay fast otherwise the line
art would have to recompute itself after each fill.
This also shows why the previous commit of moving the line art object
was necessary, because a painter would likely want to move regularly
from bucket fill to a brush tool to create area closures and we want to
avoid recomputation every time.
Also adding the CODING_STYLE.md. There is actually the question whether
we still want to track this docs files to package them in the tarballs.
It made sense 20 years ago when devs were working from tarballs, but
nowadays, devs are expected to work from git HEAD.
Anyway this fixes the CI.
… fill tool finalizes.
The idea is that you may want to quickly switch tool to do something and
back to the bucket fill for line art selection. If the input drawable(s)
did not change, the previously computed data is still valid, so let's
hang on the line art object a little longer.
Since we are resetting the input when we get back, we would still
recompute anyway *if needed*, and the line art object does follow
changes on the input pickable so we would not get any deprecated data
anyway. Still we move around ownership a tiny bit to optimize for
common case of tool switching.
In order not to keep forever this data (buffer and distmap in
particular) forever just because one tried the line art once, I add a
timer to free it after a few minutes.
Moreover it will be useful for other cases, such as being able to share
the same line art object with the fuzzy select tool (if we end up adding
the line art option there). In a coming commit, the usage will be even
more obvious for use case where you want to edit the filled area with
other paint tools, then back to bucket fill while not touching the line
art source layer.
Problem appeared on mac and also on debian unstable. This is autotools
only as `--disable-since-check` is present
in meson.build.
Fix suggested by @nielsdg.
```
make[3]: Entering directory '/Users/distiller/.cache/jhbuild/build/gimp/extensions/goat-exercises'
CC goat-exercise-c.o
/Users/distiller/gtk/inst/bin/intltool-merge /Users/distiller/gtk/source/gimp/po-plug-ins org.gimp.extension.goat-exercises.metainfo.xml.in org.gimp.extension.goat-exercises.metainfo.xml -x -u -c ../../po-plug-ins/.intltool-merge-cache
VALAC goat_exercise_vala_vala.stamp
Generating and caching the translation database
CCLD goat-exercise-c
/Users/distiller/gtk/source/gimp/extensions/goat-exercises/goat-exercise-vala.vala:28.10-28.18: error: `Gimp.main' is not available in gimp-3.0 2.99.9. Use gimp-3.0 >= 3.0
return Gimp.main(typeof(Goat), args);
^^^^^^^^^
```
- ps-menurc removed in GIMP 2.7.2 (i.e. stable 2.8.0) according to
NEWS.pre-2-8.
- in our main README, redirect now to devel-docs/README.md as entry
point for contributors.
- move HACKING to devel-docs/ and specialize it into a "how to build
from git and contributed" docs:
* Make it markdown.
* Remove some now obsolete or redundant recommendations (to be fair,
we can probably clean up the file a bit more, but we'll see).
* Add/improve relevant information.
* Make more obvious when you want to build from tarball or git.
* Just keep a single short paragraph about the coding style to
redirect people to the appropriate CODING_STYLE.md file.
* Don't recommend sending patches to the mailing list anymore.
- move CODING_STYLE.md to devel-docs/.
This change reduces to 3.33 times a second, the updates to the
status bar coordinates widget.
This dramatically improves frame rate on macOS retina displays
because it reduces the frequency of full screen updates which
are triggered by this widget updating and are very slow.
This makes the statusbar refresh changes mac only where the
benefit will be felt keenly, rather than saddling all
platforms with the change.
This was added in commit 88f97aedef and only expected to last until
fontconfig had a fix **and** it got into a released version.
This is now done.
I could verify in the git repo that fontconfig's commit 55eb1ef is
included since their tagged release 2.13.95 which is now on MSYS2
(2.13.96 there even), so we will use it for our next release.
Thanks to frogonia (long time no see! \O) for following up on this!
See also fontconfig report:
https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/144
Actually we had half of the fix already with my recent change to source
tools giving the ability to clone from multiple source drawables where I
moved the source drawables from GimpSourceCore to GimpSourceOptions (see
commit 6ad00cdbba). The problem is that gimp_vectors_stroke() is using
the context paint options, but it is creating a brand new paint core
just to stroke the path. Hence with my recent changes, the drawable
sources were finally available to the path stroke, yet not the source
position. So stroking with clone was always starting on position (0, 0)
on the source.
This is now fixed by moving also the position properties "src-x" and
"src-y" on the GimpSourceOptions. This makes this info finally
accessible to the core when running the source tools this way.
Thanks to Eneko Castresana Vara for their initial contribution.
Unfortunately the code had diverged too much for it to be usable because
of our much too late review so a different fix had to be done.
As the name implies, this is an action to toggle the paint dynamics ON
and OFF which can be a huge time saver when painting and needing to
switch between dynamics and non-dynamics painting.
I have not been adding this action in the "dynamics-action" group
because these are only used for the dynamics dockable menu. Also it
looks like the context actions are not visible in the action search (I
can't recall why, but I think there was a reason), yet you can still set
a shortcut.
Should we create a new "paint-action" group maybe?
Fixes #4333
If the checkbox is unchecked: dynamics falls back to "Dynamics Off",
the current dynamics name and its options are hidden in the UI.
If the checkbox is checked: dynamics is set to previously used one
or the default one, all dynamics options are seen in the UI.
Relative to the MR !553 where I could verify that the function
gimp_tool_push_status() does not just push new messages, it also removes
any other message from the same context (and place the new one on
front, unlike gimp_tool_replace_status()).
Therefore calling gimp_tool_pop_status() before a push or replace is
simply wrong with undesirable effect (e.g. too many useless redraws,
which can be pretty bad on some platforms like macOS, but are not ideal
anyway as a general rule).
This change reduces redraws due to spurious status updates.
Before this change, the status would be unset, then set again to the
same value it was previously. Each turn around setting and unsetting
causes a redraw.
On macOS this redraw causes a full screen redraw. With this
optimization, when the status message is unchanged, no redraw occurs.
This is because `gimp_tool_push_status` checks to see if the message
has changed.
This is a better fix for the previously reverted commit, avoiding
"floating-selection-changed" and "select-items" to recursively calling
each other.
The other fix on context update is similar and was also triggering
crashes because of recursive signal calling after the previous revert.
Using the "list-add" icon instead of "document-save" indeed makes more
sense for the button to store a layer set.
Also renaming "Named Selection" to "New layer set's name", which should
hopefully be less confusing. In particular, we keep consistency with the
"No layer set stored" label (naming the concept "layer set" both times).
And it should be clearer that it is a field to write down a name for
creating a new layer set.
My commit ca28934dfc was very wrong. We absolutely need to set context
in list view editors too. In particular, we could not loop through fonts
in the Fonts dockable very quickly with up/down arrow keys anymore
(since the GimpFontFactoryView is a GimpContainerEditor).
When doing this though, we could have some weird crash in the
GimpContainerPopup watching for context change through button
press/release. Indeed when doing this, simply opening the popup (for
instance clicking on the Fonts icon in text tool options) would trigger
a context change as a button click consequence.
The solution is obviously to check which widget the button event belongs
to and ignore it if it happened on any other widget than the popup.
Makes more sense and I am trying to make the devel-docs more readable
(which includes less crowded, especially with scripts which are not
really docs).
I was wondering what this version file was for. After some git
archeology, turns out this was used for gtk-docs. Since we replaced
gtk-docs with gi-docgen in commit 92e80d12e8, this can be removed as
well.
Though the Color and Symbolic icon themes will have a different build
process and naming scheme for their icons, the base list is meant to be
the same by maintenance principle. So I am moving out the lists to the
icons/ directory's meson file.
Bumping meson requirement to 0.53.0 because I need to ability to use a
variable as dictionary key (not only string literals), which appeared in
this version. Meson 0.53.0 was released 2020-01-07 and seem to be used
in any stable distribution released since 2020. In any case, it seems
widespread enough to bump it now for our dev branch.
Rust dependencies are not really making everyone happy apparently. We
don't want to make SVG support optional anymore because it is too
important, and unfortunately there doesn't seem to be any suitable
replacement SVG libs so far (or we haven't found them).
We explain this in the INSTALL file and also explain a bit how to bypass
the SVG parts for packagers really needing to do so, allowing GIMP to be
as portable as possible.
See also issue #6821.
Ok that was a bit of a mess with the 4 build cases (combinations of
meson, autotools, vector and raster icons). I *think* this is now OK.
Basically we still need to build the colorsvg2png tool even when
installing vector icons, just for the purpose of the 2 icons
dialog-question and gimp-wilber-eek which we compile into GLib resources
from PNG images.
Also it looks like I completely forgot to add the subdir meson.build in
icons/Color/.
Even though we only generate makefiles, we actually want to make meson
aware of the list change because it continues using the file list from
the previous configuration. We do this by "touching" the meson.build
files, i.e. editing their access time.
Also rebuild the icon-list as there are small changes forgotten.
Now the source images are in the build dirs.
Also:
- clean the EXTRA_DIST contents on autotools;
- add dependencies rules in meson gresources to make sure icons are
built before resource build;
- finally remove a duplicate build rule in Color Makefile.
Bad usage of `find`. I didn't pay attention that I removed icons from
the Legacy icon theme which is frozen. Obviously the previous commit was
only expecting to touch Color and Symbolic icon themes.
- Remove some forgotten lines related to 24x24 vector icons which were
removed a few days ago already.
- Don't install the 64x64 icons anymore as PNG when in the vector icon
case. Not sure why we ever did this, but it doesn't look useful.
- This should also fix the CI which was not looking for the tool
gtk-encode-symbolic-svg in vector icon install.
Some points to note:
- gimp-web and gimp-toilet-paper had some usage elsewhere so I also left
them in 2 of the more generic size files.
- I remove gimp-floppy altogether as it's used nowhere in any of our
code or data files.
There are some clear and obvious groups in the icons. For instance, the
Preferences icons are one of them. Looking up the code, we only use them
in 16px (in Preferences side menu) and 48px (in Preferences page
headers). Until now, we were storing in other unrelated size (22px) and
also the lists per-sizes were not consistent. Some icons were missing
here, other there.
With this new organization, the Preferences icons are listed in a single
file, ensuring usage and contents consistency. Also it allows to install
them only for the needed sizes (note that it is possible that they might
be needed in different size, for instance with custom themes; but we
can't just randomly distribute icons in all sizes; or to be more
accurate, this is exactly why we encourage rather the SVG/scalable
icons, so if some people explicitly go for raster icons, they also get
the drawbacks which come with).
Last note: it may be possible that some icons end up in different
"semantic" icon group. This is not a problem with this new organization
as my scripts handle duplicates gracefully.
Build-time tool, which basically just rasterize SVG images (it doesn't
do anything special like gtk-encode-symbolic-svg which creates special
PNG for GTK to recolor them).
It looks like I had this prepared since 2018 according to file header,
but I just never finished doing it! :P
Basically now PNG icons of the Color icon themes do not need anymore to
be committed in the repository. They will be generated from the SVG
icons.
Also adding a missing icon from the 16px list (the Playground icon for
Preferences dialog was needed in 16x16 as well, yet missing).
It may actually be meaningful to have redundant vector icons at specific
size, for instance when you want sligthly different designs (e.g. more
details at bigger size). But here looking at our 24x24 vector icons, it
doesn't look like it at all. It's mostly the exact same icons,
duplicated (with some forgotten).
Makes no sense here. So let's simply install the scalable/ icons for all
size, and that's it.
Since this is probably much less tested than the default vector icon
case, any bug there might go unseen for some time. So let's add a new
pipeline to check this. I make so this pipeline is not actually run on
every commit (i.e. manually only), then I'll just add a scheduled
pipeline to check the non-vector icon case at regular intervals.
This pipeline also test the icon-list.mk files are not outdated.
Just so that someone who happens to look in there is not tempted to
modify these files directly and get some instructions.
The comment is inspired from other similarly generated Makefile.am (i.e.
in plug-ins/commons/).
The lists are still exactly the same (except for one icon file whose
name the script fixed, which proves its usage/need even starting this
initial commit).
Now we also get more consistent tabbing than the manual one. Only
missing thing is that it was nice to separate some icons by categories
for easy reading. Maybe later.
… listing.
This way, both the Color and Symbolic icon themes, both on meson and
autotools build systems all share the exact same list of icons.
I think there are still improvements to be done on what we list and
chosen sizes and icon categories. But this step is about just getting on
the same state as we currently are, simply with shared listings. Once we
are there, we can go forward.
I realize that this module is available since meson 0.53.0 though our
current requirement is meson 0.50.0.
Note sure why meson was not popping any warning (normally it does when
we use a feature younger than the minimum requirement; but maybe this
doesn't work for modules).
Anyway this does the same thing without the 'fs' module, and maybe even
better (we know which icons should be converted or used from source, no
need to add any test logics here).
Now we get back (slowly) to something a bit saner, with a common list
shared on both icon themes. This way, we make sure we won't miss any
icon when we will add/remove/change any icon.
This is only for the meson build right now, but next step is to use the
same list in the autotools build as well. This will get maximum
consistency across build systems.
The whole logics of creating specially prepared PNG images for vector
icons (with gtk-encode-symbolic-svg) was absent. This option was
basically completely broken, yet we now know that we need the ability to
install PNG alternatives for the icons (see #6821).
This is a continuation of previous commit which is straightening a bit
our whole icon theme builds. Note though that more needs to be done
because I definitely still see room for more mess and far too much
duplication.
Some icons were missing on one side or another side, though mostly on
the meson build. Also the option -Dvec-icons=false was basically
completely broken and clearly untested, most likely ever since the
original meson build contribution.
This commit doesn't even completely fix the non-vector icon rule,
because even the file names are wrong, and the bitmap icons are not even
constructed from their vector counterpart! I am going to fix this in the
next commit.
Currently it's a mandatory option (and it has been the case for years,
ever since commit 43e218859b) so let's update the info.
Note that there are still discussions going on about this dependency and
it being hard or impossible to build on many platforms (which are stuck
on old C version, before the move to Rust). See #6821.
We'll see how it goes.
This includes:
- "copy-icon" set
- Permission and cleanup rules updated
- Exiv2 bumped to 0.27.5
- Adding an x-checker-data for OpenEXR
- Poppler bumped to 22.01.00
- OpenBlas bumped to 0.3.19
- graphviz bumped to 2.50.0
We should really get back to a single shared list as we have in
gimp-2-10.
Also just keeping the "no SVG icons" option feels wrong to me, yet it
turns out librsvg is quite a problem because of Rust, so recent versions
are just not available on many platforms (see #6821). This is what
blocked me so far to remove this whole listing of PNG variants for our
vector icon themes. Otherwise they would be gone by now.
I really wonder as well about all these size categories. Not that they
are not needed when in PNG format, but because it feels like nobody has
really taken the time to list which icons are needed in which size for
years. We really need to do some cleaning in this area.
This moves to standard fullscreen behavior for Gimp.
Added benefit is that it no longer requires gdkquartz-cocoa-access.h
which the Gtk team wish to stop supporting https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4303.
Bug 756178 also no longer manifests, cdc7542d46
so it is now safe to do.
Finally, removes dependency on objective c in the app/display directory.
Since I removed some files and forgot to change these rules. Though I
actually wonder if this still makes sense to distribute all these files
within the tarball anymore. It made sense in the way software was
distributed 20 years ago, but nowadays people who want to develop would
clone the git repo not get a tarball. We'll see.
This change makes sure that plugins can load when gimp is built with
meson. This is because .typelibs and .gir files do not have full library
paths when build using meson (this is different from autotools).
Add some more text and links to existing documents.
I also remove 3 files which are now either outdated or whose contents is
also written (with more or less similar text) in other more up-to-date
files.
Add more links to other files after I reviewed they were still relevant.
The `gitlab-milestones.txt` in particular had to be updated because the
contents was outdated (though we still need to manage milestones, simply
now we are a bit more fine-grained).
Loosely based on the old structure.xml, except it was widely outdated.
So I removed or updated what was obsolete and added missing folders.
Obviously getting rid of the old `structure.xml` (now we have easier doc
generation through Gitlab).
Finally, I fix the table of contents and replaced the title with some
metadata-style stuff which Gitlab docs suggest (otherwise the document
title ends up in the table of contents, which is a bit silly).
Sometimes we want to make quick tests on old versions of GIMP.
Rebuilding from source is definitely still an option, yet with flatpak,
we have many past builds available easily to us (at time of writing: 19
stable builds, 12 dev point-release builds and at least 3 nightlies —
though I seem to have issues with signatures on gnome-nightly right now,
so maybe there are more!).
There are some command lines needed to check the build history, then to
install a specific build, which I explained in developer docs (see
devel-docs/debugging-tips.txt, section "Testing older GIMP versions").
Yet it's clearly cumbersome and slow so I wrote this script today to
automatize the process a bit.
Running simply this command will list all available releases on the
Flathub repository (adding --beta or --nightly will list the development
releases and nightly builds instead):
$ tools/flatpak-releases
The listing will contain a topic describing the build as well as the
date, all this prefixed by a number. For instance, this is an excerpt of
the output for the dev releases:
$ tools/flatpak-releases --beta
0: Update dependencies (127a0fa7) [2022-01-13 16:59:43 +0000]
1: Issue #106: File->Create->From Screenshot not working. (9c831b14) [2021-12-14 21:46:52 +0000]
2: Release GIMP 2.99.8. (908bf5b0) [2021-10-20 20:29:00 +0000]
3: Release GIMP 2.99.6. (e04355dd) [2021-04-26 14:08:32 +0000]
…
The last build updates dependencies, the previous one fixes some
specific issue and the 2 previous ones are point releases.
Now say I needed to test/compare some behavior with how it was in 2.99.6
(e.g. to verify a regression), I would then run:
$ tools/flatpak-releases --beta -3
This would install this specific dev build number 3. In just 2
easy-to-remember commands and a few seconds, we can therefore list and
install specific Flatpak builds.
This will be the root page for the developer documentation. Note that
there are other files in this directory (old `README` included) which
will need to be deleted but I don't do it just yet on purpose until I
checked them and integrate anything which could be of interest back into
the new documentation.
There are still deprecations going around but for GExiv2 0.14.0 so we
can't change these yet.
Note also that I try a slightly different approach as I don't set a
GError for well-known tags as there is no reason these fail. I only add
a GError when we construct tags or similar calls.
Last deprecated usages in this file. Actually there are a few other
calls but deprecated on GExiv2 0.14.0, hence over our current
requirement. So we'll have to handle these later.
Replace functions gexiv2_metadata_set_xmp_tag_struct() and
gexiv2_metadata_get_tag_type() with their _try_ variants.
Note that I print to stderr rather than raising a warning here as I am
quite unsure where the list of XMP metadata we are gathering comes from.
Is it fully validated by GExiv2, and therefore no errors are ever
supposed to happen? (in such case, we should raise a warning if it does)
Or is it user-provided data (e.g. from a file loaded in GIMP which can
contain broken metadata)? In such a case, we should probably handle the
error slightly differently to warn for non-processable data (hence
possibly metadata loss at export time).
For the time being, then go with this weak handling and take care of
this better when we can look further into this.
… gexiv2_metadata_try_set_tag_string().
These are usage where we have full control over tag names and values so
no error is supposed to happen. This is why we use them as code warnings
and not returned error (because if an error did happen, this would be a
bug rather than a user error or a system error).
Here are the changes:
- Separate the check for comment contents and the one of whether or not
it starts with "charset=Ascii ". Indeed in my tests, we still want to
handle the empty string case or the "binary comment" case even without
the charset prefix (currently it was both or none, so I encountered
cases with a broken "binary comment" comment because the charset
prefix was absent).
- Add some #warning in order not to forget to remove the bogus "binary
comment" test. Indeed after some digging in Exiv2 code, I could
confirm this return value got removed in commit 9b510858 of Exiv2
repository, i.e. since Exiv2 0.27.4. Now in my test case where I had a
tag containing only 0s, Exiv2 returns an empty string, which is
perfectly fine (and it's up to us to keep or ignore it).
- Use gexiv2_metadata_try_get_tag_interpreted_string() instead of their
deprecate non-try counterparses. Right now, I am just outputting any
error message to stderr, as I'm not sure if this is the kind of errors
we want to warn people about. I guess it would depend on which type of
errors exactly are returned, so let's see if we encounter some case in
the future. For now stderr is fine to detect these.
GimpColorRenderingIntent and BablIccIntent are actually 1-on-1
equivalent (for the common base values), but it's better anyway to call
with the right type. Also fixes this warning:
> libgimpcolor/gimpcolortransform.c:215:53: warning: implicit conversion
> from 'enum <anonymous>' to 'GimpColorRenderingIntent'
> [-Wenum-conversion]
- Align macro values.
- Align backslashes to escape newlines.
- Added explicit PointerAlignment though this one seems unneeded.
- Increase the column limit (even though 80 is really the official one)
and add some penalty on breaking on very unexpected places, such as
around assignments or on first parameters in calls/declaration. We
want short lines but this is more of a soft rule which should not
override sensible line breaking rules.
- Group some rules and reorder rule names alphabetically within groups.
It looks like origin is the same as mr-origin when the contributor
pushes to one's branch. But when a reviewer rebases through the Gitlab
"Rebase" button on web GUI, I got a fatal error:
> fatal: ambiguous argument 'origin/asalle/use-dynamics-flag': unknown
revision or path not in the working tree.
Possibly `origin` is then the remote of the person who rebased (it would
be weird, yet it's a fact the branch is not found). Let's go with this
assumption.
Fixes #950
`.gitlab/search-common-ancestor.sh`'s original authors are
Philip Withnall and Frederic Martinsons.
(Jehan/reviewer's note: script further improved by Asalle)
- Add recommendations on whether to break MRs into 1 or more commits.
- Add style for one-line struct initialization.
- Protect some texts in backticks' markdown syntax.
This is the same issue as with IM000001.dcm mentioned in issue #313.
There are two problems: incorrect endian conversion for 16 bits per pixel,
and not handling photometric interpretation "MONOCHROME1", which means
minimum value is white instead of black.
The endian conversion was fixed as suggested in issue #313.
For "MONOCHROME1" we added a variable bw_inverted and we invert the pixel
value if that variable is true.
Exporting an image to TGA fails with a crash when it's an indexed image
with alpha channel. We were not taking into account that even though
the output is 1 byte per pixel, the input should allocate memory for
2 bytes per pixel (1 color index and 1 alpha channel).
Also improving a bit the download script by specifying the .isl or .islu
file extension. It's nicer than trying to download randomly, and also it
allows to better compare the list of downloaded files with the list in
gimp3264.iss script.
My previous command was also adding a linefeed just after the BOM. While
I'm not sure it would really break anything for processing these, it's
anyway much more correct to only add the 3 BOM bytes. So here is the
improved command.
Also some language files are supposed to be UTF-8 yet they are missing
the BOM markup (only method to recognize them for InnoSetup). This is
the case for Chinese Traditional. See issue #7676.
Make sure that this lang file has a BOM.
Due to recent changes on master the linked layers concept doesn't exist
anymore. The conversion code checks whether all linked layers are valid.
However, text layers need special handling.
In the past updating the linked_layers wasn't needed when the layer pointer
of a text layer was changed. Now, that has changed because we parse that
list for valid layers. To fix this we update linked_layers in the same
way as already was done for selected_layers.
yocto/oe is capable of building gobject introspection despite cross-compiling.
add an option to enable gir build even if cross-compiling
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Reviewer note (Jehan): this whole stuff is a mess. Actually I'd like to
simply get rid of the whole no-gir-when-cross-compiling logics but I
still can't figure out how to cross-build generically with GIR.
Yet since some manage it with yocto, let's unblock them.
See #7208.
There is no change for lossless images, where import precision
is directly related to bits_per_sample.
However, according JXL developers, for lossy images
(which generally use XYB color space), decoded data are not tightly
bound to bits_per_sample from header, import in 32bit
float precision can be used for better import quality
(libjxl works internally in 32bit float precision).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
