Resolves #15001
In the MyPaint Brushes v2 port (ea8b9dc1),
I implemented a cursor_update () function from the
parent class. However, I did not call the parent's
version of the function afterwards, so the MyPaint
Brush cursor was not being redrawn. This patch
adds the call to fix the cursor display issue.
Our build files were relying 'sysroot' to find gexiv2.h but this is
not possible with Apple Clang om which sysroot points to macOS SDK.
So, exotic environments like Homebrew were failing. Let's fix this.
The Filter Tool is a "hidden" tool that we switch to
when applying a filter. Like other tools, it commits when
we save our image. However, we may no longer have an
active filter in the tool when we do so (like, after applying
an NDE filter). Because we check the drawable from the
filter to confirm whether we should force NDE or not,
this can cause a CRITICAL when we try to access a now
non-existent filter.
This patch extends the "if (filter_tool->filter)" check to
cover the full commit check process, to prevent the bug.
Resolves #14993
We currently prevent paint tools from painting on
link or vector layers. However, we had not added this
protection to the bucket fill tool. This patch copies over
the relevant if statements to prevent this.
- Interactively query the release version from standard input.
- Compute the logical previous version but also the previous release in
time. For instance the logical previous release of GIMP 3.0.6 will be
3.0.4 but the time-wise previous release will be 3.1.4.
- Some statistics will use the logical previous release whereas others
the time-wise one.
We should not call archive_entry_free() since man
archive_read_next_header explicitly says that the returned entry is an
internal object:
> This is a convenience wrapper around archive_read_next_header2() that
> reuses an internal struct archive_entry object for each request.
The only reason why it was not crashing is that we were not properly
freeing the archive itself so internal objects were hanging! The man
archive_read says:
> Once you have finished reading data from the archive, you should call
> archive_read_close() to close the archive, then call archive_read_free()
> to release all resources, including all memory allocated by the library.
Therefore this code add archive_read_free() at the end and removes
archive_entry_free().
Furthermore we now verify if the zip archive contains any other file.
Unlike all other compression formats we were supporting until now, zip
is a full multi-file container format and we are always only trying to
read the first file listed in the archive. This likely means that this
file was not meant to be opened this way. In any case, still try to load
the first file as an image, yet raise a warning about the existence of
more files in the archive.
- Uppercase first letter of blurbs.
- Make the blurb and documentation strings localizable and localized.
- Add the compression format extension to the list of extensions. I am
unsure why it was set as FIXME, because it does work perfectly (per
tests) as a generic (de)compressor plug-in for any of the image
formats we support. Not even this, but I am even putting the generic
extension first, because sometimes we take the first listed extension
of a load procedure to determine the source file format. Yet the only
thing we can say *generically* about a file loaded by these procedures
is that it was compressed with the associated container format!
- For the new zip-support, do not show xcf.zip and xcfzip extensions in
the list. I don't think we want to promote these new extensions as
standard XCF variants, even though in practice this will still work
fine. Instead add hgt.zip (but again, after the generic zip, cf.
previous point), because we know that this is a commonly used format
combination for HGT files.
When exporting formats that use image procedures
(like PNG), if we don't remove the layer offsets then
the image is cut off on export. This is because we
size the image to the layer size, but then the layer offsets
move it off the canvas. This patch fixes the issue for
ORA export.
This patch adds support for decompressing .zip files and
loading an image within. This allows us to load zipped
images like hgt.zip and other compressed formats.
This fixes 46d9a09698. There was a reason why this was not implemented
as an assert-type error nor as a user-facing error: network problems
happen.
We cannot pop an error up every time:
* The computer is offline! 😱 GIMP is not made to be run as a connected
software and working on GIMP with a non-connected computer is a
perfectly valid way of using GIMP.
* gimp.org is down (it's rare, but it happens and it should not have any
impact to creators with GIMP).
* You are behind some kind of proxy or other complicated network
configuration which GIO is not able to pass through.
* And any other reason which could make your GIMP not able to read the
remote json file…
Instead let's check the more particular domain and error code, though
even this I hesitated between doing this change or simply reverting
commit 46d9a09698.
Indeed it's still quite a generic G_IO_ERROR_NOT_SUPPORTED error, so I
do hope we cannot get it in other normal conditions where reading a
remote link may fail. The last thing we want is GIMP popping up errors
which are neither bugs in our code, nor environment issues for which
anyone can do anything about.
Soon we will officially support .hgt.zip files (see !2483) but in fact,
even without this, the file-compressor actually support any other
formats we support, compressed into one of the container formats
supported by this plug-in.
This fixes such error message:
> gimp_image_set_file: failure to set file 'file:///home/jehan/Documents/gimp-splash-deleteme.png.gz' with extension 'gz'. The extension must be '.xcf' (or a compressed variant).
… gimp_file_load().
We make sure that the load procedure associated to the file is the one
used for the inner-file (in case of imbricated files into container
formats).
Also let's set the imported file unless it's a XCF inner format.
… determine if a file is XCF.
This was kinda already working for files loaded through the GUI. Yet the
code in file_open_file_proc_is_import() was assuming a file loaded
through the file-compressor plug-in is necessarily XCF.
Even though it is the original use, the code in file-compressor is
actually generic and is able to load any supported format additionally
compressed with gz, bz2 or xz.
Furthermore, we will soon support zip-ped imaged, explicitly to support
the format .hgt.zip which is quite common (see !2483). So remove any
logic of a file loaded by file-compressor as meaning it's a compressed
XCF.
Users were thinking the tutorials are some kind of official docs,
but they are not maintained as the official GIMP help website,
they are more like informal documentation about GIMP made public.
Let's clarify this reordering the buttons.
It was announced by the devs on Google Groups that they are on preview state.
I will need time to conform our scripts to the upcoming 6.6.0.
So, let's not risk creating installers with broken UI.
This reverts commit bc095d5c83.
Sandboxing XDG_DATA_DIRS, while can fix the crash due to share/mime,
on the other hand makes impossible to call share/applications
associated with such mimes on host.
So, since we bumped the AppImage to Debian Trixie so the Glib
crash due to mime is gone, we can (and should) revert the
wrong sandboxing without problems.
Fixes: #13001#13106#13492#13647#14779
AppImage jobs are now built with Trixie to adress #13001 and many others.
To have two Debian versions with less complexity possible, I needed to:
- Revert the prevalence of the AppImage CI (now nonreloc comes first);
- Revert the use of Clang on Debian (also to save 120MB from registry,
since we now have 4 Docker images, each one with its own STEP cache!).
In short, .gitlab-ci.yml will look more like before I changing it a lot.
Closes #13553
Such issue tends to affect only AppImage users (e.g. when running it in
KDE installations). This is because AppImage files are not ran by
any host helper (e.g. snapd or flatpak) to connect to GVFSd and is
not possible to bundle GVFSd due to its own nature (it is daemon).
Since GVFS is listed in the INSTALL file as a required dependency, it is
fair enough to be more clear when it is not present, otherwise users will
have outdated GIMP without knowing (like happened in macOS in the past).
We are already doing this with GIMP help plug-in by the way. The
difference is that, at GIMP start, such techinical error message can
be surprising, but even so it is needed as feedback for fail on the
update check button in the end of day. Let's follow GIMP help on this.
This patch connects the gimp_color_hex_entry_events ()
function to "key-release-event" and adjusts the code
to update valid colors as you type. Pressing Enter
will work as before, converting back to the last valid
color if an invalid one is typed.
The rgba variable would be used uninitialized. This needs to be moved
one loop level up so that the color extracted at each cell start
position is properly reused (and also so that the full transparent color
at no-entry position is properly set and reused too).
I think most, if not all, failure cases of file_open_with_proc_and_display()
should allocate a GError by now. But just in case we missed some edge
case, better not crash.
For instance, we were crashing when opening a remote file because of
this line before the previous commit was pushed.
As discussed with NikcDC, this will be useful, for instance for the SVG
export to know the mime type of the linked file. If not PNG, JPG or SVG,
we may want to output a small warning that some viewers may not be able
to read such files, since the SVG spec makes the support of these 3
formats only as mandatory.
… PDB API which will return a newly allocated GFile.
Though gimp_temp_file() was so far the only such case where a returned
GFile was being leaked, it may happen again. So the PDB must instead
assume that all returned GFile-s have their own reference and take over
said reference.
And therefore update all other functions to increase the internal
GFile-s reference counts.
While 20min is being enough, the jobs are completing
too close of the due time (due to awful runners like
OSU or Win32 stuckness). Let's prevent failures, then.
When running `ninja gimp30-windows-installer-pot`, we had this error:
```
[0/2] Running external command gimp30-windows-installer-pot
/usr/bin/xgettext: warning: ITS rule file 'gimp-ms-installer-config.its' does not exist; check your gettext installation
/usr/bin/xgettext: warning: file 'build/windows/installer/lang/setup.isl.xml.in' extension 'xml' is unknown; will try C
```
While there are cases when you want to edit the mask straight away (this is
often the case when starting with a white or black mask), in many other cases,
the mask may be already as you want it per its initialization (e.g. when
initializing with a channel, selection, the alpha channel, etc.).
Until now, the Add Mask dialog was always switching to the "Edit Layer Mask"
mode by default, which forced an additional unneeded click each time you created
a mask (and were in a case where you initialize the mask as you want it
directly).
Now adding "Edit mask immediately" feature in the "Add Layer Mask dialog":
* It's checked by default to keep historical behavior.
* As most other dialogs, the last value is remembered, allowing people with
repetitive workflow not to have to repeatedly set the settings each and every
time.
* This default is also visible and settable in Preferences > Interface > Dialog
Defaults.
When quitting the application using "Quit" from the dock's right-click menu,
GIMP does not follow our standard quit procedure. Instead, macOS forces the
application to close, which may result in losing unsaved changes.
By adding a delegate that intercepts the applicationShouldTerminate call,
we ensure our quit code is used, preventing macOS from handling the shutdown
directly.
Change of series must always have their own splash image (which will
stay the same within the whole series).
Development releases though will have a new splash image most of the
time (but it is not mandatory).
See rule edicted in commit Infrastructure/gimp-web-devel@061f544.
hb_ft_font_lock_face() (and unlock) exists since harfbuzz 2.6.5 and our
current requirement for this dependency is 2.8.2.
Fixes this compilation warning:
> app/text/gimpfont.c:1196:3: warning: ‘hb_ft_font_get_face’ is deprecated: Use 'hb_ft_font_get_ft_face' instead [-Wdeprecated-declarations]
> 1196 | face = hb_ft_font_get_face (hb_font);
Fixes following warning, seen on CI:
> ./app/dialogs/about-dialog.c:549:7: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
This is the recommended fix from Gtk to use our own mime type rather than depend on a mimetype
that has a different expectation of payload.
This means drag and drop of colors uses `application/x-geglcolor` rather than `application/x-color` which expects an RGBA color rather than a structure.
Resolves #14932
In Small Tiles, we update the preview whenever
the number of segments slider is dragged. However,
while we reacted to the slider moving, we actually grab
the number from the GimpProcedureConfig object.
As a result, there's a lag between the signal firing and the
config object updating, so we don't grab the latest change.
This patch alters the signal to run when "notify::num-tiles"
is called, resulting in the update function having the updated
number.
The bug in old Bugzilla #138357 report was happening on icc on ia64 with
-no-gcc option. It does look like after all these years, this is still a
GCC attribute, but we use the same attributes on babl and GEGL code. So
to be fair, it'd be useless to only forbid using it on GIMP code. And
that makes for much less ugly code.
Note that C11 has _Alignas() and C23 alignas() specifiers. These are
standard, but we are typically still more into C99 code. Let's see if we
move on to C11 some day… But for now, let's use __attribute__.
Also I am unsure how much this issue is still relevant nowadays. Maybe
even without specified alignment, it would now work fine with icc on
IA-64. 🤷
Or maybe it really doesn't matter that much because Itanium has been
discontinued in 2019, though I guess existing hardware will still be
around for a bit longer.
Per Martin Owens of Inkscape and Jonathan Watt,
one of the SVG specification editors
(https://jwatt.org/svg/authoring/#doctype-declaration),
we should not export the DTD with the GimpPath SVG.
This patch also adds an explicit SVG version to the
<svg> tag.
This patch adds additional API for setting the stroke/fill
properties of vector layers. You can now set/get color, stroke
width and stroke style via the PDB. Pattern get/set API is not
yet implemented.
This patch also updates a missing parameter check for GimpVectorLayer
in gimp_config_param_spec_duplicate (), and adds additional API
in /app to make it easier to safely retrieve GimpVectorLayerOptions.
This happened to our artist in residency. She had a crash when
gimp_image_pick_layer() was apparently run with a non-NULL yet invalid
previously_picked layer. So let's make sure that we clear the stored
item pointer when the object gets finalized.
I discover GLIB_VERSION_MIN_REQUIRED and GLIB_VERSION_MAX_ALLOWED. The
former will make so that we won't have deprecation warnings anymore if
ever we use a function which has been deprecated recently (as long as it
was not deprecated at the minimum required version). The latter will
make so that we get deprecation warnings for any function added after
the minimum required version.
Note that ideally both should be at the same version, but since we have
a bunch of GLIB_CHECK_VERSION() protected conditional code, we would get
compilation warnings even on correctly protected code. So just keep the
small discrepancy until we can finally bump our minimum requirement.
Also add the equivalent macros for GTK/GDK.
This really feels like internal API which we'd want to keep private (and
used by core plug-ins only).
Also as Jacob noticed, it's not even included in libgimpbase/gimpbase.h
so plug-ins wishing to use this API need to include this file
specifically anyway (but the header is still installed and the API is
introspected).
Since we cannot remove these functions now that GIMP 3 was published,
for API stability, I am only deprecating them both in the C API with
macros and in the bindings with GObject Introspection annotations.
Therefore any third-party plug-in developer trying to use these
functions in a plug-in will get build-time or run-time warnings.
Then when we'll move on to GIMP 4 development, we can remove the
deprecation and simply make this file private-only use instead.
This was simply caused by two variables having been swapped.
Gimp 2 used to work properly because there were two separate mix-ups that
cancelled each other: one in the function arguments, and one in the code
itself. Gimp 3 had fixed the error in the arguments, but not in the code,
thus enabling the bug.
GIMP supports importing a number of palette formats
such as Adobe Swatch Exchange and SwatchBooker.
However, this is not immediately apparent from the import
palette dialogue.
This patch adds the currently supported palette formats as
filters in the dialogue, both to let users hide irrelevant files from
view and to highlight which formats we support.
This patch fixes a few (mostly Windows-specific) warnings on build.
* Hides functions like gimp_get_foreign_window () and variables
like transient_set that aren't used in Windows.
* Changes hollow_g_shell_quote () to not return a const gchar *,
since the value it returns is actually not const.
* Cast update_interval to double to remove warning about mixing
enums and doubles in division.
Closes: #14796
There is no other doable option than Buildah. I also tested the
other Kaniko alternatives pointed by GitLab documentation which
were Docker-in-Docker and Buildkit but none worked unprivileged.
Regression: our logs will be a bit more noisy compared to Kaniko.
See: https://github.com/containers/buildah/issues/6362
Moving the gimp_image_undo_free and gimp_image_clean_all
functions outside the link layer check prevents the image getting
dirty. Hence, closing a new linked layer image without changes
doesn't open a save changes dialog anymore.
On some systems, it is possible for gimp_image_window_switch_page ()
to be signaled when private->initial_monitor has been set to NULL but
we don't yet have a GtkWindow. This eventually produces a CRITICAL
when gimp_dialog_factory_add_foreign () is run with a NULL monitor.
This patch adds a condition so that gimp_image_window_session_update ()
is not run with a NULL monitor in those cases.
There is no bug report that I know of as it was reported directly by
Aryeom. When a dock had only a single dockbook, if we tried to move one
of the dockable to the above or below target areas, it would fail.
The reason is that we were not counting the dockables correctly so the
code thought we were trying to move from a dockbook containing a single
dockable (single tab).
Converts the babl formats for Adobe Color Book
Lab and CMYK formats to "float", to prevent a crash
when accessing u8 Lab colors that have negative values
and CMYK colors that are too dark.
...with filters during Recompose
Previously, get_buffer_with_filters() inserted and removed a temporary
copy of a layer in the original image. This caused the image to appear
modified, adding entries in the undo history and prompting the user to save
changes, even though the image itself was not actually changed.
This patch modifies the function to create a temporary image and perform
the layer insert operation there. Filters are applied as before,
but the original image remains untouched, avoiding unwanted undo entries
and mark the image as modified.
GIMP ILBM File Parsing Stack-based Buffer Overflow
Remote Code Execution Vulnerability
Adds a check to file-iff.c to ensure the palette_size is
between 0 and 256.
GIMP XWD File Parsing Heap-based Buffer Overflow Remote Code Execution
Vulnerability.
Check offset in colormap is valid before writing to it.
Closes #14814
ZDI-CAN-27836: GIMP FF File Parsing Integer Overflow
Remote Code Execution Vulnerability
This patch increases the row_size data type to gsize and checks if it
would overflow based on the width given. It also makes sure the image
size does not exceed GIMP's image size limits.
GIMP WBMP File Parsing Integer Overflow Remote Code Execution
Vulnerability
We recently fixed one instance of not upgrading the size, but forgot
the other. Fix that here by casting to (gsize). While we're at it,
also add a warning, when reading more data fails unexpectedly.
Closes #14812
GIMP DCM File Parsing Heap-based Buffer Overflow Remote Code Execution
Vulnerability
This adds more safety checks and sets actual GError's instead of just
calling gimp_quit.
Closes #14811
As reported by Liam, apparently for someone with a lot of filters, these
node creations just to check the aux input may add up noticeable time on
boot (it may also depend on the OS too? I didn't have any noticeable
delay personally).
Unfortunately we cannot know the presence of an aux input just with
class introspection because they can be registered by the op at runtime.
This optimization is therefore twofold:
* Since we know which filters have an aux input among all the ones with
hardcoded actions, we also hardcode this data. It means we only do the
actual check on non-hardcoded operations (third-party filters but also
GEGL operations which are not specifically listed in our code).
* I only do these checks once, stored by name in a hash table, because
filters_actions_setup() is actually run several times (for different
menus).
This should improve startup time a lot for people who experienced this
delay.
Not making use of 'ref:' makes GitLab fetch the latest version of
the *initiative.yml with the latest fixes and such. That would
not be a problem and even desirable maintenance-wise but that
allows GNOME to add anything on our .gitlab-ci.yml at any time.
This is hard to debug and can break our CI. For example,
see: https://gitlab.gnome.org/GNOME/citemplates/-/issues/35.
Though most of the stats we were pulling came from this, let's format it
exactly how we have done in many latest release news.
Also add automatic stats pulling too of our many side repositories.
Some jobs were using the Debian image from Docker Hub registry:
- meson-health
- clang-format
- cppcheck
- sources-debian
- dev-docs
- dist-appimage-weekly
The reason was that we don't need a bigger image suited for builds
($CI_REGISTRY_IMAGE:build-debian-${DEB_VERSION}-${RUNNER}), but
it relied entirely on luck. If we push too much commits in a day, it
could surpass the Docker Hub limit. So, let's use our own image always.
This fixes the following warning when compiling with CLang:
> libgimpwidgets/gimppropwidgets.c:3961:11: warning: variable 'unit_type' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
> 3961 | if (pspec_unit && GIMP_IS_PARAM_SPEC_UNIT (pspec_unit))
If a unit property name is set, it must be a valid unit property. Let's
check, output a CRITICAL and return NULL otherwise.
This macro will generate a #warning message when we'll move on to 3.99
series (which means we will be on our way to GIMP 4). And it will become
an #error message on 4.0.0, hence preventing us from releasing unless we
actually resolve all these warnings.
Resolution may mean actually breaking the API/ABI, or just deciding that
it's not a good idea in the end, or finding another solution. But
something will have to be decided.
Please everyone use this macro when you discover issues where it looks
like we could improve the API (in a breaking way) so that we don't
forget when approaching GIMP 4 (pushing further the improvement).
Updating the 2 place where I was already using a GIMP_CHECK_VERSION()
with #warning, and adding a new usage in the compose plug-in, per
discussion in MR !2424.
Though I can't reproduce on Linux, the performance log seems to show we
spend too much time inside filters_actions_update(). Instead of creating
nodes at each update, let's just store the information about which
filter action has pad, since this should not change within the timespan
of a given session.
Runners do not remember the MSYS2 repo cache between jobs since
they are not relying on any Docker caching.
The problem is that GIMP could link to different lib versions than
babl and GEGL, but that is the way local shell executors work anyway.
The strings used in decompose.c's "decompose-type" do not match
the values of compose_type for YCbCr values. This means that when
using non-interactive Recompose, there's no match and the Recompose
fails. We'll need to wait until the next API break to fix the strings.
For now, we will do additional checks if the normal compose_type check
fails and also compare the four YCbCr types from Decompose.
The button for opening the edit panel for editing a brush / gradient /
pressure curves looks misaligned because it is added to the end of the
horizontal box and its icon is aligned to the end of the button instead
of its center.
This adds puts the text entry and the edit button into the same
horizontal box and fixes the image alignment.
In the case the "create-custom-widget" signal is not emitted (typically when
using the print portal), it is necessary to open a second dialog to fine-tune
the print settings.
Remove most of the per-action special-casing. This won't scale, and in
fact it already doesn't work well with all generated actions from GEGL
operations. Considering that any third-party operation will generate an
action too, this just can't work.
Instead we know that:
- Filters on group, vector and link layers must always be run
non-destructively.
- Non-interactive filters are always run destructively and therefore
cannot be run on group, vector or link layers.
- GEGL graph as well, unless a specific environment is set.
- All operations with auxiliary inputs cannot be run non-destructively
(yet) either and therefore must also be deactivated on these layer
types.
A few more actions are still special-cased (in particular regarding
being used on grayscale drawable or on formats with an alpha channel),
though it would be nice if we could generalize these somehow eventually
too.
… the whole canvas while keeping aspect ratio of the source image.
The previous dimensions were not entirely "out of the blue" since they
were taken from the file, but very often dimensions from vector images
are kinda bogus (apart from aspect ratio, they don't mean much) anyway.
Now we will just fill the canvas box by default.
When changing the source file of an existing link layer though (through
Link Layer properties), the dimensions will be within the current layer
bounding box.
Also I realized that we need to also store the link width/height in the
XCF because the buffer width/height may not be right (in case a
transform matrix was applied). This commit therefore breaks XCF file
with link layers made in the last 2 days. Since we have not made even a
dev release, it's probably fine to do this and not bump the XCF version.
Previous implementation was always keeping ratio. If the width/height
argument were of a different aspect, librsvg simply fits the image with
original aspect within the box. Now we will appropriately scale
differently on both dimensions to have the image fill the whole box.
Note that this doesn't work with librsvg before 2.46.0 (not that it's
not possible, just that I haven't looked at how it should be implemented
there (which would be a different implementation anyway since there is
no cairo step).
Finally I add a build warning for when we'll prepare for GIMP 4, as the
pixel density arg needs to be split in 2 (each dimension can have its
own PPI), even though this is not really needed right now.
Note that it's not actually tested with an old librsvg, but only forcing
this code path with a new librsvg and fixing the compilation
errors/warnings which are outputted.
Following the improvement in fe4cbb65, the Critical Dialogue
uses the native titlebar in Windows. This means it no longer
adapts to dark and light mode automatically.
Since we don't want GimpCriticalDialog to be dependent on
internal GIMP code, this patch copies over the fallback code
in gimp_window_set_title_bar_theme () (which sets the title bar
based on the background color) when the dialogue is realized.
Otherwise, the '-I' param will not be set and Apple Clang will
fail on exotic environments like Homebrew on
which not everything is in the common 'includedir'.
This commit also makes the scaling detection a bit more forgiving to
"imperfect" scale matrix by using an epsilon low enough that it probably
won't make much of a big difference, transform-wise, while it would make
a big difference quality-wise.
Resolves #14761 (and other issues)
* Clears out the selection on GimpPageSelector on load so
that it does not try to "redraw" areas when the dialogue is closed
* Fixes layout on load dialogue to better match 2.10 (and use less
vertical space)
* Now that we have a unit property, replace the call to
gimp_label_string_widget_get_widget () with a direct connection to
changes in the config's "unit". This both fixes a CRITICAL caused by
setting a signal on a non-existent object, and restores the function
that adjusts the dimensions when the unit is changed from inches to
millimeters and back.
This is not a full new release but we might as well test the new
release-candidate to see if it fixes the build issues with GCC 15.
Partially reverts 4ae861f5ac
...for toggle bold/italic/underline.
This commit adds support for common formatting shortcuts in the Text Tool:
- Ctrl+B: Toggle bold
- Ctrl+I: Toggle italic
- Ctrl+U: Toggle underline
- We now bump to XCF version 25 since vector layers were implemented in
XCF 24.
- Fix some now broken code in saving/loading, also rename
PROP_LINK_LAYER_DATA to simply PROP_LINK_LAYER and use the generic
gimp_layer_from_layer() which I created in commit afb8867bce and is
also used for text and vector layers.
- Add a PROP_TRANSFORM layer property. It is separate from
PROP_LINK_LAYER because I will likely reuse this for other (all even)
types of layers as well.
Revert the logic of opening all files as link layers back into loading
their current content as normal layers.
Instead just add a new action dedicated to open images as link layers
and add it to the File menu.
Per UX discussions with Aryeom.
This commit will make all transform tools run on a link layer cumulate
their transform matrix on top of the previous transform steps. It means
that as long as you don't edit the pixels another way (e.g. with a paint
tool), all your transformations will apply as a single transformation.
For instance it means that applying several transform tool steps on a
monitored link layer will be less destructive than applying the exact
same transformations on the exact same "normal" layer contents.
Even scaling an image to 1x1 then back to a big size will work very
fine!
Note nevertheless the following limitations in current implementation:
* The link layer with transformations will still show as a standard link
layer. Nothing says it has transformation applied on it right now.
* To drop transformations applied on a link layer, you have to discard
the link info, then monitor the link again. A specific action in the
contextual menu could be worth it.
* This should work with all transform tools (scale, rotation, unified,
perspective, 3D, even Warp…) but it won't work for the Flip tool, nor
will it work for the Transform actions. I will need to implement
GimpItem's rotate(), flip() and resize() methods next.
* The layer mask would still be destructively transformed (I have not
made any tests with layer masks yet, but this should be done next
too).
* I think that the "scaled-only" property is now meaningless. It is now
being replaced by the presence of the GimpMatrix3. Nevertheless I have
still not removed this property.
* The load/save code has not been redone yet to include all these
changes.
The kind of caveats we'd have to know about (and which are not planned
for change, because it's just how it is):
* Any intermediate interpolation methods are dropped when cumulating
transform steps. Only the last interpolation is stored. This is
because anyway the interpolation is only there as the best algorithm
where we visually see the less quality loss. Applying several
transformations as a single matrix will always be visually better than
applying several matrices (whatever the intermediate interpolation
methods chosen).
* This only works with the "Adjust" clipping method (basically no
clipping) because 2 transform steps with clipping won't produce the
same result as the multiplied matrix with clipping. It means that
applying a transform with clipping will downgrade your link layer to
being a normal layer.
The only issue I have with this is how to best convey that clipping is
a major setting setting here, which disables our less-destructive
abilities. Right now, people will just have to "know" it.
* Vector link layers in particular will have 2 levels of
non/less-destructivity transforms. In particular any scaling (both
through "Scale Image", "Scale Layers" and transform tools — since I
added code to detect a matrix doing only scaling and optionally
translation) done **first** will be completely non-destructive since
we will simply reload the original vector source at the right
dimensions. Any other kind of transforms will be appended through the
cumulative matrix, as raster link layers. This also includes scaling
done **after** other transforms, since we cannot easily move the
scaling first (matrix multiplication is not commutative). This second
level of scaling will therefore be *less* destructive, but still
destructive.
It is possible eventually to improve the whole thing if we add some
day the ability to request loading a vector image with a transform
matrix (it will then be up to each vector format plug-in to support
this feature or not).
Note: it could be argued that this whole implementation could in fact be
moved over to base layers, since it would allow also less-destructivity
when applying multiple transformations in a row. We would only merge
results once we edit pixels more directly.
But I think that it's not a bad idea to experiment with this new code in
the link layer. Eventually I may likely move this to the parent
GimpLayer if no blocking issues are found.
Instead of keeping a "modified" property in GimpLinkLayer, we just check
if the link is being monitored. It's also a better wording because we
may "discard the link information" without actually modifying the layer
pixels.
Also I now actually shut down the file monitoring process. This can be a
bit expensive so when we don't need it, let's really free the
GFileMonitor.
This commit also fixes scaling of link layer (which got broken along the
way) and improves the undo code.
Note: I'll probably want to modify the XCF flags, but let's do this in
the end, depending on further changes too.
We now re-render a link (by loading its file) immediately upon setting
the new file, i.e. during the calls of gimp_link_new() or
gimp_link_set_file(). As part of this change:
* A GimpLink now stores a GeglBuffer. And this is changed each time a
file change happens (per the GFileMonitor). In particular that also
means that gimp_link_get_buffer() does not reload the image file at
each call for no reasons, and gimp_link_is_broken() does not have a
`recheck` argument either. This is much more efficient.
* These 2 functions also have a GimpProgress and GError now. We use this
among other things to pass on a specific GimpProgress object. In
particular, the image file dialogs now show correct loading
progression again.
* As a general rule, the code is less confusing as we don't have to
wonder whether a GimpLink is ready. We can assume it always is, from
now on.
Note that gimp_link_duplicate() does not trigger a reload of the image
file. Since we assume that the source GimpLink is supposed to be
up-to-date already, we just copy its buffer as-is as an optimization.
Even if no actual drawable change may have happen, let's manually
trigger an "update" signal, hence triggering thumbnail updates too, but
also contextual menu update in the Layers dockable.
This is still mostly a test of workflow. It is based on the idea that
link layers are normal yet enhanced layers: eventually we should be able
to have some improved less-destructive scaling/rotation (even without
NDE transform effects); you can manually drop the link anytime anyway
(hence getting back to the good old fully destructive workflow); any
pixel editing automatically drops the link too.
Now this still raises quite a lot of questions:
* The link can be confusing to people used to the old way and they may
not realize that editing the original file separately would also
update the render in this file (which may not be what they wanted;
maybe they just wanted to grab a snapshot of this file at a given
time).
* You could also want to link XCF files.
* You could also want to link remote files (especially in a controlled
network environment).
* Linked images are currently taken as a whole; we definitely want layer
support to handle multi-layer image formats (so that you could link
only a single layer, or a collection of layers; do we want to be able
to edit visibility of linked layers separately too? Would be neat). So
how would we handle automatic linking when opening a file? Maybe we
just reproduce the layer structure as link layers (one link layer
monitoring only one layer from the linked file)?
Anyway this is work-in-progress, UX-wise.
This commit changes the following:
- It's now possible to set whether to store an absolute or relative path
when editing link layer properties.
- New layer dialog doesn't propose an "Image link" fill type anymore.
Link layers won't be created this way (see in a future commit).
By default, we set them as relative paths. This seems like the more
practical and allows for relocatable folders when one work with project
folders containing all their assets.
We don't have yet a way to set this to being absolute path, but it will
come in a further commit.
Unless other types of edits have been done on a link layer (e.g.
painting), we avoid quality loss by multiple scaling of raster link
layers by always re-scaling from the source file.
This commit was edited after GIMP 3.0, now that we have dedicated
support for loading vector images with GimpVectorLoadProcedure.
- By default, when loaded as GimpLinkLayer, vector images are loaded at
a size so that they are exactly contained in the image.
- When scaled with Scale Layer dialog, link layers of type vector are
re-loaded from the source file to always stay perfectly crisp.
Even though G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT should normally
happen when we are *probably* at the last change of a set of changes,
the keyword is clearly *probably* as I had 5 or 6 of these events when
saving a single image.
There is no need for our link layer to reload a same image that many
times in under a second. Instead, just emit our "changed" signal in an
idly source to avoid uselessly duplicating events.
Similar to commit 06be074650, but now for
link layers. Their dimension are also determined by their contents so
anyway let's be more resistant from some forms of file corruption.
These are layers who content depends on another source (right now only
an external image). This can be useful when for instance working at
several people on a single artwork, hence being able to load new
versions of an image without even touching anything in the XCF (for
instance, say you draw an animated character while someone else is
taking care of the background).
Similarly to what we do for text layers, once you start modifying the
contents, it turns into a "normal" layer. The link information is still
available though, so it is possible to revert to the monitoring state
with the menu item "Monitor Linked Image" which appear when a link layer
became a normal layer.
This is not finale as I'm still experimenting. In particular, I have not
implemented XCF saving/loading yet for this new layer type.
A GimpLink is just a class monitoring an image file and sending a
"changed" signal when it changes. This will be used to implement link
layers, whose contents is based on an external file.
This is only a simple first version. Future versions may also allow to
monitor specific layers in an image file, or a layer in the same XCF
image which you'd want to link instead of duplicating it.
This note was relevant when the plug-in used GEGL code for collecting
available GEGL operations. This is no longer the case and thus the
copyright can be dropped.
When creating a GimpFillEditor or GimpStrokeEditor with
edit-context == TRUE, a color button is created next to the
foreground/background option. However, the color of the
item associated with the button doesn't change until the
user confirms it in the corresponding dialogue. This prevents
"live-previewing" color changes on vector layers or text outlines.
This patch adds a call to gimp_color_button_set_update () when the
color buttons are created in GimpFillEditor (which GimpStrokeEditor
inherits from). This allows live-previewing on vector layer fill/stroke
and text outlines, as we currently support with text color from the
tool options.
On export, when synchronizing the comment with the metadata equivalents,
we did not consider that the comment could have been changed in the
export dialog comment field. In fact, we already updated the metadata
before that happened in gimp_image_metadata_save_prepare.
To fix that
- We remove it from the above mentioned function, since that is too
early.
- Add the (possibly) updated comment to the exported_image as a
comment parasite so that we can access the updated value, but only
when synchronizing metadata is allowed, and saving comments is enabled.
- Synchronize the comment, taken from the parasite, with its metadata
counterparts in gimp_image_metadata_save_filter, but only when
synchronizing is allowed and saving comments is enabled.
Note that due to this the synchronized metadata comments are only
visible in the exported file. The metadata in the opened image is
not updated.
This patch adds PDB functions to get and set the PaintOptions
fade-length and fade-repeat properties. This settings can be
used together with gimp_context_set_emulate_brush_dynamics ()
to further control how the paint strokes are drawn in a script
or plug-in.
In 6b10cce6 I introduced setting created date/time metadata for new
images. However, I made a mistake there by using : instead of - between
year, month and day for the XMP metadata tags.
This commit fixes that.
While I checked that all the "main" downstreamers make use of it
(ArchLinux, Fedora, Ubuntu, Debian, Ubuntu, MSYS2, macports),
it is so hidden that we can't guarantee anyone will
actually see it in the future in the middle of many lines.
Closes: #14716
This ports the macOS trick to avoid loading binaries from the host.
SetDllDirectory (and its modern counterpart AddDllDirectory) are
not enough since we do not have control about all processes.
STYLE_FG and STYLE_BG to enum GimpViewBorderType, where FG uses the
actual style FG, and BG is simply transparent. Default to STYLE_FG
instead of BLACK (which is BLACK's actual intention). Also, don't
leak all GeglColors of all view renderers.
rid of implicit knowledge about the surface's scale factor.
- render everything to renderer->surface
- pass the widget scale factor around explicitely when rendering
to the surface
- when drawing the surface to the widget, get the scale factor from
the surface itself.
It is a bit too long and not the ideal naming but with the new one we avoid
the -x64 arch suffix which feels redundant due to the [x86_64_v3] added by GL
Resolves #14705
The path tool prevents creating a vector layer from an empty path.
However, the menu option "Path to Vector Layers" does not have this check.
This patch updates the check to constrain it to just one path.
Additionally, it adds a check for the path being NULL before trying to use
it in g_set_object ().
This removes the old custom DIR/DDIR code from the era of the
installer was built locally. Now, it will refer to bundles so
making the .exe installer based on the bundles available,
not enforcing the developer to download all bundles anymore.
We will not use such new facility on CI since we distribute an
universal installer with all arches since 2.8 for good reasons.
This will not change, we will continue to create multi-arch .exe.
The main advantage is locally. Now the .iss script can
recognize at ISCC build time the bundles on the machine,
to create, for example, an one-arch installer. This is very
fast and practival for local hacking the installer scripts.
Of course, this also makes the installer script powerful and
consistent with all other dist scripts which already can do
one-arch packages (appimage, flatpak, snap and msix).
gimp_action_group_add_actions has a loop that expected all strings
to have a context since msg_context was set. Without a context
the original string was used.
DWMWA_USE_IMMERSIVE_DARK_MODE and activeCodePage were introduced on "1903"
The Store version manifest was already using this as minimum version since
day 1, so the commit just extends that minimum version to the Installer.
While is unlikely that users will be affected, we can revert this commit if:
1) LTSC/LTSB users report on tracker that is not possible to install GIMP;
2) we confirm that GIMP works on this machine even with that incompatible API.
While there is a style "background color", the idea of a "widget
background color" is completely bogus, the widget background can be a
gradient or whatever.
- Get rid of "background" in GimpViewable's preview API, only leave the
"foreground color" there for things like brushes or fonts.
- In GimpViewRenderer, add the background types to be used to class and
instance, so each renderer type can choose what it needs.
- Render all previews to alpha surfaces, and do the background
for all renderers generically in gimp_view_renderer_real_draw(),
then render the preview surface on top of it.
We now have a proper PROP_VECTOR_LAYER property in the XCF which will
store the various data relevant to vector layers.
This also fixes saving this new type of layers at all, since it was
broken in MR !773.
This same code will also be usable for GimpVectorLayer and
GimpLinkLayer. It was made generic so that we don't copy the same code
over and over.
Now it also supports the case when the layer to copy was already added
to the image, which is going to be necessary for GimpVectorLayer.
- Some coding style bugs.
- Factorize setting vector layer options into
gimp_vector_layer_set_vector_options(), making sure all code paths to
update the options do the same thing.
- Ceil the vector layer size since stroke width is a double. C rounds
towards zero, which means we may still have too small buffer.
These functions should not be for the PDB only. The core will soon need
these too (e.g. to load resources linked from a XCF file).
So gimp_pdb_get_data_factory() is moved to gimp_get_data_factory() in
Gimp class. And gimp_pdb_get_data_factory_item() is moved to
gimp_data_factory_get_data() in GimpDataFactory class.
… take care of the NULL value.
Up until now, the NULL color was simply not stored in the XCF. I.e. we
had a FILTER_PROP_COLOR argument type (under PROP_FILTER_ARGUMENT) whose
data was just… nothing.
Now we'll just always store a 0 uint32 (just like we do for NULL
string). On load though, we'll continue recognizing both nothing (thanks
to the payload size) or zero.
This patch improves vector layer UX based on feedback.
In summary:
* Makes vector layer editable from the Path tool
* Adds initial PDB for creating vector layers in scripts
* Size vector layers to the path size, rather than image
* Transform tools utilize the path for resizing
* Path tool automatically selects vector layer path
This patch provides a temporary fix for issue
14442. Currently, gimp_drawable_size_changed ()
is called whenever a drawable's size changes (like by
scaling, rotating, resizing, etc). When called, it resizes
filters to the layer's new width and height.
Unfortunately, it is currently also called when typing new
text, as that changes the layer size too. This causes filters
like Drop Shadow to be cut-off because they originally
extended outside the bounds of the layer.
This patch checks if the layer has been rasterized - if it hasn't,
then size_changed () is not called. As stated, this is a temporary
fix for GIMP 3.1.4, and will likely be replaced with a more
permanent fix for GIMP 3.2
Extensions is used both for file extensions and for
GIMP's planned Extension format. This patch adds translation
context so translators know which one we're referring to.
Add the new filter browser to POTFILES.in of po-plug-ins.
POTFILES.skip of po-python and po-script-fu also needed
updating to ignore the new subfolder under plug-ins.
This documents meson-health and appimage
Also, remove the speed comments because these pipelines will
run automatically regardless of the developer intention.
MSYS2 provides the same needed library so let's just find it properly.
Note: even when we do have MSVC support we should never hardcode .build
files. Setting paths to be searched on MSVC is the job of LIB env var.
By default, it is evaluated to CodeView since this is the format we
use on .exe installer and .msix for many reasons (see git log).
However, some people may not use standard debugging tools for
Windows but, for example, GDB, so they need DWARF symbols since
GDB debugger (and the GCC toolchain) have limited Windows support.
Resolves #13087
We use gimp_layer_get_effective_mode () to retrieve
a simplified layer mode for optimization purposes
(e.g. if it's effectively NORMAL, we can do less processing).
GimpTransformGridTool used this function when the user
requests Composited Preview to only apply transforms to
individual layers in a group if absolutely necessary.
This means that sometimes, it returns NORMAL instead of
PASS_THROUGH depending on the number and types of
layers in the group.
Since 71aff497, when we remove a filter we also update the
effective mode of the group layer. However, this leads to an
infinite loop scenario where the effective mode change causes
the TransformGridTool to repeatedly remove and add a filter
until GIMP crashes.
This patch changes the gimp_transform_grid_tool_add_filter ()
check to always get the actual mode rather than the effective mode.
This prevents the effective mode change from causing an infinite loop,
but does mean that we now always apply transforms to all layers of the
group even if the composite preview would work fine.
Fixes the following warnings from Coverity:
* file-paa.c: Casts "width" to guint32 to prevent overflow.
Also, fix checks so that RGBA_8888 textures will be read.
* file-png.c: Free variables if APNG is not fully loaded
* file-seattle-filmworks.c: Verify fseek () doesn't exceed
length of file
* file-tim.c: Casts "width" to guint32 to prevent overflow
* guillotine.c: Free "file" if image creation fails
* gimpitem.c: Initialize offset_x/y to 0 to remove warning
Otherwise we don't know what happened in GIMP build. It
is too verbose to output on GitLab runner console due to
flatpak-builder awful messages about .debug stripping.
For the same reason of 3e958583 this will not work.
And even if we manage to have it configured for
containers in the future, it would be slow like b51f2b52.
Our JPEG 2000 plug-in assumed all imported images
are unsigned - however, it's possible to store signed data
as well.
This patch adds a check to see if the image has the `sgnd`
flag set to TRUE. If so, we offset the signed data to get it
into the unsigned range before converting to an image.
Resolves #14412
While b98fe0c3 resolved issue 10133,
it broke exporting text layers as text on
single layers, since they would be merged
beforehand. This patch reverts the change
until we find a solution that resolves both
problems.
This reverts commit 246f9d284f.
This only reverts the part modifying libgimp* headers. All the part
switching to #pragma once in app/ was kept. See #14668.
This reverts commit 06cd254954.
GObject Introspection tools somehow fail to introspect some macros in a
very bizarre way. See issue #14668.
I thought #pragma once was somewhat standard, but it turns out it's not.
And Wikipedia even stays about this:
> While #pragma once is available in most modern compilers, its
> implementation is tricky and might not always be reliable.
Anyway clearly it's not reliable at least regarding GIR tools. I believe
we should hold up on using #pragma once at the very least within our
libgimp* libraries. It is probably fine for app/ or plug-ins/ where we
don't need to introspect anything (and so far we haven't had any
compilation mishap because of this preprocessing directive).
The name GIMP_METADATA_SAVE_UPDATE does feel a bit ugly but we need to
keep the GIMP_METADATA_SAVE_ prefix, otherwise we would break the GIR
bindings. cf. commit 27fead082a.
Make a warning for ourselves to happen when we are closing onto GIMP 4.
Then we can make a decision whether or not we want to rename this enum
value.
...remapping shortcuts with GDK_META_MASK
On macOS, the Command key is GDK_META_MASK. But when setting a shortcut,
GDK_MOD2_MASK is added too. This extra modifier makes it hard to check
if the shortcut is already in use. GIMP sees it as a different combination,
even if it's really the same. Now, when GDK_META_MASK is used, we remove
GDK_MOD2_MASK. This helps GIMP detect existing shortcuts correctly
and avoid duplicates.
We already use '*_submission' on the MSIX script.
Submission is the first act, the one which we trigger on CI.
The publishing is done by the store (Flathub or Snap Store).
This commit adds support for activating user-defined keyboard shortcuts in the Welcome Dialog to:
- Create a new file
- Open a file
- Open one of the 10 most recent files
When the device is of type GDK_DEVICE_TYPE_MASTER, calling
gdk_device_get_vendor_id() and gdk_device_get_product_id() fails and
triggers a CRITICAL warning. This commit avoids invoking these functions
on master devices, where failure is guaranteed.
See #14219
Resolves #14649
After the Color Space Invasion, we retrieve the color format
from the palette when creating palettes from images. However,
gimp_palette_import_create_image_palette () still only receives
RGB values. Thus, the palette can store RGBA values without the
alpha, thus defaulting it to a random alpha value. This can cause
issues when using the palette to make a gradient or other instances
where the alpha value is reintroduced.
This patch checks if the format has an alpha channel, and if so, sets
the alpha to 255. Future work can be done to make the image palette
conversion less RGB-specific.
at devel-docs
Due to me using an enum name that only ended in one word instead of
the other enums also adding `SAVE_`, the enum values in the gir
scanner were assigned a double name, causing API breakage and a
failure to build the documentation.
So, let's conform to the other enums and change the name of our
enum to `GIMP_METADATA_SAVE_UPDATE`.
Currently, all Raw Data parameters are displayed in a column
when loading. This can cause the dialogue to go off-screen on
displays with smaller heights.
This patch adjusts the dialogue to be a two-column layout, similar
to some of our legacy plug-ins, to reduce the chance of the options
going off-screen.
Closes #5856 - provide a way to export images without adding or
changing any metadata.
Handles issue #3490 together with !2367. The latter makes sure that
an image comment when present is favored over similar metadata tags.
This commit makes sure that when you disable the preference to
update metadata automatically, it does not synchronize the
image comment with similar metadata tags (possibly overwriting other
metadata), it does not update the modification date, and does not
add or update software and change history metadata.
This adds a metadata preference (enabled by default) that on export
determines whether we add and update some non essential metadata.
When this setting is disabled, we only touch the metadata that we
cannot avoid (e.g. updating size, presence of thumbnail, etc.).
The charset=[ascii|InvalidCharsetId] comment originates from broken
handling in exiv2 of Exif.Photo.UserComment. However, due to the way
we (or possibly other programs) write comments, this could have
propagated to the generic image comment and to the
Exif.Image.ImageDescription metadata tag.
By adding a check for an existing comment first, the metadata tags
were not necessarily checked anymore.
To fix this in all cases we need to unconditionally read and interpret
the comment and both metadata tags.
We move handling of charset=InvalidCharsetId to the already existing
function gimp_image_metadata_interpret_comment by adding some
parameters and call this function for all three cases.
always loading comment from metadata
I noticed that if there was text in one of the metadata tags that we
consider equivalent to the image comment, the first one of those
always took precedence over an actual image comment that an image
may have.
Let's change that to only use metadata comments if the image didn't
have a comment set. So, if present, load the gimp-comment parasite
and set that as comment. If not present, we try to load a comment
from metadata.
We use to have a separate hrz.c plug-in for reading these files. It was
removed in 76a5689f.
Since HRZ is a raw 8 bit RGB image with a few extra constraints, it makes
sense to include it as an option in our Raw Data plug-in alongside HGT.
That completes a3aca3c1 making the snap script just like the other ones but
it differs on the way to get GIMP_UNSTABLE since we don't have access to
the GIMP's config.h file after building with snapcraft remote-build.
This patch uses the is_u8 variable in GimpColorScales's
create_group () function to conditionally set decimals to
0 when creating u8 RGB color selectors.
This change will help further distinguish between the 0...00
and 0..255 views in the Color Selectors. It will also better
convey to users that u8 is an integer value rather than a
floating point.
This patch allows GIMP to import two formats created by
Seattle Filmworks. The earliest format SFW93A, and the most
common format SFW94A. Both formats are essentially mangled
JPEGs, though mangled in different ways.
Thanks to Loren Amelang for providing sample images and
information about the format!
libheif from GNOME SDK Snap can't directly use codecs from ffmpeg due
to the use of plugin system (plugins on LIBHEIF_PLUGIN_PATH) at build time.
Also, even if it could (by custom building, which I don't plan to do),
codecs like libde265/x265 are always present in GNOME runtime Snap
(unlike GNOME runtime flatpak) so there is no way of not installing them.
The GNOME SDK Snap have only AVIF and HEIC decoding plugins,
no AVIF or HEIC encoding plugins and no J2K at all. So,
let's complete the support with 'build-packages:'.
The "grabbing" cursor currently used is quite large on
newer versions of GTK3, and makes it difficult for users
to see where they're grabbing. This patch switches to
using "pointer" cursor for hovering over the slider area,
and "col-resize" when actually moving the slider.
It also reverts padding changes in CSS so that the progress
bar aligns with the place the user clicks. Padding is added
in Cairo for the label, though the number entry is now
flush against the input buttons.
This commit allows the "reference value" spinbuttons in GimpSizeEntry
to accept and evaluate mathematical expressions, just like the main
value fields. The GimpEevl parser is now attached to both value and
reference value spinbuttons.
It completely relies on GListModel and doesn't manage any list items
itself. The port should be pretty much feature-complete.
Add a ton of stuff to GimpRow in order to look and behave like a
GimpContainerTreeView row.
Add a playground switch to use the new widgets in all views that can
be switched between list and grid view (brushes, patterns etc.)
Please test!
Our custom keys are now listed under <custom/> instead of <metadata/>,
with the same format otherwise.
This change was initially triggered by using as_component_get_custom()
in libappstream instead of as_app_get_metadata() in appstream-glib (cf.
MR !2326). It seems that libappstream doesn't have any API to get the
<metadata/> keys, and that this tag is not officially in the spec
anyway.
The custom tag on the other hand is officially in the specs (and has
been added in 2018 apparently, cf. commit 1b1ba1f61 in the appstream
repository).
See also commit Infrastructure/gimp-extensions-web@f9f497b.
Without this, all extensions were broken with MR !2326. They were parsed
and correctly listed, but no entry point to plug-ins or data were
registered.
The following things were broken:
* Remove gdk-pixbuf-2.0/ from gdk-pixbuf include (this is part of the -I
directory in the pkg-config data).
* Properly free the allocated AsMetadata which were leaked (while the
AsComponent was freed mistakenly since it belongs to the AsMetadata).
* Properly free GFile as a GObject (it must not be freed with g_free()!).
* Fix various coding style bugs.
* Fix installing a .gex file by dropping it in GIMP. The code in
file_gex_validate() was completely broken as it was not parsing the
AppStream metadata anymore.
* Mininum libappstream requirement moved down to 0.16.1 so that GIMP can
be built on Debian bookworm (our dependency baseline).
* Fix Snap build (hopefully, untested).
From the horse's mouth:
"WARNING: appstream-glib is heavy maintenance mode, use appstream
instead"
Additionally, appstream-glib no longer conforms fully to the
appstream specification.
Some care is taken to taken to support both libappstream 1.0 as well
as libappstream 0.16.x to support stable distros.
Also add API gimp_row_monitor_changed() to be called from a future
container, because we don't want the logic of gimp_widget_track_monitor()
on each row.
Add a GimpView widget and virtual functions to prepare for subclasses.
The controller page of prefs looks a bit funny now, but it's a nice
temporary test case without disturbing general user experience.
A new browser for exploring the available and supported GEGL operations
for use with the filter API. These include also all operations loaded as
GEGL plug-ins and operations registered from GIMP.
Similarly to the Procedure browser it shows also the details of
individual parameters like the allowed values and default values. In the
case of a type that is not completely supported by the GimpProtocol, the
browser can show useful information about a parameter thanks to a PDB
procedure encoding the information in a placeholder GParamSpec.
To prevent losing all information about a type (and also reporting a
different API by dropping a parameter when retrieving an operation's
pspecs, create a placeholder type with a known name and type and put the
rest of the information into its blurb. A little hack-y but filter
browser can now show information of parameters with unsupported types.
Whatever a plug-in does, it should not be able to trigger WARNINGs or
CRITICALs on the core process. Here this was possible when requesting an
array of param specs with gimp_drawable_filter_operation_get_pspecs() on
a GEGL operation, while GIMP doesn't support all types for this filter's
arguments. Trying to send unsupported type specs through the wire would
fail.
Unfortunately just saying that we must add support for these types is
not enough because we simply cannot support every possible types. First
because even in current GEGL core filters, there are types we might
never support (e.g. audio fragments?). But even more because third-party
filters could have custom types too (just like our own filters have
custom GIMP types).
So instead, acknowledge that some types cannot be sent through the wire,
verify when it's one such argument and simply output an informational
message on stderr (because the info of a non-supported type is still
interesting in case this is something we should in fact add support for;
it's much better than silently ignoring the argument).
In an upcoming commit a new user of gimp_gegl_get_op_classes will expect
a list of all operations supported/allowed in GIMP and not just the ones
that are not exposed in the GUI.
In an upcoming commit a new user of gimp_gegl_get_op_classes will expect
a list of all operations supported/allowed in GIMP and not just the ones
that are not exposed in the GUI.
With the same change, this switches from maintaining a list of
operations exposed as an action, this now uses the actions themselves
for the filtering. During this I found some operations that were in the
"exposed in GUI sub-list" were in-fact not exposed but were straight up
blocked. I moved them to the appropriate sub-list along with the
justifications I found in the commit history.
This will be used in particular for adding GimpTRCType to libgimp.
Otherwise it generates some broken gimp_TRCtype_get_type() function
name.
For this use case, we need to look-ahead a bit in the regular
expression.
Some x86_64_v3 runners provided by Cannonical have a 60m limit which
makes impossible to maintain connection in snapcraft remote-build, so
let's ensure we use gimp x86_64_v2 runner which have longer limit.
On the other hand, let's use the x86_64_v3 ones on AppImage to
avoid the AppImage jobs delaying the Snap ones and vice versa.
These updates brokened badly json-c, x265, cfitsio and maxflow modules.
Let's workaround them with proper patches and build options.
By the way, cfitsio was updated and is now built with CMake.
ghostscript was temporarely dropped since it is impossible to
build right now even with Archlinux patches. Let's wait a release.
This fixes the "surprise" of not being able to make a .msix without
previously built assets. That surprise existed because the test was
running quite late (after the successful AppxManifest.xml creation).
Even me, the script author, was feeling like the script was trolling me.
Closes #13001
XDG_DATA_DIRS is a variable used by many deps (e.g. glib) to
find runtime data. So, let's point XDG_DATA_DIRS to the
appimage bundle so prevent unexpected data from the host.
The old API to select stuff and its signals was doing unexpected
stuff and was very confusing. Change things to be "normal":
The selection API is now set_selected() and get_selected(), with no
internal data exposed, and set_selected() emitting the expected
signal.
The signals are now "selection-changed" and "item-activated".
"selection-changed" is always emitted in response to changing the
selection, be it via the API, or by changes in the model (the internal
callbacks in from e.g. GimpContext or GimpImage simply call set_selected()
and don't do any unxpected magic).
This patch adds support for loading
compressed PAA textures.
This includes RGBA 4444, 5551, 8888, and
Grayscale with Alpha channel.
It does not yet cover DXT1 - 5 texture
import support.
The experimental Seamless Clone tool assumes
that all pasted objects are GimpBuffers. With multi-select,
it's now likely that the pasted object is an image containing
layers instead. Thus, the tool would report there was no pasted
data to work with, even though there was.
This patch updates the check so that it retrieves the first selected
layer from the pasted image if it's not a GimpBuffer, allowing the
tool to function again.
Note that this patch does not improve the speed of the Seamless Clone
GEGL operation, just enables the tool to work again in GIMP.
Resolves #9287
In GIMP 2.10, before checking if the drawable was locked,
we checked if it was a layer mask and switched to its
layer if so. This is because the lock status is saved in the
layer.
In GIMP 3.0, we accidentally moved that check to the bottom
during the conversion to multi-select. As a result, when
switching to a layer mask, the lock content and lock position
would always be turned off since we checked the wrong
drawable.
This patch restores the 2.10 order of checks so that
we compare the lock status with the layer and not the mask.
To prevent people from making changes to setting while
in the middle of loading images, we turn off sensitivity to all
widgets in GimpFileDialog (except for the cancel button).
However, the progress box no longer shows the load percentage
when it is not sensitive. Therefore, this patch conditionally leaves
it enabled so we can see progress while loading large images.
Resolves #13589
When selecting multiple layers to transform, the boundaries
would only consider the first layer selected - leaving the other
items invisible.
This patch reuses code from gimp_edit_paste_get_viewport_offset ()
to loop through all selected layers and update the transform
boundaries to consider the total offset and dimensions of the selected
layers.
Following Linux and Windows implementations, this commit add the
system color scheme detection on MacOS, enabling the "System Colors"
setting also on this OS.
Fetch date and time via GetDateFormatEx/GetTimeFormatEx to respect
the user's custom formats from Windows Region settings instead of
falling back to C locale defaults.
When the time or date format is changed from macOS system settings,
these changes do not affect the locale but the user preferences.
This commit ensures that the date and time are retrieved directly from
those settings, respecting the selected format.
When using huge-dimensions (e.g. 60000 x 60000) using a 32-bit int is
not enough to compute the offset, which causes a crash when loading
such a huge image.
We fix this by casting the first variable to gsize. We also do this
for the case where `alpha-frame` is TRUE since it is clear that the
same could also happen there.
Thanks to lazka and the whole MSYS2 project for adding this package to
their repository so that we don't need ugly special-casing anymore.
See: e515fe48bc
The MyPaintSurface2 interface got added with libmypaint 1.5.0.
Also mypaint-brushes 2.0.2 release notes explicitly say:
> The v2.0.x brushes (in general) require libmypaint >= 1.5 to work correctly / not crash.
(cf. https://github.com/mypaint/mypaint-brushes/releases/tag/v2.0.2)
Since Debian bookworm ships with libmypaint 1.5.1, this is fine to bump
this requirement.
Note: there is still some discrepancy lying around with Windows x86
(32-bit) still using mypaint-brushes-1.0 but apparently these older
brushes still work fine with the new API, and Alx will ask the MSYS2
project if we can have a mypaint-brushes-2.0 package for x86 too.
This may happen upon upgrading, before the next update check kicked in
and the existing last-known-release was imported by the config migration
from an older version of GIMP.
Let's just make sure GimpCoreConfig will silently discard these old
values when they are older than the currently running version.
Reju developed a redesign of the Animation Playback
plug-in that more closely resembles standard playback
UIs (such as VLC Player).
The redesign also changes the progress bar to a GtkScale,
so users can move to different frames on the timeline
instead of always having to step through them one by one.
On some system themes, the progress bar on the
status bar was less visible due to the minimum height
being set too low. This patch defines a CSS rule to make
sure the progress bar is at least 10px tall.
This patch separates the conditional logic
for loading perl and mypaint-brushes2 from
ea8b9dc1 to be two separate calls to MSYS2
pacman. This should resolve an issue with
line break differences between platforms.
On Windows, the crosshair cursor for brushes is
offset from the brush outline if you have a display
scale of 200% or more. This is because
gdk_cursor_new_from_surface () does not contain code
to scale the hotspot X/Y coordinates to match the surface
on Windows - so it expects you pass those values in
already scaled to the surface.
This patch adds conditional code to scale the hotspots on
Windows the same way we currently do on macOS (though
for opposite reasons).
...GimpCageCoefficientCalculation.
Resolves #8297
The custom filter "gimp:cage-coef-calc" is used
in the Cage Transform tool, which always sends in
a GimpCageConfig parameter. However, it's possible
to call this filter from GEGL Graph without the config.
This causes GIMP to crash, as it tries to access
members of a non-existent config in
gimp_cage_config_get_n_points ().
This patch adds safeguard checks to make sure there's
a config object before trying to use it. The resulting
filter's output in these cases is blank, which is not ideal
but better than a crash.
Resolves #13842
fits_write_img () was incorrectly used, since we
were writing one channel of RRR...GGG...BBB... data
at a time. This patch switches to fits_write_pix (), and
increments the first pixel's 3rd index after writing
each channel so that the next channel is written from
the correct starting point.
Note that the horizontal and vertical color buttons are
still chained and laid out manually, as we do not have
a chained color widget in GimpProcedureDialog.
...when setting animations for GtkStack.
Adds a check if gimp_widget_animation_enabled ()
is TRUE before setting an animation type in
gtk_stack_set_transition_type (). If it's FALSE,
then we turn off animations with
GTK_STACK_TRANSITION_TYPE_NONE.
This affects the Input Controller dialogue,
Preferences dialogue, and the Welcome
dialogue.
2bbe1958 also added outlines to labels in
the color selector, which was not intended. This patch
reduces the scope of the style change to prevent this.
Resolves #12873
This patch fixes a few warnings and bugs in Map Object.
* Since GimpChoice parameters with only a few options
become RadioFrames rather than ComboBoxes, the
"value-changed" signal no longer worked for Light Type.
This was replaced with a "notify::light-type" signal.
* After the GimpProcedureDialog port, xadj, yadj, and zadj
were no longer created. Calls to block signals on these were
removed, and replaced with updating the GimpProcedureConfig
object directly.
* The step increment for adjusting the Light position was lowered
to match how they work in GIMP 2.10 (and because the current step
size sends the light off-screen in one click).
In ea8b9dc1, PROP_RADIUS was incorrectly used for the
view-zoom and view-rotation property IDs. This patch
removes the duplication and makes the IDs distinct.
Adds support for the following features, based on
unofficial documentation and user-provided sample
files.
* Sets the selected layer based on the image-level metadata
* Sets the visibility of the background layer based on the image
level metadata.
* Sets the blend mode and color tag of each layer, based on extended
layer-level metadata. Legacy blend modes are used, based on
user feedback and comparison with Sketchbook.
* Creates group layers and stores layers in them. Layers are read from
top to bottom, and layer groups are added and filled based on layer
level metadata.
Additionally, fixes a bug where "R~G~B~A" was used instead of
"R~aG~aB~aA" to transfer the color, as Sketchbook TIFF layers use
associated alpha.
Pop-up widgets tied to button viewables can have their previews go over
the original max value which officially is 192 ("gigantic"). When they
do and update their property with the number, a critical gets fired
regarding the maximum value being crossed over.
Closes #14337
Resolves #14456
Similar to bbbf6df5, GTK3 uses GTK_STATE_FLAG_ACTIVE to
indicate a radio button is selected, rather than GTK2's
GTK_STATE_FLAG_SELECTED. This patch fixes the check to use
it when updating _map_format after toggling the format.
While investigating this bug, the code format was also fixed to match
current standards.
This commit changes the metadata viewer to use `GtkListBox`es instead of
`GtkTreeView`s for displaying the tags and their values. The main
advantages is that the latter isn't available in GTK4 (making the
eventual port to it smaller), that they have a11y problems, and that
list boxes allow more advanced UIs than just showing a simple string.
One thing for example that this commit introduces, is to make the labels
selectable, so they can be easily copy-pasted for lookup.
Since we wanted to use `GListModel`, this commit also introduces a
helper object `GimpMetadataTagObject` which holds both a tag's name and
its value. In the future, we could use this to move the string
formatting logic to that helper object, which we could then in turn use
for more advanced UIs.
Use the opportunity also to rename the plug-in to a more
self-explanatory `GimpMetadataViewer` (rather than a `Metadata` struct
which can be easily confused with `GimpMetadata`).
PSP creator comments are supposed to be ASCII according to the psp8
specs.
Since we expect utf-8, text with characters that have their high bit
set (e.g. Copyright character) fail to be read as utf-8.
We fix this by first converting the creator keywords to utf-8, and as
extra security also test if the result is valid utf-8.
Unlike gimp_image_get_selected_items (), we don't return
anything after calling the appropriate function inside
gimp_image_set_selected_items (). Thus, even if we match
the GType for the item, the g_return_if_reached () will always
run at the end of the function and throw an error.
This patch puts that statement in an else {} condition so it
only runs if the GType doesn't match a layer, channel, or path.
This shouldn't be a real change in design, just moving away from
`GtkTreeView`.
Since we stopped relying on the underlying `GimpContainer` API, we can
now stop exposing it in the `GimpControllerManager` too.
* Anders Jonsson noticed a typo where the
'r' in "pressure" was left off in the Gain
parameter description
* Since 0.0 is an invalid value for the viewzoom
parameter in MyPaint, the cut off is adjusted
to be greater than 0, not greater than or
equal to 0.
* The default viewzoom value is set to 1.0f,
100%, rather than 0.0001, very zoomed out.
Previously selection mode variables were shown as-is with
their name in a drop-down in the brush pipe export dialog.
Add a label so we can have nicer strings for the GUI and
also make them translatable.
This patch ports our MyPaint code to use the
MyPaintSurface2 API, allowing us to support
version 2 MyPaint Brushes correctly.
The API update lets us take into account
the zoom factor and rotation of the canvas
when drawing. It also adds a "Gain" option
to the GUI in order to control the strength
of the input's pressure (tablet or mouse).
As a caveat, this patch does not yet
implement spectral/pigment blending.
The TIFFTAG_SUBIFD has a 16-bit length parameter, but we were using a
32-bit int that was not initialized to 0.
Apparently on clang when returning this value the high bits are not
set to 0.
This caused an incorrect high value which caused a stack overflow.
To fix this we change the type to gint16.
See issue #14432.
gimp_file_save () lets you save an image to
any supported file format, but it did not
update the GimpImage's file or exported
file accordingly. This patch adds code to
do just that, patterned after /app/file/file-save.c's
file_save ().
Transform the `GimpControllerManager` so it encapsulates all the logic
related to managing all `GimpControllerInfo` objects, so we can pass
that object around, rather than dealing with the `Gimp` struct
everywhere and pretty hackishly retrieving the manager struct using
`g_object_get_data()`. By also making it a proper `GObject`, we can
later put even more logic onto it.
It seems we were never migrating toolrc since GIMP 2.4 (commit
152af52bfe) but that means that people were losing their toolbox
configuration at every minor release.
Let's migrate recent toolrc, and rename the path tool. I went back to
2.10 because apparently if tools are missing, the toolrc parsing would
fail. Anyway we have no new tools in 3.0 or 3.2. We'll see how to
properly migrate this file when we'll also add new tools but there is no
reason to lose this configuration at each software update.
Resolves #14421
This patch provides a CSS rule for GtkFrame borders inside of
a dialogue (see Filmstrip plug-in GUI for an example) to prevent
a system theme leak from altering the color.
Vala is being silly again and emitting code that is generating a ton of
C warnings that we can't really do anything about. Just ignore all C
warnings (while keeping the Vala warnings of course).
We just agreed that there is no point in keeping these forever if they
have not been fixed for years. They only produce warnings and also they
likely won't work in Wayland anyway so they probably *can't* be fixed
without heavy updates.
This mode should never be used as layer mode anyway but it must still be
listed.
Fixes:
> app/core/gimpimage.c:2837:7: warning: enumeration value ‘GIMP_LAYER_MODE_OVERWRITE’ not handled in switch [-Wswitch]
Resolves #14417
As a security measure, if the user tries to load an SVG
that's larger than the specified limit, we show a warning dialog
that informs them of the possible security risk and lets them
decide if they actually want to open it. However, we did not call
gimp_ui_init () before trying to show this dialogue - resulting in
a crash. This patch adds a call to initialize the UI before creating
gimp_dialog_new ().
...if Save Comment option is enabled.
Currently, it's possible to unknowingly export an image
without a comment, even if it exists, if the "Save Comment"
option is left unchecked. This patch adds a signal whenever
the "Save Comment" checkbox is clicked (and when the dialogue
is first opened) that uses its active status to set the sensitive
status of the comment text area. If unchecked, the text area will
be marked as insensitive so it can't be edited.
instead of using gimp->image_new_last_template directly.
The first call to gimp_get_last_template() will create
gimp->image_new_last_template on demand and thus make sure the first
new image is always matching what is set in preferences. All later
images will still default to the last image created in this
session. Fixes #14378.
In GTK3, GtkProgressBar does not show the frame numbers
by default. This is a regression from GIMP 2.10, so we need
to call gtk_progress_bar_set_show_text () after creating it
to restore the text display.
Resolves #14392
When using Alpha to Selection on a single layer with no
transparency, we were not cropping the selection channel
from the image size to the the layer size. As a result, we were
essentially performing Select All instead of only selecting the
area of the layer itself.
This patch refactors gimp_channel_combine_items () in its
single layer check, to create a mask for single layers with no
alpha that is the size of the layer. It's then used to crop the
image channel the same way the alpha channel does for layers
that have transparency.
...when System colors theme is set.
Previously, we just checked if the theme
was set to Light or not and used that to
decide the title bar colors. With the
System colors theme, this was no longer
valid logic.
This patch renames
themes_win32_is_darkmode_active () to
gimp_is_win32_system_theme_dark (), and
moves it to gimpwidgets-utils.c so that
it can be accessed by functions that
need to determine Windows mode
settings. We then use it to determine
dark mode if the System colors theme
is set, and use the original logic otherwise.
I noticed when running 3.1.2 for the first time it copied settings
from 2.10 instead of 3.0 as I would expect.
Investigation shows that the major version number is hardcoded to 2,
so let's change that to major.
In addition to that, the outer loop continues running even when we
found a migration path if there is a lower major version number
available. Let's change this so we stop when migrate is TRUE.
Also fix some issues that could hit us in the future:
- Change the value of `major` in the for loop from a hardcoded value
to using `GIMP_MAJOR_VERSION`.
- The flatpak specific testing is for version 2.10 but only tested
the minor version. Change that to make sure major is 2.
To make more clear to users that GIMP is up to date, the About dialog now
shows "Up to date" along with the timestamp of the last update check.
If there's a new update available, it will show only the timestamp
of the last update check.
Closes #13079
We don't know if ~/Library/Caches (NSCachesDirectory) is
the practical equivalent of $XDG_CACHE_HOME on Linux or
%LocalAppData% on Windows so let's just drop 3.00 for now.
Showing and hiding the "%d selected items" text in the
ItemTreeView header causes the height of the header to
shift slightly. This is most noticeable on the layer dockable,
as it has a search icon which moves up and down.
To prevent this, we can switch to using gtk_widget_set_opacity ()
to hide and show the text, as the height stays consistent.
GimpSpinEntry is problematic to use when there's little horizontal space
because the slider becomes too small. GimpSpinScale does not suffer from
this because it uses the available space more efficiently. These days it
is also used more over GimpSpinEntry.
Related: https://gitlab.gnome.org/Teams/GIMP/Design/gimp-ux/-/issues/503
We did not load the alpha channel when loading Photoshop patterns.
The Photoshop pattern format doesn't tell you whether a pattern has
an alpha channel. You can only find out by reading the color channels
first and then checking if there is enough room for another channel.
In addition to that there is also an 88-byte empty space before the
alpha channel.
To fix this, we now always add an alpha channel to the pattern and
then check if there is enough room. We separated the code inside the
channel reading loop into a separate function, which is now also
called if an alpha channel is detected. If none is detected, we
initialize that channel to 255 (fully opaque).
Besides this a few minor error checking improvements were made:
- Only show the unsupported color mode text once per pattern file.
- Only accept 8-bit color channels, other values will print a console
warning.
It is possible to have an indexed image open
in one tab, and RGB/grayscale images open
in others. If you have the color editor open
and swap between them, you'll receive a
CRITICAL because the ColorMapEditor will
always try to update a color entry even if
the active image is not indexed.
This patch adds checks to ensure you have
the indexed image open before trying to update
its color entry.
In gimp_edit_copy (), there is a code path where
we iterate through drawables *after* we had freed it.
This patch moves the code that frees "drawables" until
after its final usage.
By moving the block of code to resize the image to layer size outside
the has_selection condition, we ensure that a smaller layer without
selection also gets resized properly.
The existing usage of the mask value was as interpolation variable,
which is a different usage. If we werent doing this, trying to paint
with tool opacity to 100 and a paint dynamics changing opacity, we'd
still have 100% opaque pixels instead of lowered opacity.
I get why Woynert wanted to still interpolate both alpha and RGB
channels here, avoiding some too harsh transition when using the brush
tool. But the algorithm felt overly complicated (unless I misunderstood
the reason). I think what we want is simply to use the mask value to
interpolate, which allows the alpha and color to smoothly transition in
parts where the brush designer was expecting transitionning, when used
in a paintbrush-type tool.
In particular the proposed algorithm was never using the layer[ALPHA]
value which felt quite weird.
Additionally to the algorithm update, this commit:
* Makes the composite mode/space and blend space explicitly immutable.
* Removes code from other composite modes, which was anyway just
copy-paste remnants from gimp:normal operation and add some
g_return_val_if_reached() call to protect these code paths.
* Fix a code path where the out array was never filled (i.e. it was
filled with random data).
* Fix another code path where we could make a division by zero (in my
case, it didn't crash, but I got nan values).
Following 36b660e2b2
- PATH was being set due to the Installer and MSIX but
on my tests on both relocatable and Unix-style builds it
was bogus. C and Py plug-ins worked without problems
- Same aplies to GI_TYPELIB_PATH, it is obscure and useless
This fixes some "illegal variable" noise in the build. There can't
be any dynamically created environment files in the *source* directory,
but there may be in the *build* directory we're modifying.
On 32-bit systems the computed linear size can overflow, causing a
crash.
Use a function that checks for overflow when multiplying and return
an error if that fails.
As extra security also update the loop to compute the base offset after
each line of data, and convert to gsize first when computing the
size for g_malloc and memset.
This patch adds support for loading and
applying active legacy Inner Shadow
layer styles in PSD images. It uses
gegl:inner-glow with certain preset values
to replicate the Photoshop filter.
This also depends on the same settings to render brushes with theme
colors, because this is data, not user interface. Therefore following
theme colors is not necessarily what creators would expect.
Unlike other dockables such as brush and patterns,
deleting a palette color does not automatically select
the next one. This makes it difficult to delete multiple
colors in a row. This patch gets the current index before
deleting the color, and then uses it to select the next entry
afterwards.
Even .sh (Unix) scripts being "forbidden" by us on Meson to
allowing GIMP being 100% natively built on Windows, it is a
good pratice anyway .sh being portable even outside Meson.
Currently, some GEGL filters must always be merged because
we don't yet have a way to store GimpDrawables with filters.
When creating these filters as part of the Filter Tool, we were
changing the "merge-filter" property directly. This mean that
if you had previously set the Filter Tool to be non-destructive,
it would be destructive the next time you added a filter (even if
the filter supported NDE).
This patch creates a separate boolean variable (initialized to the
current state of "merge-filter") and uses that instead in the
gimp_filter_tool_create_filter () function. This allows us to still
force filters with aux pads to always merge, while not affecting
the user's preferences for other NDE filters.
Per Wormnest, the 4 bytes allocated to
PSD Legacy Dropshadow properties are
meant to be used for fixed floating point
values rather than integers. This patch
corrects the PSD layer resource struct and
how the data is loaded, based on prior
work by Wormnest.
Photoshop's PSB format is nearly the same
as PSD. The main differences are that it
allows you to save images up to
300,000 by 300,000 pixels, and it doubles
the size of pointers related to pixel data
(such as layers and channels).
By being in GimpContainerIconView, the toggle was only being shown in
grid view, even though it also affected the list view. So we move it up
to the container, next to the query tag entry.
Also I am adding a function to make this toggle visible only when
requested. And so far, we only request it for the Brushes dockable,
because it doesn't do anything on other data dockables (we added some
code to follow theme, for instance in Palettes dockable, but it doesn't
depend on this setting, because it doesn't touch data render, only GUI
render where it's normal to follow theme).
The latter function fixes issue #14260.
Some system themes add a box shadow and change borders
for GtkNotebook headers. This patch adds rules defining these,
along with defining the outline for header buttons when hovered
over.
- Improve the hash: doing the value computation in guint64, we'd
wrap-around the max guint64, which mostly means that we'd drop all
high bits! Therefore the hash doesn't depend at all on the most
significant bits. Instead let's do our computation in double and
convert to guint in the end. I am not 100% sure if it is that much
better, to be fair (thinking in term of color: the old hash function
depended on the least significant color channels; I do wonder if it
could not make collisions more frequent but I'm not sure). The
wrap-around hash function should be fairly distributed too, but then
maybe we should just use guint directly in this case.
- The computation of unique colors was leaking all the GBytes but the
last! First we must use g_hash_table_new_full() to set a free function
for inserted keys, then we must free every non-inserted key ourselves.
- The "n/a" string should be localized (it's English acronym).
- Also display this "n/a" in italic to make it clearly different from
computed numbers.
- gimp_pattern_load_photoshop_pattern() should be a static function.
Fixes:
> app/core/gimppattern-load.c:39:1: warning: no previous declaration for ‘gimp_pattern_load_photoshop_pattern’ [-Wmissing-declarations]
- Fix wrong format for goffset values:
> app/core/gimppattern-load.c:137:16: warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 6 has type ‘goffset’ {aka ‘long int’} [-Wformat=]
Inspired by https://github.com/flathub/org.gimp.GIMP/pull/437
Now, in the weekly builds the job will fail if some module is old.
It is reasonable to make the job fail since nightly builds are
supposed to be blending edge so they should have the latest deps.
This makes way easier to spot when some module needs to be updated,
reducing a bit the continuous burden of syncing the 3 manifests.
This reverts commit 7af987d31b.
This commit is not needed anymore since the automatically generated
widget will now be radio buttons for small lists of choices.
… depending on the number of choices.
Enforcing a UX decision into code from GIMP/Design/gimp-ux#323.
Note that this is not a perfect automatization, since the right default
widget may still be a combo box even for limited choices arguments, when
the dialog is crowded.
It still improves the defaults, and it is still possible to override the
widget on case by case (just as of now).
Since these functions used in gimpbrush-load will also be used in
Photoshop pattern loading, move them to gimp-utils.
At the same time, change the signature to return a boolean which
indicates TRUE on success and make the returned value a parameter.
This makes it easier to check multiple read calls for success.
Seems it was used at runtime in the past but that is
not the case anymore. Indeed, it started to be bundled in
af79bbe028 due to an
error: before the Windows bundling unification the
crossbuilds "script" on .yml bundled all the 'share' dir.
Some filters such as Color to Alpha require
an alpha channel. Now that we have NDE,
filters can exist separately from layers
until they're merged down. This means
the layer itself may not have an alpha
channel, causing distortions on merge.
This patch adds a method to check if
the filter requires an alpha channel, and
adds it to the layer on merge or export if
it has such a filter.
Resolves #14240
This patch extends a9056419 to use the existing filter's
drawable (if it exists) on all other on-canvas widgets instead
of always using the selected layer.
This is a code path where we already verified that the returned FILE was
NULL. The compiler complained too:
> plug-ins/common/file-tim.c:280:7: warning: argument 1 null where non-null expected [-Wnonnull]
This would be theoretically useful for gimp-image-find-next-guide except
that this function was already using the int type, and allowing 0. I'm
not changing to 'guide' type with none_ok because it would break the
libgimp API (the signature would change, with the type changing from
gint to guint).
Since it already works like this, I just leave a TODO for further
update.
With this and previous commit, we now fully replaced commit 69894d8bbf
attempts for allowing 0 to some types. There was in fact also some
change on 'tattoo' type, but I went through all the PDB functions we
had, one by one, and I don't think we currently have a single case where
we need to allow 0 as a tattoo value. If this need ever arises then we
can always add none_ok support easily in the future.
… passed "0" as argument.
Adding support of none_ok for arguments of type sample_point, allowing
to pass 0 as a special value and use it on this function.
This reverts commit 69894d8bbf.
Let's not randomly make our API less strict on types as a workaround for
a bug. If there are specific cases where it's needed to accept 0, then
these are the cases we have to handle.
Also unlike what the commit message was saying, it's not true that this
was only affecting Script-Fu. Any change to the PDB affects by
definition the whole PDB, as well as libgimp and all bindings (over PDB
or libgimp alike). And yes, this change **was** of "real consequence".
I'll do further commits for the proper fixes to #14205.
Since MR !2158, we set the desktop name as prgname, because that's what
is expected for Wayland. But this doesn't work on Flatpak where the
desktop file is renamed (and even to different names for the stable/beta
vs. nightly flatpaks). This commit adds some special-casing when we
detect we are inside a flatpak environment.
Note that on X11 (whether or not we are in flatpak), we just always use
the original desktop name, because then it will be set as windows'
WM_CLASS which will also match the StartupWMClass key we set in the
desktop file (cf. previous commit).
The WM_CLASS X property is apparently set to windows throughout the
program by the g_set_prgname() call which we changed in commit
95e32ebb34 from being the executable name (being the fully qualified
program name with the version) to the desktop name.
The Foreground Selection algorithm was being run when
users switched to a different tool, even if no strokes had been
painted. This caused an unnecessary delay, since no selection
will be generated.
This patch adds a check to verify we have at least one foreground
stroke made by the user before trying to create the selection.
This patch removes restrictions on applying
NDE filters to channels in the GUI. Note
that layer masks are still restricted, not for
technical reasons but because UX/UI needs
to be considered further.
This reverts commit fbee943213.
We must not remove any PDB function because we promise API stability
(not only in libgimp, but also in the PDB). Even if this was not used
anywhere in our own scripts/plug-ins, it may be used by third-party
scripts. At best, we can deprecate them so that people are properly warn
that we plan on removing a function. Then we'll remove it for GIMP 4.
Also I believe that various people were not perfectly happy with GEGL's
unsharp-mask operation, compared to the old one. And that was a reason
for keeping the legacy Script-fu version around. See gegl#122 or other
reports which mention such concerns.
At the very least, this should be discussed first with more specialized
developers to determine whether we consider GEGL's replacement operation
to be adequately replacing the historical script by now, so that we can
plan the removal for GIMP 4.
AVCI images can be opened now, saving is not available in libheif yet.
Opening AVCI needs libheif 1.19.6 with OpenH264 decoder enabled.
HEJ2 images can be saved, when at least
libheif 1.19.8 with enabled support for OpenJPEG is detected.
...to GimpProcedureDialog.
This patch allows plugin developers to create a
GimpCoordinates widget (two GimpSizeEntries linked
together with a chain and with a units combo) in the
GimpProcedureDialog.
It is largely a wrapper for gimp_prop_coordinates_new ().
This patch also makes that function more responsive
to the unit property, now that GimpUnit has a proper
GParamSpec implementation. The default unit and
whether we show pixels, percents, or the resolution
spinners can now be determined via the unit
parameter (if set) rather than relying on
hardcoded values.
As a demonstration, the Tile plug-in's width/height
entries were restored to what they were before the
GimpProcedureDialog port, with units and a chain
link between values.
Was replaced by a GEGL filter, long ago.
See 18 year old commit 31282ecc by Sven that says this exists for backward compatibility.
Which means we should have removed it befoe GIMP 3.0 major release.
Provides nothing more than the GEGL filter, so just delete it,
and NOT move to gimp-data-extras repo.
Fix #13824 (or at least makes it moot.)
The obsolete script was not used by any code in the repo,
except for test scripts, which were changed to not use it.
Resolves #14206
If the user clicks the Fx icon in the DrawableTreeView
repeatedly (and quickly enough), the "closed" signal
function that cleans up the Filter popover does not
run before the next creation code is started. This can
results in the previous view being left in editor->vbox,
leading to duplication.
This patch checks if the editor and view already exist when
the popover opens, and if so, it runs the clean-up code first.
Three types declared in pdbgen perl code,
for sample-point, guides, and tatto objects,
declare too restrictive a range of permissible values.
They should allow the value 0, which the API uses as a sentinel value,
to represent "invalid object ID".
The types are for object ID's, which are unsigned.
GObject checks the declared range when you chunk into a GValueArray,
to call the PDB.
Declaring the attribute in the perl .pdb "no-validate"
is not sufficient since GObject doesn't understand
GIMP_PARAM_NO_VALIDATE, that flag is distinct from G_PARAM_NO_VALIDATE.
Only affects the ScriptFu binding to PDB.
The GI binding to libgimp is not affected.
The declared range is no more restrictive than the underlying type
"unsigned int 32."
So of no real consequence.
The API could be changed to return a list which the caller
would iterate on.
Closes: #12929
This normalizes argv0, making the AppImage debuggable by gdb etc.
From now, the AppImage can't be run in pre-Bookworm (glibc < 2.36)
distros, but that use case was never officialy supported anyway.
No functional change, just some include cleanup, as well as reordering
with a private function made public.
Also adding a comment saying why we have somewhat unrelated code (about
color-scheme) in gui-unique.c. Maybe eventually we should generalize
this message-handling invible window code into a separate file, if it
becomes further used for more message handling.
GIMP 3.0 enforces stricter parameter range checks
compared to GIMP 2.10. As a result, scripts that are the
right datatype but go outside the parameter range will
fail. In GimpProcedure, we have checks if a no-validate
flag is set to bypass these constraints.
This patch adds those checks to Script-fu so it also knows
to not check ranges if no-validate is set.
Total Ink Coverage shows the total percentage of ink
that would be needed to print a particular color. It is the
simple addition of all CMYK channels.
This patch adds a Total Ink Coverage label to the
CMYK color selector, as a reference when selecting a
color for print.
We can't guarantee that the .so modules pointed by GIO_EXTRA_MODULES will
link properly to the bundled libc and other bundled deps in the AppImage.
So, by making our AppImage ignore that var we avoid errors on terminal due
to linking mismatch (e.g. on NixOS which sets that var by default).
It fails silently sometimes, which shouldn't happen but
I don't have time right now to investigate and fix.
For now, allowing it to fail will free auto merge again.
The OpenRaster specification has two official extensions
for layers - storing if they are pixel locked, and if they are
selected. Krita and MyPaint already support these extensions
on import and export. This patch adds that support to GIMP
as well.
Uses plain libpng rather than modified libapng library.
Since libpng only reads one image (and reports other frames
as "extra compressed data"), we read the PNG chunks in separately,
then restart and pass them into libpng for processing.
Since APNG and PNG share the same magic number, we add a check
in the regular PNG loading sequence to see if it contains APNG
frames, and if so, we load them afterwards.
In 756fed0c, we removed code that automatically added an
alpha channel for transformed layers, as it relied on the user
setting interpolation to anything other than NONE.
This patch attempts to restore this behavior with a different
check. If gimp_matrix_is_simple () returns FALSE, it means that
the transformation requires some form of interpolation, and thus
requires an alpha channel. Flipping and translating do not trigger
a change in the alpha channel, but rotation, shearing, and perspective
transforms do (even if the tool's interpolation is set to NONE).
It is unused and setting it on the new toggle button doesn't seem to
work anyway as the dockable's help ID is called. Improving the help page
for this dockable, rather than adding a specific help page, seems a
better fit anyway.
Commit 80fca449a4 had a few issues:
- It was using the theme's foreground or background colors as non-entry
color, depending on whether we draw a grid or not. It should just be
the background's color.
- It was still defaulting color to white/black in some places, instead
of fg/bg colors (though I just removed these defaults because the code
just always properly set these colors later on).
- It was using the foreground colors for vertical grid lines, instead of
background color.
- It was coloring horizontal grid lines as black, instead of background
color.
Resolves #14192
In procedure_commands_get_display_args (), one
section missed a check for the argument array length
before trying to access the index. This caused a crash
if there were not enough arguments sent in for a Script-fu
plug-in. This patch adds that array length check to prevent
the crash.
In 2.10, we did not add a Undo History item for "Lock Content"
in the History dockable. In 3.0, we add the item, but Ctrl+Z
doesn't work because we don't actually push the undo item to
the stack.
Comments in fb1a6725 indicate this was intentionally left off
in 2.10. However, it's more consistent in 3.0 to have all locks
behave the same when it comes to undo history.
The Photoshop and Sketchbook TIFF enums
were added in later versions of libtiff. Since we
do not enforce that version when compiling, we
add macros to verify TIFFTAG_IMAGESOURCEDATA
and TIFFTAG_ALIAS_LAYER_METADATA are defined
before trying to build with them.
Resolves #10133
We always set GIMP_EXPORT_CAN_HANDLE_LAYER in
the export options, even if the user set the "layers-as-pages"
parameter to FALSE. As a result, single-page PDFs did not
render the same way they appeared in GIMP, since
gimp_export_options_get_image () did not process them
as a single layer image.
This patch makes GIMP_EXPORT_CAN_HANDLE_LAYER be
conditionally set based on the value of "layers-as-pages".
The code was still assuming that GimpTempBuf is always 8 bit. Fixed
that, and optimized it to call babl_process() once per line instead of
per pixel. Fixes #13253.
gimp_procedure_add_uint_argument () creates an unsigned integer
parameter. It's functionally equivalent for creating dialogue widgets,
but since we only checked for G_TYPE_PARAM_INT, these parameters
did not generate widgets in GimpProcedureDialog.
This patch adds a check for G_TYPE_PARAM_UINT in relevant sections
to resolve the issue.
Floating selections are added to the same stack as
non-destructive filters. While the GUI prevents merging
filters when there is a floating selection,
gimp_drawable_merge_filters () did not explicitly prevent
this. This patch replaces the while loop to merge filters with
a for loop, and explicitly checks if the item in the stack is a
drawable filter (and not a temporary one).
editable filters, regardless of whether they are currently editable.
Also an ugly hack to make sure the popover resizes corrently with the
number of filters.
- move the filter popover to its own file
- centralize popover sensitivity settings
- get rid of gimp_item_refresh_filters()
- lots of minor filter fixes/changes
Many actions done on layers require refreshing its filters, by toggling
the layer off and on again. When done on an invisible layer, this would
turn it visible, which could not be undone.
Now, the layer remains invisible.
- add channel->full the same way we have channel->empty
- never actually iterate the pixels to determine "full",
only set it on simple stuff like "select all"
- optimize some code to take a fast path when the channel
is full
Fixes #14081.
Layer Masks", Fixes #14055.
- change the logic to show the toggles in "on" state ONLY when ANY
selected layer has the property enabled.
- adjust the action callbacks accordingly, and fix them to only push
undo groups when multiple layers are changed.
- completely remove gimp_layer_tree_view_update_menu(), which did the
same as the action update code, only more broken, was causing
redundant undo steps beibng pushed, and was probably obsolete for 20
years.
This patch fixes the following:
- The magic number for J2K codestreams was left off
when porting from GIMP 2.10, preventing GIMP from
recognizing those files automatically
- The "colorspace" parameter was added to JP2 loading
procedure as an aux argument, so that if a color space was
not defined, the pop-up dialogue will work correctly.
- Fixed a crash in sycc444_to_rgb (), similar to 127cd671,
when freeing parts of the OpenJPEG object that were still in
use.
- Minor spacing issues fixed.
has no alpha, simply fill the mask with complete opacity instead of
leaving the user with a completely empty mask (and thus a completely
transparent layer).
We need the gir and plugins to be able to generate the splash image(s).
Add those as dependencies to gimp executable to ensure they are there
when needed.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/13657
Resolves #13889
Adds support for exporting palettes in
Krita's .kpl format (zipped .xml data).
Colors are currently saved as 32-bit
floating point RGB values.
Future work includes supporting other
color spaces like CMYK, other precisions,
and including color profiles for colors.
Similar logic to 4d8073a3 - the selection signal was not
being properly disconnected when the dialogue closed after
the color entry's color was changed via the HTML field.
This patch switches to using g_signal_connect_object ()
to automatically disconnect when the object is destroyed.
Currently, the Jigsaw plug-in only draws on RGB
channels. If the alpha channel is 0, then the Jigsaw
pattern will not show because it does not change the
alpha channel.
This patch adds a check if the format has an alpha
channel, and conditionally sets the alpha byte to 255
when drawing to ensure the pattern is always visible.
This patch also does some formatting clean-up, and
adds a check on the final progress update when previewing
to prevent it from showing 100% as soon as the GUI appears.
… follow theme colors or not.
This is an update to MR !1370, as a result of testing and usability
meetings with Aryeom. While we understand that some people may want the
brush dockable to not display as some huge white "stain" in the middle
of an otherwise dark GUI (or other colors, depending on the chosen theme
and color scheme), brushes are not part of the GUI. When you look at
brush previews, you don't expect these to follow theme. And for sure,
painters more often paint over a white canvas than a gray or dark canvas
(or other colors), even though this is not an "always true" either. But
it's probably a better bet than following theme (which is closer to
"always false"!).
Therefore, what this additional commit does:
* By default, the brush previews still show as black on white;
* Nevertheless there is now a button (using the Preferences' theme icon)
in the Brushes dockable which allow to switch to theme colors
following brush previews.
* This setting is a GimpGuiConfig property, which means it will stick
across sessions.
Previous code was using the correct background color from the theme, but
the foreground color was always either white or black (depending on GUI
config color scheme). Instead, just use the foreground color from theme.
Since core/ doesn't have access to GTK, hence the theme, we had to
update GimpViewable's get_preview() and get_pixbuf() abstract methods to
have a color argument for recoloring previews (when relevant, which for
most types of viewables is not).
background color. Resolves #9983.
We now check the parent widget's color
first to prevent issues with the selection
altering the background color of the
icon until the view is refreshed.
As a result, we can now define the
selected color of an icon, fixing a
regression from 2.10.
..background rendering. As with the
previous commit, this patch tries to
retrieve the background color and color
properties of the widget, then use them
to draw the background and grid of the
Palette and Colormap dockables.
since GTK 3.10 and according to the GTK3 documentation the setting
is ignored.
Remove the reference to it and thus setting a fallback. According to
the GTK docs `hicolor` is the fallback icon theme.
Since `gimp_icons_notify_system_icon_theme` was only used to add
the fallback, remove the function and setting it with
`g_signal_connect`.
Photoshop stores their Levels filter presets in an
.alv file. This patch adds support for loading these
and converting them to GIMP's Level format.
The .alv file is binary, and consists of a 2 byte version
followed by 29 groups of 2 byte values for input,
output, and gamma. We only read the first four for
now, since GIMP only supports composite and then
R, G, and B individual channels.
Photoshop stores their Curve filter presets in an
.acv file. This patch adds support for loading these
and converting them to GIMP's Curves format.
The .acv file is binary, and consists of a 2 byte version
and 2 byte curve count. Then, you read in 2 bytes for
the number of curve points, followed by 2 bytes for
the Y value and 2 bytes for the X value. You repeat that
for the curve count defined in the header. PS Curves range from 2 to 19 points total.
Since we did not define the padding between menu items
in the menubar, some system themes caused them to
scrunch together. This patch sets the padding to match the
"default" GTK CSS to ensure there's distance between each
item in the menubar.
This patch reduces three sets of warnings
when compiling on Windows:
* In gimp-layer-modes.c, we move the
g_return_val_if_reached () in
gimp_layer_mode_get_format () to the
default case in the last switch statement
to prevent a warning about an unhandled
switch case
* In spline.c, we initialize V[] to prevent
a warning about uninitialized values
* In flame.c, we unconditionally call
g_bytes_unref () to prevent a warning
about dangling pointers.
Right now, when you were setting your hints as KEEP_ABOVE, the dock
window would only keep above the image window from which you called it.
If you create a new image window, it could hide your toolbox and dock
windows.
Now we will reparent the dock windows when switching active display.
Note that this also applies to other types of dialogs we have, such as
the New Image dialog or the Search Actions, etc. But looking at all
these factory dialogs we have, it doesn't look like there is a single
case where the parenting pertains to a specific image. So it makes sense
that we always reparent when focusing a different image window.
Per testing by Gabriele and discussions on IRC, it doesn't make sense
that UTILITY windows also keep all dockables above. Otherwise what's the
difference with KEEP_ABOVE?
Also it turns out that on macOS, setting a parent makes the transient
window follow the parent window (so it's close to the modal window
concept of GNOME). So that makes it even more important that our utility
windows don't have a parent.
Previously, we set text color to change when the "color-changed"
signal was sent out from GimpColorPanel. When all of the text is
the same color, this works fine. However, if we select text with
different colors on the canvas editor, the color defaults to black
since we can only hold a single color. If the user cancels, the
"color-changed" signal is still sent out, so we change all colors
to black.
This patch changes the code to use the "response" signal instead.
Then, we check if the user chose "OK" before calling the color
change function.
To balance the child areas in the toolbox horizontally,
we dynamically set the maximum number of children in
the GtkFlowBox depending on the number of visible ones.
It is possible to hide all of them, giving us a max count of 0.
However, gtk_flow_box_set_max_children_per_line () requires
the max count to be at least 1 - this causes a CRITICAL.
This patch adds a check to make sure the count is at least 1
before calling that function.
In GIMP, if a layer mask is marked as disabled, it
does not show on the screen. However, we always
rendered the mask on PDF export. Since other image
formats like PNG don't render the mask, and since the
user likely does not expect an invisible mask to be drawn
on export, we add a check for gimp_layer_get_apply_mask ()
to be TRUE before rendering the mask image on PDF export.
Resolves #14047
The Color Dialog that appears when you select a
text outline color does not load a palette from context.
Since we then try to get the name from a NULL palette,
this causes a crash.
This patch resolves the issue by adding a check for the
palette's existence before trying to get its name.
I realized that without a listing of changes, the "Release Notes" tab is
missing from the Welcome dialog. I can change this in the code, but
having just a single small sentence filling a big tab is not really nice
either. So instead, let's add some more details even if these are not as
major changes as on a minor point release.
After all, these are still nice changes anyway.
Several of these even take good advantage of the demo feature in our
AppStream parsing.
Converting to "edit-paste*" was counter-productive because you could end
up overriding the default (and very well known) ctrl-v just because one
you touched this "edit-as-new-layer" action at some point in the past
and didn't even remember it.
Also since "edit-paste" existed in 2.10, you could even have shortcut
conflicts by having 2 shortcuts merged.
Instead "edit-paste-merged*" actions seem a bit better, are kinda
similar (though not exactly) and since they didn't exist in 2.10, you
are at least not creating conflicts.
Just swap the values in the stored GeglNode each time you undo or redo.
When undoing, the GeglNode contains the values from before this undo
step. When redoing, it stores the values to after the step.
Also fix a few leaks (GValue-s and list of properties).
A new GIMP_UNDO_FILTER_MODIFIED
enum is now used to store filter properties
when an edited NDE filter is committed.
A new undo entry will be added to the
history each time the filter is edited and
committed.
A GimpColorFrame's GeglColor's Babl format's precision is set to the image's precision
when picked. On an Image encoding change to a different precision the colors are
perceptually identical, but for Sample Points set to 'Pixel' we need to run
gimp_color_frame_update after updating the frame's color to the higher precision one.
windows‑display* actions are used to switch open displays and are not
meant to be remapped. They are implemented so they can be reassigned
each time a display is opened, closed, or moved, in order to keep them
aligned with the order of displays. This commit hides them from the
Shortcuts dialog to prevent remapping and avoidinconsistent behavior.
To avoid hiding these actions completely and making them harder to discover,
this commit removes them only from the shortcuts dialog while still showing
them in the action search.
(see #11685)
It turns out that commit bd6745ab40 is not a good solution either,
because now it is the "Making sure you're not a bot!" page from Anubis
which is blocking us.
I am hoping that a git clone should encounter neither the HTTP 429 error
(though we clone through HTTP, but maybe/hopefully the rate limitation
is set up only for actual web page requests) nor the bot protection.
While all other resources are supposed to be already loaded, this is not
the case of fonts which are loaded in a thread, and whose loading may
end after plug-ins are initialized. So ignore unknown font name as an
exception (because we can't know if it is really unknown or just not
loaded yet).
This fixes such WARNINGs:
> (script-fu:33006): scriptfu-WARNING **: 14:35:28.259: script_fu_add_resource_arg declared resource name is invalid Serif
This fixes 2 such warnings:
> app/text/gimpfontfactory.c: In function ‘gimp_font_factory_load_names’:
> /usr/include/glib-2.0/glib/gstring.h:74:5: warning: ignoring return value of ‘g_string_free_and_steal’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
The (void) ! trick was also possible but this is so ugly so I went for
actual usage of the return value as we should.
Also clean up some trailing whitespaces.
This is to make sure than regardless of how many fonts there are, font loading
won't delay startup.
FontConfig if compiled against libxml2 might fail to parse huge xml configs.
So instead of passing it a huge xml, pass the xml every MAX_NUM_FONTS_PER_CONFIG (currently 1000) fonts.
Also made GimpFontFactory custom config strings private because there is no reason for them to be public.
Profiling showed that a significant amount of time was spent created the hb_blob, and calling FcParseAndLoadFromMemory.
To allow only fonts that pango/harfbuzz recognize, an hb_blob was created from
every font to test if harfbuzz recognizes it, which is obviously a lot of overhead.
FontConfig allows to check if the Font is SNFT and wether it's a WOFF[2] font.
For some reason pango returns a FontDescription with name "Normal" when called
with empty string. This caused crashes in pango markup serialization. This
patch checks if the font before serialization is a valid font object, otherwise fallback to the fallback font.
Also font's reference count wasn't increased in one case when opening xcf file with a text layer.
Resolves #13981
The dimensions of NDE filters were being updated
when a drawable was resized or scaled, but not when
the drawable was rotated. Since this transform also
affects the dimensions of the filter, the filter refresh
code should be called there as well.
This is already documented and updated on gitlab-ci.yml's
"There are five "TYPES" of pipelines on our CI" section so
maintaining two explanations is pointless and not future-proof.
Rather than having to hold Ctrl to switch to edit mode, users can now
just click the start point from the end node to create a connected path.
This makes the Path tool consistent with similar tools in GIMP
(such as Free Select, Scissor Select, and Cage Transform tools) as well
as other programs with a Path tool.
For some GUI elements, we may not want to restrict
the color options to the image mode (for instance,
grid colors on a grayscale or indexed image).
This patch adds a "user_context_aware" boolean
to GimpColorPanel so it can be passed on to set
the same boolean already in GimpColorDialog.
This allows GUI elements like GimpGridEditor to
optionally give full color choices to users,
independent of the image mode.
The behavior of the text tool was such that an undo is pushed only when a single property changes, which is obviously not expected, because, e.g. if part of the text uses a different font this means that the markup changed and all "properties" stayed the same, so an undo wouldn't be pushed.
...color-picking on the image.
In GIMP 3.0, we now show a GimpColormapSelection when
users open a color dialogue. However, unlike the RGB color
selector it does not respond to color-picking, instead always
defaulting to index 0.
This patch adds code to get the index of the currently selected
color from the palette, and set the ColormapSelection's selected
index to that.
47224ba1 set the number of children in the GtkFlowBox
that holds the toolbox widgets to a constant 3. However,
this means if you only have one or two widgets shown,
there was still a horizontal imbalance.
This patch adds up the number of visible widgets whenever
that is changed, and adjust the maximum number of flowbox
children accordingly. It does add a small amount of padding at
the bottom since the invisible widgets are moved below.
As reported by Seungho Kim our despeckle filter doesn't check for
integer overflow when allocating buffers, nor do we check for failed
allocations.
A potential integer overflow vulnerability exists in the GIMP
"Despeckle" plug-in. The issue occurs due to unchecked multiplication
of image dimensions (width, height) and bytes-per-pixel (img_bpp),
which can result in allocating insufficient memory and subsequently
performing out-of-bounds writes. This could lead to heap corruption and
potential denial-of-service (DoS) or arbitrary code execution in
certain scenarios.
Vulnerability Details
•width and height are of type guint (signed 32-bit int).
•Multiplying width * height * img_bpp can result in a value exceeding
the bounds of gsize.
•g_new() does not perform overflow protection; if the size wraps around,
less memory than needed will be allocated.
•Subsequent pixel processing loops write beyond the allocated memory
region (src, dst).
Proof of Concept (PoC)
Open a specially crafted image with very large dimensions (e.g.,
70,000 x 70,000 pixels) and apply the Despeckle filter. GIMP may crash
due to heap corruption, or undefined behavior may occur.
We applied the suggested changes and in addition adjusted the despeckle
function to be able to set error messages, and check for NULL
allocations.
Small follow-up from !2097. To be fair, looking at this plug-in's code,
we should also go much further, because so many useful types are defined
while we could use GLib types.
But I don't want to get into this cleanup rabbit hole right now.
Selecting a color in GimpColorSelection triggers
gimp_color_selection_color_changed (). In the legacy
Grid plug-in, this led to an infinite signal loop (and crash)
when changing colors when the chain link is active. Changing
one button's color would trigger the other to change, which
would trigger the first one to change again and so on.
This patch resolves the issue by blocking the signal in color_callback ()
when the other button is changed in response to the first, so that
there's no infinite chain of callbacks.
It would be more performant since it allows concurrent access as long as
you only need read access (i.e. as long as the cache won't change, which
is the most common case).
- No need of local_grad_data_new(). Just set default variables in init()
as it should be.
- Also move gimp_gradient_chooser_draw_interior() to the init()
function, so that the new() function is only a wrapper of
g_object_new() which is the proper way to implement new classes.
- Get rid of wrong comment.
This commit message has been rewritten by the reviewer (Jehan) because
the original message was not right. It was originally meant to fix #13189
but it was only doing so as a side effect of getting rid of the slice
API.
We still push it as a second step (with updated message) because it's
not a bad idea to stop using the slice API where we can as it's anyway
no more than a malloc/free synonym since GLib 2.76 and might get
deprecated some day.
Even though this is mostly the same thing now, it's only true since GLib
2.76, yet our AppImage uses GLib 2.74.6. This explains why the chooser
finalization was crashing plug-ins.
Note that I also tried to set the monitor as a weak pointer, but it was
not properly finalized by GDK at disconnection apparently. Anyway
processing the "invalidate" signal is a correct way to do this too.
A further possible improvement may be to store the description of the
monitor in the sessionrc file, and keep these in the GimpSessionInfo
too, so that we can easily retrieve a monitor which is often
disconnected and reconnected.
Making sure that it's private then NULLified at end of construction so
that none tries to use this again later on during the life of the
display shell (it may have become invalid since then, cf. #12542).
Also NULLifying a similar variable stored in GimpImageWindow (though it
was already a private variable not used outside in this case).
Setting NULL monitor to file_open_with_display() and
file_open_from_command_line() work just as well to use the monitor under
the pointer which is what gui_get_display_name() was also doing anyway.
We store an `initial_monitor` in several places, not taking into
consideration that a monitor object can become invalid, e.g. when
disconnecting or turning off a monitor. When the monitor is invalid,
it can cause a crash in `gimp_display_shell_set_initial_scale`.
Instead of referencing the initial monitor, we request the monitor for
our display shell. Since at that point we already know that shell is
valid, we should get a valid monitor too.
This was removed in commit b3620517 though we missed it when making our
GIMP 2 to 3 migration rules. A bit late now, but better than never.
I realized this thanks to MR !2240.
Whenever we change the colormap colors in the
Fractal Explorer plug-in, we call set_cmap_preview ()
to update the gradient widget. However, this only changes
the colors if the total number is different than the previous
one, since the only time we change the colors is via a
size reallocation. As a result, most of the time the GUI
display doesn't change.
This patch adds an initial size request of 0, 0, to ensure
the second resize actually triggers the size reallocation
code.
The GFig plug-in assumes that there is always
a valid brush selected when creating its
dialogue. However, a NULL brush is possible,
and GFig's assumption can cause a crash
in GIMP by attempting to get a buffer from
a NULL brush.
This patch adds conditional checks for the
brush to not be NULL before using it.
Fixes #6378
This will break Cygwin workflows (aka when the dev use 'sh' instead
of native cmd or PowerShell) but we were already not supporting that
due to 'win32_command' which redirects Unixish commands to cmd.
This restores the GUI design from 2.10, which requires
less clicks to update settings. It also aligns with
proposed design guidelines to use radio buttons for
parameters with only a few options.
In 1b64fdf5, when copying a selection we resize the
layers but leave the image itself the same size. This
allows us to paste the image in-place if requested by
the user. When pasting as a new image, we retrieved
the stored offsets and use them to resize the image
and shift the layers in the opposite direction of the
offset to align them in the image.
This process works fine within GIMP. However, when
pasting outside of GIMP, we don't go through the
resizing process - so we paste an area the size of the
original image instead of only the selection.
This patch inverts the logic to resolve this regression.
The image is resized on copy, but the original offsets
are still stored. When pasting in place, we retrieve the
offsets to shift the layers over, since we still control
the data inside GIMP. This allows us to send the
correctly cropped image when pasting to outside
applications.
Some languages may **add** localized variants of the acronym (in
particular when the language system is different, usually when it's not
latin script), but the original acronym should stay a valid keyword
because many people will still use it to search the software.
Resolves #13910
Since ICO can store PNGs, it's possible to create an
icon that's much larger than the stated image size and
cause a buffer overflow.
This patch adds a check to make sure the width * height * 4
calculation does not overflow in addition to making sure it
doesn't exceed the maximum allowed size for that icon.
swapping the order of the calls to gtk_widget_show() and
calling gimp_window_set_transient() seems to fix the problem of the
dialog not showing with recent versions of gdm.
Resolves #13903
Our code was set to pan the screen if the user had the
space bar held, even if they had the space bar set to
"no action" or "switch to move tool" in Canvas Interactions
in Preferences. This patch adds a check to make sure we
have the action set to pan before continuing to pan when
the mouse moves.
Resolves issue #13901
Some system themes did not add sufficient padding around
radio icons in our Tool options (like Move and Rectangle Selection).
This made it more difficult to see what was selected.
This patch defines padding to ensure there is enough space to see
which option is currently selected.
while we are looking for the end of a clipping group. We did not take
into account that (non-clipping) groups can be nested multiple levels
deep. In that case the parent last_index will also be -1 which
caused a crash because we used it as an index into the layer array.
To fix this test if parents last_index is -1. In that case the we
keep looking for the end of the clipping group, so no change to
use_clipping_group, just output optional debug info.
In gimp_pickable_pick_color (), we get RGBA values using
the pickable's babl format, but then create a linear format
to convert it when Sample Average is enabled. As a result,
non-linear encodings are always converted to linear, and
the displayed pixel values are shown incorrectly in the
color frame.
This patch removes the code that changes the pickable's
format to RaGaBaA double, since gimp_gegl_average_color ()
already does this and handles the conversion to and from the
original pickable format.
BinPackParameters is looking for a boolean right now, which was changed
to the enum we were using, but only for LLVM 20 (not yet available in
our CI). Comment this line for now.
Fixes failure in "clang-format" job in CI:
> Debian clang-format version 14.0.6
> /builds/GNOME/gimp/.clang-format:22:20: error: invalid boolean
> BinPackParameters: AlwaysOnePerLine
> ^~~~~~~~~~~~~~~~
> Error reading /builds/GNOME/gimp/.clang-format: Invalid argument
See: https://github.com/llvm/llvm-project/issues/117830
Fixes issue 5176.
In GIMP2, the window hint preference controlled whether the image
window was allowed to draw on top of the Toolbox and docks.
In GIMP3/GTK3, apparently that hint does nothing; it's transient-for
that controls that behavior. This patch uses the transient-for
setting only if dock_window_hint is set to GIMP_WINDOW_HINT_KEEP_ABOVE.
Resolves #13711
This patch replaces the generic "Add filter" undo history
for NDE filters with the filter's name. This makes the label
consistent with destructive filters, and is more descriptive.
We may consider adding some indicator that filters are
NDE or not in a future patch.
As per GIMP's style documentation [0]:
- put function parameters on their own lines,
- pack function arguments to fit line and only then wrap.
[0] https://developer.gimp.org/core/coding_style/
MyPaint Brushes have their own custom sliders for brush
options, so they were displayed lower in the dockable
compared to other paint tools like Pencil and Paintbrush.
This patch moves them up so options are in the same place
across all standard paint tools.
Resolves #13850
While layer-actions.c blocks showing the Layer Attributes
dialogue if the layer is a floating selection, it was still
possible to show it if the preview icon was activated.
This is because that calls the "layers-edit" action, which
bypasses the "layers-edit-attributes" block and shows
the dialogue anyway.
This patch adds a check for floating selections in
layers_edit_attributes_cmd_callback (), and returns if the
layer is a floating selection.
Unlike PSD and JPEG, our TIFF plug-in's color profile export
code only ran if the user had enabled the Save Color Profile
option. The CMYK option alone did not trigger the profile code,
so it was possible to accidently export a CMYK TIFF without
including its color profile. Since this is rarely desired, the CMYK
boolean was added to the profile export conditional code, so that
it runs if either option is selected.
Since we don't (and shouldn't, see: #11385) use them. Now, our
Windows builds are 100% native (aka not using Unix-only binaries) so
on par with Linux, which completes a process starded in 9ab48164.
The tool group tooltip was not updated when users
toggled the visibility of tools in Preferences. This patch
adds a check before adding a tool to the tooltip, to make
sure it's visible first. It also clears out tool group tooltips
on mouse over to ensure the tooltip is updated.
The Plug-in Browser plug-in makes a call
to gimp-plug-ins-query to get plug-in
information. Since this PDB was made
private, the browser could no longer load
plug-in information.
This patch makes gimp-plug-ins-query
public again so it can be used.
Following: 89dfd0161a
Even if some script/tool is common on Windows, it's not wise to
use Win-specific things on Meson if they are avaiable on Python,
since that non-Python code will be too hard to mantain without the
Windows maintainer. So, let's make life easier for non-Win devs.
Meson broadly uses one of the few languages that it is available on
all platforms so let's take advantage of it on internal scripts.
This way, we have only one build language to care (aside Perl, which
have its own purpose) and avoid terrible bugs like: #11385.
We forgot to edit the default unitrc when removing these fields in
commit 2a00a9e60a. It's OK since our code can still read these fields
for backward compatibility anyway, but better clean up the file.
The "Available Filters" scrolled window was locked to
200px by 100px when the Display Filters dialogue is
opened. Since this size restriction is unnecessary and
makes it difficult to see the actual filters, it was removed.
The "Active Filters" still restricts the height (with scrolling),
since you can add multiple copies of the same filter
to the display.
Before the "fix" on 941fc000, everything was working fine, which
is a sign that it wasn't even being used. Also, after Jehan own
investigation and my tests, I confirmed that it isn't used anymore.
We use GEGL filters for some of our currently destructive
editing only tools, like Warp and Bucket Fill.
While eventually these will have non-destructive options,
for now it's confusing to show an Fx icon briefly when
the tools are active.
This patch sets these filters as temporary, and updates
the GimpItemTreeView code to not show the Fx icon
if there is only one filter and it is temporary.
Temporary filters can not be deleted from the NDE
pop-up, only from their tools, preventing another set
of reported crashes.
If somehow an image is not passed when opened from the command line, this avoids an infinite loop
as was seen in #13702
This still does not solve the issue of how a bad image was passed in in the first place.
This port made clear that it is almost impossible to
do the langs patching with PowerShell alone.
The new output of the patching will display the encoding.
Previously, the Help button triggered the default dialog close behavior, without showing any help.
This change ensures that pressing Help triggers the expected help function.
Reverts dc21fb76
The CodeView format introduces some advantages to our Windows build:
- It is way smaller than DWARF, reducing the .exe installer. With
the strip of COFF symbols too, the installation is 120MB smaller.
- Can be uploaded as .appxsym to be used on demand by MSIX (in thesis)
- Works better with DIA and DbgHelp debuggers like WinDbg and DrMingW,
respectively. LLDB also works by using LLDB_USE_NATIVE_PDB_READER=1
Context: that was not working before because DrMingw and LLDB seems to
only search for the build-time .pdb path in '.buildid' section of bins.
See: https://github.com/jrfonseca/drmingw/issues/91 and
https://github.com/llvm/llvm-project/issues/125355. So, we will set
_NT_SYMBOL_PATH at least for $PREFIX/bin for now as workaround.
The Smudge Tool gets accumulated buffers from its
history via g_list_nth_data (). However, this function can
return NULL if we go out of bounds. We did not check for
this before trying to use it as a GeglBuffer, which caused
crashes if we ran out of accumulated buffers (e.g. if we
were partially smudging off-canvas).
This patch adds NULL checks to prevent the crashes.
...before trying to get its GimpColorConfig.
Resolves #13691
After the color space invasion, various GimpCanvas
functions are now aware of color management settings.
However, these public GimpCanvas functions do not
require the user to pass in a GimpCanvas, just a GtkWidget.
This can lead to crashes if we pass in a different kind of
GtkWidget, since it may not have a GimpColorConfig property.
One example is the Navigation Dockable, which crashes when
it tries to draw boundaries around the image when "Show All"
is turned on, because it passes a GimpView widget instead of
a GimpCanvas.
This patch adds a check if the "canvas" parameter is actually a
GimpCanvas, and sets the config to NULL otherwise.
With grave on heart I am dropping crosbuilds. Always liked them but
actually our crossbuids on Debian are flawed on either GCC or Clang
(with linking either to UCRT or MSVCRT, I tested all possibilities).
The main problem is that Debian does not provide the runtime deps
(unlike Fedora) so we use from MSYS2. This fact tends to cause:
- Linking problems due to undefined references on compiler: #11756
- Clash between Windows runtime and Linux build-time deps: #12970
Worst, these bugs historically are rarely spotted or fixed at all.
Some of them took weeks and even months(!) to be reported by us and,
in the end, there is only one or two guys to do this: me and Jehan.
I do rather prefer to improve native builds than spending more and
more time on fixing crossbuilds without effectively using them.
Resolves #11552
We did not explicitly define the colors for the Minimize,
Maximize, and Close button icons for merged titlebars.
On some system themes, the color used blends into
the titlebar and makes the icon look invisible.
This patch makes sure we always define the icon color
for the Default theme.
Resolves #13633 (for now)
Same rationale as 975d1a4a, as diagnosed by Thomas Manni.
During 3.2 development, we can review and likely just set this as
the default value inside GimpDrawable.
For now, this is a limited bugfix for 3.0.x.
Following eab5e061
This avoids curious users cheating the mode to make multiple installs, which
is unsupported by us since we only allow for different mutexes. See: #1382
It looks like packagers have regular issues with this support. Also I
added info about the fact we also support JPEG2000-in-HEIF (HEJ2) now.
And I made clearer that there may be other encoders/decoders possible
for a given format (though for AV1, we have a clear AOM preference in
our code).
Finally I add info about an environment variable which may be useful
probably in cases when the run prefix differs from the build prefix.
Cf. a case which was recently happening in the Snap package.
See: https://github.com/snapcrafters/gimp/issues/390
The Force option does not affect the Pencil Tool's painting.
While Force is already set to be insensitive, hiding the
option entirely makes it even clearer that it can not
be used with this tool.
for generated brushes.
The maximum radius we allowed for generated brushes was not used
consistently everywhere.
In the API call we clamped it to 0.0-32767.0, while the param_spec
set min and max to 0.1 and 4000.0, and the brush editor used a
maximum of 1000.0.
Using a large value (probably anything larger than 4000) would
sooner or later lead to a crash.
Instead of manual changes everywhere, let's define a maximum and
minimum in one place and use that wherever we need the min/max values.
Use the values as set in the param_spec for the defines.
The only place we can't easily do that is in brush.pdb, so we add
a comment above our defines that the values need updating there too.
Actually we should probably use more defines for other values too,
that way there is less chance of min/max values getting out of synch
throughout our code.
This makes a bit more clear changes introduced by:
itInstall, itReinstall, itUpdate: cbe2f6bec2
itRepair: eab5e0615d
itDowngrade: e447b1244b
Unninstall (settings): b6069baa04
Unninstall (restore): 22e3ae24c7
Relocatable builds do not need them.
Also, remove comments about the inspiration for the scripts since
they are now so refined that make no sense to link 3P sources.
If we were running Gimp.locale_directory() at the very start of the
script, it would append before _gimp_reloc_init_lib() had happened, and
therefore the returned value would be the non-relocated locale
directory.
Calling this inside set_i18n() happens later, and also feels like the
proper place for this code.
When reading a gimp:curves preset file, we assume
that we read in at least 64 bytes for the header. If the
invalid preset file is smaller than that, g_input_stream_read_all ()
can read it just fine but the code fails when comparing the
bytes read in to the size of the header.
This means that the GError object is still NULL, so g_prefix_error ()
has no effect - and thus the calling code crashes when it tries
to get "message" from a NULL GError object.
To resolve this issue, we check if error or *error are NULL.
If so, we set the error with g_set_error () instead.
The commit hash is not that useful on releases, even for unstable
releases, because a release is always at a known tagged commit anyway.
Note that I only change this for the About dialog where it's less
visible, and not on the canvas, because I do appreciate that stable
series show with a clean empty canvas. I like stable series to be closer
to a release state (even though it's true that having the commit hash
accessible somewhere for dev/continuous build is a useful feature).
Sorry to translators too! I break the string freeze during the stable
series. It's a string only visible on dev builds anyway, so it's not a
very urgent string anyway. Thanks for all the hard translation work! 🤗
When at least 3 recently closed docks were present in the Windows ->
Recently Closed Docks submenu, then clicking the middle one caused
a crash. Clicking the top or bottom one didn't cause a crash, but
the submenu was then removed so the other closed docks were not
visible anymore (until restarting GIMP).
It turns out we were removing the whole recent menu, instead of
picking the specific action that needed removing. So now we change
this to get the action_name and use that in the remove call.
Although this already fixes the crash, I added an extra check to
make sure action is valid, and if not we generate a critical. This
way we will notice something is wrong if this happens in the future,
without causing a crash here.
The .default style (to show which button is selected by
default) was being overridden by more general CSS styles.
This patch moves it after these general styles so that it
is shown again.
Starting in librsvg 2.54,
rsvg_handle_get_intrinsic_dimensions ()
always returns TRUE for width and height because
the SVG assumes a width/height of 100%.
This means that SVGs without explicit widths/heights
are loaded as 1px by 1px.
This patch adds a check to see if the width/height is
100%, and if the viewbox exists, we use those values
instead.
In 594afaf9, we changed how texture maps were imported.
The array size is now only loaded if we have a valid DX10 compression
set. However, GIMP allows you to export a texture map without
setting a DDS compression. Thus, any DDS images exported with
no compression would only load the first layer on import.
This patch moves the code that copies over the array items size to
be unconditional once the header is loaded.
Resolves #13501
When painting with "Expand Layers" on, we call gimp_get_fill_params ()
to get the color to fill in the new area. However, if the user has set the
fill type to Pattern, the color is NULL. This caused a crash because we
immediately try to set the alpha channel of the color to 1.0 if the layer
has no transparency - and if the color is NULL, that's not possible.
This patch checks if we received a valid GeglColor before trying to
set its alpha channel.
In 10b798c198 g_list_next always was used from the beginning of
the layer list for each call for volume map and array export, so
all layers after the first were the same.
Inno needs an AppMutex to be aware of GIMP execution so
prevent unninstalling or installing GIMP if still running.
(Unninstalling with GIMP running was making GIMP to not be
fully unninstaled since gimp*.exe process file was opened.
It also could cause problems with settings unninstall.)
(Installing with GIMP running was already not possible
since Inno code in that part is more refined but
that check isn't done before deleting .debug files)
Resolves #13504
Similar to c997349e, 2.10 users expect that pressing Enter
on dialogues such as Fill/Stroke Path should immediately commit
the operation. This default response may have been lost during the
GTK3 port, so we need to explicitly set the default response with
gtk_dialog_set_default_response () if a GTK_RESPONSE_OK has been
set.
After discussing with Idriss, we found that if you create
a GimpTextLayer via the public API, the GIMP object
was not being stored in the GimpText object.
If markup like bold/italics was then applied, GIMP
would crash on saving as XCF because the serialization
code tried to access text->gimp_font_factory.
This patch resolves the issue by passing the GIMP
object into GimpText when we create it via the
API.
Based on user reports after the 3.0 release.
These leaks were most visible in the Preferences dialogue,
and cover too large checkboxes and radio boxes, wrong colors
for scrolled window backgrounds, sliders, scales, and
Preference Dialog headers.
...in Welcome Dialog.
Resolves #13468
Per Jehan, there is no need for this text to be selectable,
especially as the other text on the Welcome Dialog is not.
This patch removes gtk_label_set_selectable () for the
"You installed GIMP x.y.z" text to keep it consistent.
Our DDS plug-in checks to see if we have six layers
with certain labels in their name to create a cubemap,
and if we don't, that option is locked.
When porting to GIMP 3 API, we accidentally kept checking
only the first layer's name instead of all six+ layers, thus
making it impossible to verify we had layers with the right labels.
This patch adjusts the iteration code to ensure we check all layers
in the image and not just the name of the first one.
When we removed the drawables parameter for image exports,
we switched to using gimp_image_list_layers () to retrieve the
layers from the image parameter inside the function.
However, for DDS, this provided all layers rather than the selected
ones, so we always exported the top layer. This patch switches
to using gimp_image_get_selected_layers () to only retrieve the
subset of selected layers.
Partly inspired by Infrastructure/gimp-macos-build#69
Now, we ship headers, static libraries and (relocatable) pkg-config files of
babl, gegl and gimp to make a bit easier building filters and plug-ins.
Developers will still need MSYS2 to install the compiler and the
other many dependencies.
Shipping .debug symbols is not a common practice on Linux distros.
Also, backtrace() API seems to not be able to read them separetely.
So, there is no use for them. Who wants top tier debugging can set:
export DEBUGINFOD_URLS="https://debuginfod.debian.net"
Difference Clouds displayed a GUI in GIMP 2.8, which came
from the Solid Noise plug-in. When Solid Noise was converted to
a GEGL operation, it no longer showed a GUI when called from a script.
This patch adds custom parameters to the Difference Cloud so that it will
auto-generate a GUI, restoring the ability to configure most settings for
Solid Noise. Because of commit f92f7d42, script-writers can still call
Difference Clouds without the new parameters to retain the GIMP 2.10
behavior.
Since the ICO plug-in did not process the image with
gimp_export_options_get_image () before export,
filters were not being merged down and thus not
included in the final image.
This patch adds that feature to ICO, CUR, and ANI
exports.
Resolves #13411
While implementing the Sketchbook layers import
code in TIFF, we originally used a procedure to do
part of the processing. This code was replaced, but
the unused variable was left behind. This patch
removes it to reduce warnings on compile.
Closes: #1382
We do not allow multiple installs under the same GIMP_MUTEX_VERSION.
That is a good thing but depends on the partition of the install dir.
Otherwise, if the partition is lost, this become a registry nightmare.
That nightmare is a more 5 years old issue that tormented even one of
our past maintainers, Michael Natterer.
So, let's make possible to fix GIMP installation when the previous
install dir can't be accessed.
Closes #12998.
On Install mode, we correctly allow users to customize the installation.
This is the expected use case of the "Customize" button: the first user be
able to decide if the installation will be system-wide or on local user,
to see the license, to choose the install dir, to select components etc.
On Reinstall and Update mode, however, some options choosen byf the first
user can't be undone, mainly components, since Inno never had support to
"modify" installs (it can only not install the unchecked components).
So, in our current scenario (before this commit):
- If python support was installed but on the update the user uncheck it,
the old python and all old gimp python plug-ins will remain installed
- The same applies for postscript (.ps) component and 32-bit TWAIN
So, the chances of breaking the install are very high. Inno knows that
and displays a built-in warning, but even that dialog have limitations.
So, let's not keep that false impression of being able to modify the
install, let's fix that by hidding "Customize" on Reinstall and Update.
Whenever the font in the Context (e.g. through selecting another font
from the fonts list) changes, a signal is emitted to propagate the
change to the active text layer, but if the font is set to NULL in
Context, we don't want that to propagate (because this would change the
current text's font to some fallback font).
In other similar codepaths (e.g. brushes) this is not a problem because
selecting a brush that doesn't exist will prevent painting until an
existing brush is selected.
Closes: #11666
Creating restore points when admin is common on .msi installers.
We will use PowerShell's 'Checkpoint-Computer' cmdlet which will
automatically evaluate if the Restore point should be created.
Previous code was right and equivalent because
gdk_wayland_window_export_handle() works asynchronously in the same
thread (so phandle can't get overridden by mistake). Nevertheless a
quick code scan felt surprising, so to avoid any such future surprise,
let's just switch the order of statements.
This is probably a temporary fix until 13149 is tackled. And we need to make sure it works on all platforms.
The problem has been patched on macOS so we could also skip this change until the proper fix is done.
While the slider colors match GIMP 2.10's light and
grey themes, the colors in 3.0 were inverted compared
to 2.10's dark mode. This patch inverts the dark mode
colors to better match 2.10's version.
The default value of the number of
children in a GtkFlowBox row is 7.
Since we only have 3 widgets in the toolbox
area, this caused them to be scrunched
over to the left. This patch improves the
spacing to match the widget count.
Reverts: 093f31dc
My approach avoids bundling build-time deps (that increase about 100MB and
creates expectancy of support of some not-used things like 'Tcl/Tk').
However, this hardcoded approach of mine is more fragile.
Some system themes add additional padding or borders
to menu items when hovered over, which causes
the menu to jitter or shake. This patch attempts
to mitigate the issue by defining those values in the
Default CSS theme.
In the Selector editor dialog, on the Glow tab, Changing the Size (%)
and then sliding it back to 0, causes a crash when reaching 0.
When the Size is 0, the pos in `calc_get_gradient` is NAN, which we
do no check for.
This could be issue #13282, but until we hear back and see a crashlog,
we can't be sure.
There might be other issues earlier on, but the whole plug-in could
probably use a revision since a lot of code is unchanged from 1999.
So let's just add a check for `isnan` and additionally change the
< 0 check to < 0.0001, since I saw it not catching very small values
near zero.
Adding some excerpt from our Code of Conduct to be "Considerate and
Respectful". Negative emotions are only making things worse and make
some contributors not even want to interact anymore with some reports.
Also in our MR template, add the mention that we don't want anything
AI-generated in or even anywhere near our project.
Both these topics are things which were recently discussed within the
team (mostly on IRC).
Resolves #13293
This patch fixes a regression from 2.10. The OK button
was not set to be the default response for certain
Selection dialogues like Shrink/Grow/Border, so
users could not just press Enter to apply if they were
fine with the default values. This patch adds a call to
gtk_dialog_set_default_response () to restore this
behavior.
In collaboration with Denis Rangelov, the separator between
panes has been updated to use the same colors and thinner border
in all three theme variants.
Note that the border is created with box-shadow CSS, and is only
shown on one side of the horizontal separators to suggest that
it is a continuation of the bottom section.
GimpHistogramView uses the widget's foreground color
to draw both the histogram and its border. This causes
clipped values to blend into the sides of the border,
preventing the user from seeing them.
This patch gets the luminance value of the foreground
color, then uses that as a threshold to lighten or
darken the border color for contrast.
On some system themes, the background color of
menu items on a merged headerbar would be a
different color from the rest of the menu when
GIMP's main window was out of focus.
This patch defines those items as clear so they become
whatever color the rest of the headerbar is instead.
Closes: #4544
This adds a dialog (after GIMP files unninstall) that prompts about
deleting GIMP config files only: %AppData%\GIMP\${GIMP_APP_VERSION}
Doing that at admin mode would be too convoluted so that feature is
exclusive of user-mode install (which is the default since: 08019d95)
The whole multi-threading changes in the help plug-in seem to badly
break on macOS. See discussion in reopened #12898.
We decided to get rid of it for now and see later if we need to
reimplement this (after understanding what is going on).
Revert "plug-ins: fix #13049 Calling help on unknown help-id causes..."
This reverts commit 7d153bcc6d.
Revert "plug-ins/help: fix thread unnecessarily waiting when locale_parse failed"
This reverts commit fd0ccfa16c.
Revert "plug-ins/help: fix crash when locale is NULL"
This reverts commit 4075add5b4.
Revert "plug-ins: fix failing to access help from within GIMP"
This reverts commit 38f0527ebc.
Revert "plug-ins: add some better error handling when the docs XML request/parsing fails."
This reverts commit 543bb374a8.
Revert "plug-ins: try to load the gimp-help.xml file in a thread."
This reverts commit f2d47e910b.
Resolves #13124
In 3f3b29ba we bumped XCF version to 23 due to
new blending spaces. However, we did not update
the version check switch statement to accept this
version. This patch adds a new case to handle version
23.
Resolves #12880
Since ICNS stores full PNGs for some icon types, it's
possible for them to have a color profile stored in
their iCCP chunk. This patch enables the existing
metadata option to save color profiles, then passes
that choice to the PNG procedure when exporting. Since the new widget affects the existing flowbox,
we also define a minimum height to prevent cutting
off the first row.
Loading is trickier since other software could
potentially combine PNGs with different color profiles
in the ICNS. GIMP does not yet support per-layer
profiles, so for now we'll follow the way the TIFF
importer does it and just attach the first color profile
we come across while loading.
Resolves #13122
The HTML table code expects RGB or Grayscale pixels
when creating a "BGCOLOR" attribute in the table.
This patch defines the capabilities of the exporter
in GimpExportOptions and retrieves a suitable image
with gimp_export_options_get_image ().
Exporting ORA images involves first creating PNGs of
the layers. To do this, we create separate images for
each layer with Gimp.Image.new ().
However, if the original image was indexed, we lose
the palette when passing the temporary image to
the PDB call. This caused us to try saving a NULL
palette, which resulted in the crash.
This patch adds a check if the image is indexed, and
copies over the palette to the temporary image.
When exporting a grayscale image with alpha channel as DDS while
choosing "default" format, we did not set the DDPF_LUMINANCE flag,
but instead used DDPF_RGB, on loading in the 3.0 branch this caused
a failure to read this format due to unrecognized combination of
settings.
First we make sure that on exporting to also set DDPF_LUMINANCE for
grayscale with alpha.
Second we also make sure to zero the blue and green mask fields,
since that is the expected value when these fields are not used.
To support this type of older exported DDS images, we add an extra
format definition for this unusual combination of DDS settings,
that way we recognize them when opening and are able to load them.
Resolves #13092
GIMP crashed when converting an image to indexed mode,
if the user first changed the color in the Configure Grid
Dialogue. This was because signals were not being
properly disconnected from GimpColorMapSelection
after the dialogue was closed.
Jehan found the solution, to replace
g_signal_connect_swapped () calls with
g_signal_connect_object () and flags set to
G_CONNECT_SWAPPED to retain the original
behavior. This ensures the signals are disconnected
after the widget is destroyed on dialogue close.
So the problem was that the duplicated image (as returned by
gimp_export_options_get_image()) was not fully rendered. I think it is
related to the computed size of pass-through group layers (whose borders
may show actually smaller than their actual render which is in fact
composited with below layers).
I am not perfectly happy with my solution as I'd have prefered fixing
the source issue, but it is good enough, just a few before GIMP 3.0
release.
The call to gimp_drawable_merge_filters() on a group set a buffer to the
group layer (a bit like when we rasterize text layer) which was why it
worked fine. But when the group had no filter, we didn't have this side
effect.
So let's make sure we use the mode node output as our merged layer's
buffer in such case.
Also when the bottom layer (to merge) is a pass-through group, we don't
want to disconnect its input.
Resolves #13104
print_preview_get_thumbnail () crashes when trying
to display thumbnails where the image's precision is
higher than 8 BPC. While the plan is to rewrite/replace
this plug-in, for now, we'll duplicate the drawable's
image and convert to 8BPC to prevent issues.
Resolves #13099
For indexed ICO images, we get the palette from a
temporary image during export. Since the palette is
tied to the image, when we convert the temp image to
RGB and then delete it, the GimpPalette is lost and
the image is exported as pure black.
This patch resolves the issue by calling
gimp_palette_get_colors () to get the actual GeglColors,
then adding them to a new palette with
gimp_palette_new (). As this is separate from the
temporary image, it is retained after the call to
ico_image_get_reduced_buf ().
Resolves #13096
In 5a43a464, some debug output was added to help
diagnosis a problem when Snap to Active Path was
turned on. The issue seemed mostly resolved in e57ad0f8,
but the print statements were left in. This leads to
slowdown when moving layers while Snap is enabled
(due to the continuous print statements).
As it's been 19 years since the original commit, it
should be fine to remove these debug statements
to boost performance.
Previously, we did not check if the clipping path name
was properly converted to ISO-8859-1 from UTF-8
before saving. g_convert can return NULL if it fails,
which means we wrote NULL (causing a crash on load).
To resolve, this patch adds a check if the clipping path
name is NULL on load, warns the user, and then
stops loading the clipping path resource.
On export, we fall back to ASCII instead if the conversion
to ISO-8859-1 fails.
Just using the output of the group is not enough since the pass-through
mode cannot be reused for the normal layer (and anyway all below layers
will have been removed). This still works out with a full-opacity
pass-through, but for lesser opacity, what we want is to replace with
not just the group's render, but in fact the render after the
compositing node.
As far as my tests go, we should now have exactly the same render before
and after merging a pass-through group, whatever the group opacity.
...and GimpPatternClipboard
Resolves #10046
After 1b64fdf5, gimp_get_clipboard_object () no longer
returns a merged version of the selected area.
This affected the Clipboard Brush, Clipboard Mask,
and Clipboard Pattern, causing them to always use the
entire image instead.
To restore the 2.10 behavior, we check if the pasted
image has a selection. If so, then we call
gimp_selection_extract () to get the buffer of the
selected area. We also need to unreference this
buffer afterwards, so a boolean check is added once
the buffer has been copied over to the brush and
pattern.
Existing logic to merge a pass-through group layer was wrong because it
was changing the global rendering of the image as though the group was
in fact in Normal mode.
Instead a pass-through group can be kinda considered as a Normal group
which would contain not only its children, but also all visible sister
layers below it. Therefore the new pass-through group merging will be
taking the real pass-through group render into the new layer (we don't
change the original group's mode before copying the render anymore), set
to Normal mode, then we remove not only the pass-through group but all
its big sister layers below it on same level.
Organizational-wise, it may seem unexpected because "merging" this group
leaks outside it (getting rid of not only the children but also the big
sisters and cousins). Nevertheless this is exactly how this group mode
works after all. So let's go full-in.
After discussing on IRC with Wormnest and NikcDC, we decided that it was
worth doing this specific merge the technically proper way, and we would
just educate people through the docs on why this group mode is very
particular this way.
After all, if someone absolutely wants the old-style merge, they can
always manually change the group to Normal mode first before merging.
But if they let to "Pass-Through", we should assume this is the render
they want.
Some data in a GimpContext may have a reference to a GimpImage. In
particular there may be a GimpLineArt when the bucket fill tool is ON
when exiting GIMP.
In such a case, gimp_exit_idle_cleanup_stray_images() would see a
remaining GimpImage, would believe it's a stray image left by a plug-in,
output an INFO message and free it, which would in turn produce various
CRITICALs when actually finalizing the GimpContext.
Therefore we move gimp_contexts_exit() into gimp_exit(), and not when
disposing of the Gimp object (which happens too late).
Resolves #13073
This patch adds a check to make sure we're not
writing beyond the bounds of the "pos" array.
This is the same check that we do earlier when
writing pos[xc++], but it was left off of the last
write command. Since "n" will be 0 if we get to the
end of the array, it prevents us from writing beyond
that.
Resolves #12967
In cdd51740, we added a destructive option
for filters. Since toggling this moves the filter
to the bottom of the stack, we refresh the
layer.
However, layer masks and channels can not
yet have filters applied non-destructively,
so this code created unnecessary undo history
items when commited. This patch adds a
check so that we only refresh layers and
layer groups for now. Once we have NDE
filters for layer masks/channels, we should
revisit this code.
Fullname might not be suitable for display (e.g. if contains family and
style with no whitespace between them), so when available,
use "family style" for display instead.
Sometimes there is more than one name in the font file, the heuristic to
use the second name instead of the first assumed that the first name is
in english and the second is in the font's primary language, but that's
not the case.
e.g. on Windows "Times New Roman Italic" second name is "Times New Roman Cursiva".
Previously buttons in the style editor meant just "faux" bold/italic,
which is different from the behaviour of 2.10, where real bold/italic
was used if available.
Unfortunately this might break in some cases if fontconfig doesn't return the correct face,
but at least it's consistent with 2.10.
Resolves #12428 (for now)
As noted by Thomas Manni, GimpDrawable
does not initialize its push_resize_undo value
except via gimp_drawable_new ().
If the drawable is created in some other way,
it defaults to FALSE and does not save the
original size in history when resized or cropped.
Thomas proposed initializing it to TRUE in
the init () function. This is likely the correct
approach, but could cause some new bugs
right before the 3.0 release.
For now, this patch calls
gimp_drawable_enable_resize_undo () for
GUI-specific operations (like opening as
layers or dragging and dropping layers) to
fix the regression for 3.0. Afterwards, we
can spend time confirming the init ()
approach and switch over to that.
progress on statusbar to not finish
When we returned early we did not call `_gimp_help_progress_finish`.
We fix this by adding those calls in relevant places.
If `gimp_help_locale_parse` failed due to a locale not having a
manual available, we always waited for a 10 seconds timeout because
we depended on the value of success to decide if we should exit
the thread.
When the call finishes we should always stop, so add a `done` parameter
and depend on that to decide if we can exit instead of using success.
Due to recent changes locale could become NULL when no manual for a
certain locale was found.
We fix this by always checking locale first.
While working at this, I realized that nowadays we don't need a second
loop when the specified help-id was not found. Even if a certain
help-id is not translated, an untranslated page is always available
when an English page is present.
So just reference the help_missing page for the locale we found instead
of doing another loop over the locales.
Because of all the options, the JPEG export dialogue is too tall
on smaller displays or resolutions and goes off-screen.
This patch attempts to mitigate the problem by putting some options
in a two column layout.
To prevent long file names from stretching
the menu across the screen, we set a max
character limit and ellipsize them in the middle
in both the File and Windows submenus.
This Windows specific error seems to be a reversal of previous issue
#2495 where we had to add an exception due to many issue of breaking
tablet support.
Now, many years later, it seems the reverse is happening, and people
are reporting not being able to separate between eraser and stylus,
and that there is no differentiation in different pointing devices.
Removing this old "hack" fixes this.
However, we don't know for certain if there are still other devices
where this will cause issues. Let's hope that all drivers for old
devices have been updated by now.
According to my experience, Debian jobs never surpass 20min.
So, if they take more than that, they are likely stuck at:
- Deps job: when pulling Kaniko docker image
- Test job: when running some problematic plug-in test
Regarding Flatpak jobs, they can reach up to 40min at:
- Deps job: when building deps not present on GNOME runtime
Similarly, if Windows jobs surpass 60min, they are stuck at:
- Gimp job: when generating things from gimp-data or bundling
Defines the background color behind
GtkNotebook tabs, removes the background
image from GimpSpinScale progressbar,
and specifies the padding and border width
for toolbuttons to prevent offset issues when
hovered over.
Now, we create the Debian packages image and build babl and GEGL in the
same job. That's not only more consistent with other pipelines but also:
- First, we reduce queues to runners and the chances of they being busy
- Finally, we can cache more "layers" while in Kaniko container (this
will be useful specially to crossbuilds, when they get fixed, and
could be even more to flatpak too if its Docker image wasn't RO).
This patch prevents a system theme leak
for the "highlight" slider on GimpScaleEntry
widgets. Future work can be done to
improve the appearance of the slider.
When used outside of the dockable dialogues,
GimpEditor objects might not have a label
widget assigned. This patch adds a check
to make sure it does before trying to
change its text.
While this was already working when updating a filter through the GUI,
we could see the weakness in the code when updating through the plug-in
API (there, we could again reproduce problematic not-updated bounding
box, similar to #12294).
Since commit 543bb374a8 when
`gimp_help_domain_lookup_locale` returned NULL, we returned with
an error condition.
However, when a user with locale en_CA, or sv_SE tries to access our
help, it should not return, but try again with en and sv respectively.
Instead of returning, only call `gimp_help_locale_map` when locale is
not NULL. Then after that we continue with second pass processing
which will handle the above cases.
At some point, the code to show the label
for grids in dockable dialogues was removed.
(Possibly when GimpContainerGridView
was removed around 10e3a968).
This patch restores that code to
GimpContainerEditor to display the label
when selecting items in gridview in the
dockable dialogues.
While the pass-through group can be skipped in some specific conditions,
this won't work with filters (then the effect would only apply to the
one layer child instead of applying to the result of the child
blended/composited with the bottom layers).
This inconsistency was quite visible because people had to create 2
layers and have one as non-Normal mode for it to behave as actual
pass-through group.
Currently, if you open multiple files at once via the Open as Layers
dialog, it creates a new Undo History entry for each layer. As we
compress multiple layer operations elsewhere (such as deleting
or duplicating multiple layers), it makes sense to compress them
here as well.
12 bpc JPEGs currently load a blank image with a warning
that 12 bit precision is not supported.
libjpeg-turbo supports loading 8, 12, and 16 bpc JPEGs without
separate builds as of 3.0, so this patch adds support for loading
them and normalizing to 16 bit precision if needed.
Since we don't enforce a minimum libjpeg-turbo version, macros are
used to prevent this enhancement from being compiled if not supported.
In 2baa518a, to avoid a critical we use
the resolution as the width of GimpScaleEntry
when the unit is set to pixels.
This had the side-effect of making the
width of the GimpSizeEntry very long when
the unit is initially set to pixels.
Since GimpUnit is now an object, the original
critical no longer displays. Therefore, we
partially revert 2baa518a and refer to the
value as entry_width instead for clarity.
The minimum width is set to 7 to match
the minimum width of GimpSpinButton.
If you were to select a layer group and some/all its children, current
implementation was "flattening" all these at the same level, which is
weird.
Now the whole questioning of what to do in this situation is a very good
UX discussion to have, in particular when you only select *some* (not
all) of the children. Does it mean something? Does it mean you want to
copy part of the tree structure with only part of the children? What
when it's not a copy, but a move (e.g. a dnd in the same image). You
can't move part of the children (what do you do with the rest?).
Anyway that's many questions which I prefer to leave for a real gimp-ux
discussion and specification. For the time being, at least not
flattening a whole tree structure seems a better behavior.
When selecting by color with the Fuzzy Selection, Color Selection,
or Bucket Fill tool, we use gimp_pickable_get_buffer (). This only looks
at the raw pixels and not any active filters, which can result in some
unexpected selections (for example, an NDE offset filter will make it
appear as if you are selecting the wrong area).
There are plans to let users decide whether to select the raw
pixels or the filtered layer. For now, this sets the default action to
consider the layer as seen by the user, with filters included in the
calculation.
In 06bd1f1289 the max number of
dimensions was set to 1000, but the plug-in runs into a
segfault when dimension >4. The rest of the plug-in uses
GIMP_PIXPIPE_MAXDIM as max (4), so use it for the dimension argument
as well.
In particular, we want the new Script-Fu plug-in to be able to handle
their progress status themselves, which is possible with
(gimp-progress-set-text) except that it is far too quickly overriden
because each procedure call generates a new progress message.
I hesitated to make (gimp-pdb-proc-exists) public but I don't think it's
a good idea as it would be redundant with gimp_pdb_procedure_exists() in
the C API.
Instead, just implement (gimp-pdb-procedure-exists) specifically for
Script-Fu, with a name mapped to the C function.
Adding an is_internal value was a mistake, or rather it was redundant.
We already had a procedure type and all internal procedure are set as
GIMP_PDB_PROC_TYPE_INTERNAL.
I also double-checked that it is not possible for a plug-in to create a
procedure with this type (it is rejected), so it's very fine.
… gimp_procedure_is_internal().
I realized we were already naming these "internal procedures" in the
Procedure Browser and this is in fact a better naming than "core
procedure".
When closing the last image, it seems that we'd remove twice the
"windows-display-0001" item, first when making the action invisible,
then when gimp_ui_manager_remove_ui() is called on emptying the display.
And gtk_menu_tracker_remove_items() doesn't handle correctly a NULL
list.
Some people reported cases where gdb doesn't even seem to understand
Python scripts (the error in #12904 implies it is looking for standard
gdb commands, because apparently -x option allows both styles).
Others had issues in sandbox building (#12956).
I don't really want to spend too much time understanding each case,
especially as it's a self-debugging tool, not absolutely necessary for a
successful compilation.
So let's just make this optional, and default to "false".
The original code from 9eec33ba was wrong because it was not downloading at
CI_PROJECT_DIR. Now, it does, and only downloads on parent dir if locally.
Also, fix .NET Runtime download URL.
Similar to 333499265d,
since we need 'AppxManifest.xml' and 'data_associations.list'.
Also, fix build_dir code when script is called from 'installer' or
'store' dir.
Now, we don't need to set a lot of params when calling 'issc' anymore.
The version vars will be taken from Meson, being more future-proof.
This is not 100% future-proof, however, because we unfortunately can not
take 'config.h' vars directly due to Meson limitations:
https://github.com/mesonbuild/meson/issues/14260
This a bandaid for an issue on MacOS:
an IO event is received that says a read pipe from a plugin has data,
but the pipe is actually empty and reads hang, and hang the app.
Possibly this is an issue with GLib and could be fixed there,
to not send such a spurious IO event.
Possibly an alternative fix is to determine whether the app side of the
plugin protocol is in a state where no messages from the plugin
are expected. In that case, the read pipe should be flushed
i.e. data discarded, with non-blocking reads, until a read returns nothing.
Resolves #12973
Since the standard 'drawables' argument for procedures
is now a GimpCoreObjectArray, the suggested syntax for
setting it in a Python call was incorrect. This impacts other
parameters as well, so we add a check for the argument type
being Gimp.ParamCoreObjectArray and then provide the
correct Python code to set them.
This is an alternative implementation for issue #12825, replacing commit
424ef17bac, after further discussion with Jacob.
Basically we don't need a new key "gimp:help-id" anymore. Instead, for
every action we add through a "gimp:menu-path" key AND when its name is
prefixed with "gegl:", we generate a help ID from the operation name.
The first few operations in such case already have a help page for them,
with corresponding help ID, in gimp-help repository.
In the future, we may expand this help ID generation rule to any
core operation (i.e. any operation prefixed with "gegl:") but for the
time being, we only do for the ones with a menu path, otherwise we'd
have too many missing pages.
Also fix again gimp_gegl_procedure_get_help_id() so that it searches a
help ID within all existing operations in the "filters" group, as I
realized that this was still broken in some cases.
I pondered a lot about this one. In particular I wished we saw the leaks
earlier so that this change were in a RC (really unsure we'll have any
more RCs now).
On the one hand, I could tweak signal callbacks so that the callback
gui_exit_after_callback() is called before the fast exit(). But it feels
more and more like a hack over a hack.
Having 2 code paths depending on whether we are in a release or not is
ugly and would only hide bugs during the whole development cycle (as
proven here). Now when I read the comment, the part about speeding up
the quit process doesn't seem like it makes much sense these days (maybe
back then when this was implemented?). GIMP is fast to quit with or
without this.
Now the part where I worry is the problem of plug-in possibly still
running. Does it mean there used to be cases where GIMP would be stuck
at exit because of buggy plug-ins? I don't think I ever saw one of these
during the whole unstable cycle, and pretty sure we have code able to
kill plug-ins when needed. Even if not, by now, my preference would be
that, if ever someone were to report a similar case, we should just
improve our exiting code to kill (SIGKILL, without any chance of
avoiding it) any guitly plug-in.
This is why I finally decided to just get rid of this very old code.
For reference, the last time it was added was commit cdc2f0ded6 in
2004, though we can actually find older commits where it was removed
(921f00c13d), added (1db2ada311)… Looks like it used to be quite a
dance, but this is hopefully not needed anymore.
I had a case where the GIO API ended just stuck and never returning.
This API is made to work in a thread so that you can cancel loading URIs
from the main thread. Let's make use of that.
Seems that Debian Testing 'apt' defaults to 'dialog' mode by default, which
produces warnings since the Docker image don't come with 'noninteractive' set.
These warnings are inoffensive but they pollute the job output. Indeed,
they were making some GIMPers a bit worried on IRC.
---
Also, added a comment about why we always use Debian Testing for crossbuilds.
Let's call 'C:\msys64' $MSYS_ROOT as vcpkg guys do (since
it is not a prefix, the real MSYS prefix is $MSYS_ROOT/usr)
and call the various shells by MSYSTEM_PREFIX.
When converting a CMYK JPEG 2000 image to RGB, we freed
the Key array. Since it is still in use, this caused the
plug-in to crash. This patch replaces this with lowering
the component content and letting the OpenJPEG clean up
process handle this work instead.
Some ABR brush files have 16 bit grayscale masks, which fail to load.
This patch adds support for uncompressed versions of these brushes,
based on a provided sample file.
First of all, let's init with the main procedure label (stripped of
leading/traling spaces, of mnemonic underscore and of ellipsis) as
progress status for gimp_progress_init().
Then reuse this main label for all subsequent progress updates by the
same top procedure.
Finally "pulse" the progress at each update to make it more like
progression actually happens.
This is a first experiment to see if not having progress API in
Script-Fu is fine (#12948), by having better progression defaults.
Note that I don't touch the GimpFileProcedure and children because they
are special-cased anyway. As for GimpBatchProcedure, ALWAYS is a good
default too.
This was removed by commit 38b18de709 because this operation doesn't
exist anymore and was replaced years ago. Even though it was not wrong,
let's be over-cautious rather than not enough. What if someone had still
a binary of this old operation lying around?
This doesn't cost much to keep it in the list, so let's just do it (with
a comment to still document it doesn't even exist anymore).
Since the move of GimpUnit from some weird int/enum mixed type into a
proper object type, this was not usable anymore in Script-Fu.
Functions like (gimp-text-layer-new) were therefore broken. It now works
again.
Even though the libgimp wrapper has annotations, it is still possible to
pass a NULL font through, in Script-Fu for instance by not passing all
arguments (and very likely in a plug-in by calling the PDB procedure
directly rather). And unfortunately this would crash GIMP when it tries
to work on the NULL font.
Let's do some sanity check!
Now, we can use whatever variable we want from 'config.h' with its
value, unlike the previous code which was hardcoded and did not
worked at all for variables with custom values like GIMP_RC_VERSION.
(Note: there are still work to do with Inno scripts)
It was caused by GTK finding host's canberra or others modules, which
is goappimage fault: https://github.com/probonopd/go-appimage/issues/332
This bug will remain if the distro have some uncommon module (e.g.
appmenu, colorreload), since we don't ship them.
In 9e8499bb, we forced image and drawable
previews to be 8 bit integer for compatibility.
However, this affects image previews when
in higher precisions, leading to banding
and other conversion issues.
Since the color space invasion, the original
problem should have less of an impact
as GIMP now handles conversions between
profiles much better. Therefore, we will
just grab the existing format for Grayscale
and RGB images, rather than forcing a
precision change to 8 bit.
As discussed on IRC these ops mostly duplicate other gegl ops and
have some shortcomings: range and gui-range, among other things,
are currently not supported. This causes some issues changing values
of parameters in GIMP, see e.g.
https://gitlab.gnome.org/GNOME/gegl/-/issues/403
Since they bring nothing new, and have issues, we will blacklist them
from the GEGL tools interface in GIMP, at least until they have
better support in GEGL.
After discussing with NikcDC and Wormnest on IRC, we agreed that maybe a
default of being sensitive when one or more drawables are selected seems
better, since the run() signature now has an array of drawables. So most
plug-in developers will consider the case when there are several
selected drawables as an obvious possible case.
And if someone really doesn't want to handle this case, they can always
set the sensitivity mask explicitly.
In particular, when setting a sensitivity mask but no image types, the
procedure was always sensitive.
Also make gimp_plug_in_procedure_get_sensitive() more robust.
Resolves #12854
Previously when loading filters, we used gimp_drawable_filter_apply ().
If there was also an active selection, it affected the recreation of the filter
and distorted the display.
This patch switches to using gimp_drawable_filter_apply_with_mask () so
that the filter's mask is always used instead, no matter if there is an active
selection or not.
gegl:pack replaced gegl:hstack almost 5 years ago, but the blacklist
for not showing it in our list of ops in Gegl tool was never updated.
Since Pack is also causing issues in GIMP, see #12890 and #12902,
let's update the blacklist add it there and remove the old gegl:hstack
that has been removed from GEGL.
Following e653535e
The meson-generated 'compile_commands.json' file added by 793c9588 shows an
assumption that we are building in-source, and assumptions are not welcome in
this general file, according to Jehan comment: !1021 (comment 1801018)
On export, when GIMP_EXPORT_CAN_HANDLE_LAYERS is not set
but GIMP_EXPORT_NEEDS_ALPHA is, we merge all layers in the image.
If there's a floating selection however, its attached layer is not included
in the exported image.
This patch converts the floating selection to a regular layer so that both
are included in the final export.
While we blocked rearranging a floating selection in the NDE GUI,
we did not add a check to prevent another filter from being moved
into it. Since a floating selection is considered a GimpLayer, applying
GimpDrawableFilter operations to it caused a crash. This patch adds
more safeguards to prevent this.
This reverts commit 490c8e7dc4.
Actually, I forgot to add 'GITLAB_CI' as an authorized MS Entra app on
Partner Center. So, I just done that and submission from our CI worked.
Cropping relatively to the full image contents is a common usage (it is
in fact the "Crop to Content" feature we have in the Image menu) so I
found it a bit frustrating that these 2 functions only allow to crop
relatively to a single drawable.
Therefore, I make NULL an acceptable input which will default to
cropping to the full image content instead.
- Clean up a bit the 2 procedures' descriptions and add more info in
gimp_image_autocrop() description to explain how the input drawable is
used.
- Rename gimp_image_autocrop_layer() to gimp_image_autocrop_selected_layers(),
which makes it clearer.
Rename plug_in_compat.pdb to image_autocrop.pdb so we retain commit history.
All procedures defined there are related to autocrop.
- made internal, not plugins
- renamed from plug-in- to gimp-image-
- exposed in libgimp
If we need plugin compatibility PDB group in the future,
a starting template can be recovered from plug_in_compat.pdb 2.10 or late 2.99.
Fixed plugins that call. The C plugin now calls libgimp instead of a PDB procedure.
This is used by our release scripts on gimp-web.
Let's not generate for other pipelines, however, since they
don't have long life on GitLab and there is no permalinks yet.
The 'ICON' type of ICNS is a 1 bit black and
white image without a mask. The current
code assumes all pre-OSX ICNS types
have a mask, which caused a crash when
we tried to access it. This patch adds an
additional check if the mask type is 0
before trying to access it.
Closes #11397
Now, the .msixupload submission will be done from our CI with 'msstore-cli'.
Unfortunately, we can't easily update the changelog due to problems of
Submission API regarding '\b' and '\u0008' backspaces, but it's better to
not have a changelog than to keep using the painfully slow Partner Center.
It was not a bug per-say. Simply the filters were set as having "clip"
set by default. We should add a libgimp function to let people choose
instead, but I want to think a bit better how we handle clip and masks
in filters before creating more API. Cf. #12874.
So for now, let's just set clip to FALSE. If we have to choose a single
possible clip value for filters made by the libgimp API, I believe this
is the nicer value.
Since named parameters were added for script-fu, we get a warning if
we don't use named parameters.
This adds named parameters to GIMP's own scripts.
Incidentally it also fixes an issue with Spinning globe when the
image was not the first one opened in GIMP and changes that script to
the new interface too.
This is a new attempt at fixing the issue with cropped effects when
stacking them. The previous attempt was reverted as commit c1c38228a2.
Instead of trying to find the bounding box for the previous effect's
output, just drop the crop_before node (i.e. make it a "gegl:nop") when
it's not the bottom effect.
I don't think this would create any undesirable behavior. In fact, the
only case which I could think of would be when the previous filter
creates an infinite plane (e.g. "gegl:color"). But when such case
happens, filter_clip is forced to TRUE anyway, which triggers crop_after
to be set. Therefore we don't need a crop_before anyway in this case,
because the previous filter necessarily has a crop_after.
… this filter is meant to be merged.
In commit 2c066afff9, I made so that we had a "gegl:convert-format" only
at the latest filter over a drawable. While this was already a huge
improvement, it was still "too much".
Basically the only time when we want to convert to drawable format
(which means usually demote the output to lower bit depth) is when the
filter was just created and is meant to be merged.
This also means that from now on, during preview time, when checking and
unchecking the "Merge filter" checkbox, the preview may be slightly
different. A very good test to see the difference more obviously would
be with indexed images, because "Merge filter" preview would map to
allowed colors only.
It has been reported that ipc4, ipc5, and ipc6 type ICNS icons do not render well
when included in an app as part of a bundle.
This patch uses the older is32, il32, and ih32 24-bit RGB formats (with 8 bit masks)
instead of the newer PNG formats for those sized icons, to avoid the issue.
The help ids for the View Color management commands all pointed to
the same id.
Let's use more specific ids, so that help will arrive at a more
specific location in the manual (once we have added the ids there too).
The help ids for the Image Color management related to soft-proofing
were all pointing to the View color management submenu.
Let's use more specific ids for the Image menu, so that help will
arrive at a better location in the manual (once we have added the
ids there too).
Cleanup cruft, unused files.
script-fu/scripts/init/init.scm
is the only copy that GIMP uses.
It is more or less upstream TinyScheme init.scm v1.42,
that K. Cozens occasionally patches with upstream changes.
But upstream has been at 1.42 for several years.
/scripts/script-fu.init is an unused copy of upstream TinyScheme init.scm v1.40
It should have been deleted on the earlier commit
that moved the file in the repo to /scripts/init/init.scm
and the installed init files to /scripts/scriptfu-init.
/tinyscheme/init.scm is an unused copy of upstream TinySche init.scm 1.41
Deleting it means that the tinyscheme dir can no longer be built by itself
into TinyScheme standalone binary, but we don't support that anyway.
The array of strings representing the Scheme types wasn't updated
after adding named parameters. This caused a crash when trying to
use named parameters where that isn't possible.
Resolves #12855
Since tool-based filters like Warp Tool do not have operations,
checking them when merging down the active filter stack throws
a CRITICAL. The check was not needed, so it was removed.
After recent changes to API:
some PDB procs now private
some PDB procs signature changed, arguments reordered
New testing framework functions: testing:layer-new and testing:layer-new-inserted
No changes except to tests.
This is a bandaid for a situation on MacOS.
When plugin facade in core receives IO event on read pipe from
remote plugin process, check the plugin is in a state where
an IO event is expected i.e. sane.
Otherwise, ignore the event and assume the read pipe is empty.
Resolves #12844
As suggested by Alx Sa, rounding the phase argument in waves-anim
is enough to fix the argument error the plug-in would run into when
using certain values for "Number of frames".
Resolves #12842.
Due to API changes, the call to plug-in-animationoptimize in burn-in.scm
requires a vector to be sent rather than an individual layer. This affected the
script when "Prepare for GIF" was selected.
Therefore, the blended-layer argument was converted to a vector.
Interactive scripts should use the context
palette or gradient rather than the saved
one, as the user is more likely wanting to
edit the gradient or palette they have
actively selected. This is also in line with
how 2.10 operated.
This patch clears out the palette or
gradient property of Python scripts
when the GUI is created, so that it
uses the context version. It does not
affect non-interactive usage.
ISO 8601 basic format was used for standardization. Windows
does not support colons in filenames, so the more human-readable
extended format could not be used.
Resolves #12827.
The Autoslice option was not updated to expect GeglColors instead of GimpRGB
arrays after the Color Space invasion. This patch updates the find_index() and
hexcolor() functions accordingly.
CMYK is saved with lossless compression. Lossy CMYK is
not recommended by libjxl developers.
libjxl API allows possibility to use lossy compression in original
profile but the compression in this combination of settings
is ineffective, with visible artifacts and discouraged
by libjxl developers. We removed this option.
Resolves #12821.
GimpSpinButtons (CSS spinbutton class) did not inherit the hover colors of
other buttons, so they did not highlight when hovered over. While comboboxes
mostly did inherit, there were a few odd instances where they were not in the
same hierarchy as other elements with hover colors defined. This patch defines
both explicitly to prevent one-off issues.
In the initial NDE implementation, we
prevented merging filters if the Warp, Cage,
or Gradient Tool were active to prevent
active tool-based filters from crashing
when cleared.
This patch removes this limitation by
automatically committing the tool before
merging the rest of the filter stack.
This applies the tool-based filter correctly
and then merges the rest of the filter
stack as normal.
When editing a filter, the NDE UI is set to
insensitive so they can't be deleted.
However, closing and reopening the
popover re-enables the options.
This patch adds a new "temporary" boolean
to GimpDrawableFilter. It is only set to
TRUE if the filter is a temporary "editing"
filter. When we reopen the NDE UI, this
checks if the filter stack contains a
temporary filter, and if so, once again locks
the options.
While fixing individual widget's labels to have proper default is good,
let's also have a centralized re-setting of alignment and margins for
all the labels which we set in the same GtkSizeGroup. This makes nice
and consistent dialogs.
Additionally I set a 4px margin at the end of label (0 elsewhere),
otherwise the longer label in the size group end up sticking too close
to its control widget and it's ugly.
This new widget is much nicer, with proper label to document the GUI and
also with support to save files or create folders. It also has mnemonic
support and the label is put into the same size group as other so that
it's nicely aligned.
As a consequence, I remove bad support of object arguments with a GFile
value. People should just create proper GimpParamSpecFile arguments
(also GimpProcedure API now has a function only for such type of file
argument).
I also remove gimp_procedure_dialog_get_file_chooser() which was only
useful when we didn't know what action a file argument was for. Now it's
part of the param spec definition.
libscriptfu was updated too because SF-DIRNAME arguments don't need
special casing anymore.
Finally I change gradients-save-as-css to just make use of the new
automatic widget creation (more than 60 lines of plug-in code replaced
by… 0 lines because it's automatic!).
This whole commit is mostly a lot of code removal now that we have
proper automatization for file arguments! \o/
This widget will replace our usage of GtkFileChooserButton, except that
it has a title label and also it contains GUI implementation for the
SAVE and CREATE_FOLDER actions (unlike the GTK button). Moreover this
widget was removed in GTK4. So it is a good idea to start encapsulating
such GTK widget anyway.
I'm also adding a propwidget function to create such a widget bound to a
GimpParamSpecFile property.
New functions:
- gimp_file_chooser_get_action
- gimp_file_chooser_get_file
- gimp_file_chooser_get_label
- gimp_file_chooser_get_label_widget
- gimp_file_chooser_get_title
- gimp_file_chooser_get_type
- gimp_file_chooser_new
- gimp_file_chooser_set_action
- gimp_file_chooser_set_file
- gimp_file_chooser_set_label
- gimp_file_chooser_set_title
- gimp_prop_file_chooser_new
This patch does the following to reduce the
height of the Load PDF GUI:
* Hides the title label if the PDF does not
have a title.
* Reduce the padding around elements
* Reduces the requested height of the
GimpPageSelector widget.
* Alter the GimpPageSelector widget so
that the layer/image combobox and the
range entry are on the same line.
New libgimp functions:
- gimp_param_spec_display_none_allowed()
- gimp_param_spec_drawable_filter_none_allowed()
- gimp_param_spec_image_none_allowed()
- gimp_param_spec_item_none_allowed()
I believe that now all param spec strucs which needed to be hidden are
effectively hidden!
New libgimpbase functions:
- gimp_param_spec_choice_get_choice
- gimp_param_spec_choice_get_default
Now the only GParamSpec in libgimpbase whose struct is visible is
GimpParamSpecObject. This can't change since it is derived into param
specs defined in libgimp and therefore needs to be visible.
Actually it does more harm than good on CI, causing inconsistency and work.
The plan was to use it in all jobs but it is simply impossible for Flatpak
(https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/1502)
and seems that for Crossbuilds too (tested both crossroad and quasi-msys2).
Actually, only Windows jobs can use it, but started to fail on x86 runners.
On the other hand, sometimes the build is faster without ccache and we do
not have the burden of contacting managers etc. Just pkg caching is fine.
As a consequence, here are needed new functions:
* libgimp:
- gimp_param_spec_resource_defaults_to_context()
- gimp_param_spec_resource_none_allowed()
* libgimpbase:
- gimp_param_spec_file_get_action()
- gimp_param_spec_file_none_allowed()
- gimp_param_spec_unit_percent_allowed()
- gimp_param_spec_unit_pixel_allowed()
… GimpParamSpecUnit's default value.
When I reparented GimpParamSpecUnit to GimpParamSpecObject in commit
ba3da3d338, I clearly forgot to get rid of the redundant default value.
It was working with LC_ALL or LANG but not with LANGUAGE which is an
additional system above the locale system AFAIU.
Concatenating both LANGUAGE environment variable and the locale-set
language, we get a more resilient opaque string value to compare.
Resolved by @Nizhile
In 4bdb8792, a patch porting chrome-it.scm to not rely on
removed brushes included an apparent typo. A decimal
was left off a curve point, resulting in incorrect outcomes.
This patch by @Nizhile fixes the problem.
Resolves #12795
After the Color Space Invasion, gimp_gradient_get_uniform_samples ()
returns an array of GeglColors rather than GimpRGB values and a status
variable. This patch fixes the Spyro-Plus plug-in to expects the new
return values.
It also restores code that utilized the second color gradient in the output
when the Gradient's Repeat Mode is Triangular Wave. This appears to
have been lost during the port from GIMP 2.10.
Without a proper way to compare GFile, gimp_config_reset_properties()
does not reset the config argument to default. This breaks the "Reset to
Factory Defaults" feature in particular.
This same widget is used for GFile args and GimpParamSpecConfigPath
specs. The latter are string-based. So we need different code to handle
both types of arguments.
This was crashing when a change was coming from the config object,
rather than from the GUI, such as when doing a reset to factory values.
Now that GimpParamSpecFile makes file validation depending on the action
set in the param spec, when trying to open a non-existing file (which
can happen through GUI, for instance when opening through the Document
History dockable or Open Recent menu), we had a quite obscure error
about a value "out of range" used "for argument 'file' (#2, type
GFile)", which is because core tried to set the GFile for a non-existing
file into the second parameter of the plug-in PDB. This is not a very
nice error for end-users.
The old error was much nicer as it used to say things like:
> Could not open '/path/not/existing.png' for reading: No such file or directory
But in fact, this string came from the plug-in, which means:
* first that the error can be different depending on the format
(inconsistency of error message);
* depending on bugs in plug-ins, it may just crash or return no error
messages;
* finally we were making a useless call to a load plug-in while we
should already know from core that it won't work.
The new message is something like:
> Error when getting information for file "/path/not/existing.png: No such file or directory
This error is generated by core, so it will always be consistently the
same, is understandable too and the plug-in won't even be called.
As a side related fix, I updated the GimpParamSpecFile validation to
only validate local files, just like we do in core. Remote files can
always be set (and we let plug-ins handle them), at least for the time
being.
Per the (quite off-topic) discussion in #12772, the fact it's quite
broken on Windows, apparently not too maintained anymore and its syntax
clashes with gi-docgen syntax…
I forgot to set meta.m_file.action into the GPParamDef! 🤦
As a side update, let's store the action as gint32 in GPParamDefFile. I
realized that otherwise, depending on the actual size of an enum type,
when casting to a (guint32 *), we crop the value! This works out in
Little Endian because we are only in small number territory, but in Big
Endian, we would always crop any action value to 0!
This was not the bug in this specific case, but it could become the
exact same bug (always passing action 0, i.e. OPEN, through the wire) on
Big Endian hardware.
I don't know what I was seeing when I added this several years ago,
but I can't find any psd CMYK images where the merged image is RGB.
It is wrong for the CMYK images we have and there are none so far
that do conform to it, so let's remove this code.
The merged psd image we create when writing psd's is incorrect when
we selected cmyk at export.
The problem is that we are only saving the 3 channels of our RGB
input image, or 1 for a grayscale image.
Move the channel count up and compute it separately for cmyk, then
reuse the count instead of computing it again.
libgimpbase:
- Mew GimpFileChooserAction enum type: basically a near-mapping of
GtkFileChooserAction (GTK is not accessible from libgimpbase) with
an added GIMP_FILE_CHOOSER_ACTION_ANY.
- New GimpParamSpecFile param spec type: based off
GimpParamSpecObject, it has a default value, but also a none_ok and
action argument. This way, we can also know from the argument type
if this is a file argument meant for selecting a normal file or a
folder, or for saving into a file, or for creating a directory.
libgimp, plug-ins:
- All existing file arguments (until now using a standard
GParamSpecObject param with GFile value type) were moved to the new
GimpParamSpecFile.
- Script-Fu in particular will now generate the appropriate param type
depending on whether it is an SF-FILENAME or SF-DIRNAME.
- File arguments are now stored between runs as a URI rather than as a
path. As far as I can tell, a GFile always has a URI, but not always
a path (in particular remote file won't have a path).
For diagnosis purposes, it is useful for people to be able to copy and paste
the compatibility warning text that GIMP shows when loading a PSD with
unsupported features. This patch makes that label selectable, which allows
for copying.
This is again a change in gettext 0.23 whose release notes say:
> The value of the xml:lang attribute, inserted by msgfmt, now conforms to W3C standards.
Our xpath selection now recognizes both the old and new (proper) format
so that it works both with older and new versions of msgfmt.
f4582d97 uses gimp-font-get-lookup-name, which is now
marked as private PDB. This patch replaces that usage with
gimp-resource-get-name, which is public and standardized.
… gimp_file_create_thumbnail().
One more case where "save" is misleading, and even more as it's not a
procedure where we control where an image is stored. We only say
basically "make a thumbnail which maps to this file according to my
platform's rules".
As a side fix, I also improved a bit the logic so that it allows @file
to be the exported or — as last fallback — the imported file.
And finally improve the function's docs.
Resolves #12753
gimp-fonts-get-list now returns a vector rather than a list,
so we needed to change calls for length to vector-length
and replace car with vector-ref.
Followup of the save/export difference, plug-ins can only register
"export" handler procedure (save handlers are registered by core). Also
rename _gimp_pdb_set_file_proc_save_handler() though it's private so it
doesn't matter much.
Now gimp_file_save() is a special case, because it can indeed "save" to
XCF or "export" to any other format. So I just leave it named this way,
but I make the function's documentation more exhaustive.
Not sure what I had in mind with the class method copy() in libgimp
GimpLayer. The core duplicate code already takes care of returning an
object of the right type. Also the GimpTextLayer implementation was not
a perfect copy (only text, font and font size were copied). Now it is
because, again, core has all the duplication code necessary.
Finally this makes this function visible to PDB, hence Script-Fu, again.
The PSD export dialog did not allow you to choose what metadata to
export, nor whether the color profile and thumbnail should be exported.
The metadata and thubmnail were not exported at all.
A recent commit changed this export dialog to GimpExportProcedureDialog,
which now allows us to easily add support for these types by
indicating we support these for psd, which is what this commit does.
When using GIMP_DEBUG=file-psd to have debug output in the terminal,
there are two issues:
1. When exporting there is a critical because nowadays we work on a
copy of the image, which doesn't have a filename attached to it, so
let's just remove this debug statement.
2. When loading the merged image, we do not load all layer resources,
since we don't need them. In this case it is expected that the layer
offset isn't at the end of the resources. We now skip writing this
debug statement in this specific case. The offset will be adjusted
in the lines below this.
The libgimp wrapper was just calling the PDB procedure. Get rid of the
wrapper and make the PDB proc public. Also reorder the name argument to
be in the second place, just like it was for the wrapper.
We had 2 flags to indicate that a PDB argument could be nullable:
null_ok and none_ok. That was a huge mixup and the PDB generation code
was using sometimes one, sometimes the other. Let's settle for only
none_ok.
This fixes a bunch of annotations.
Among other issues, this bug impacted exporting images with CMYK
simulation profiles. Because the image was duplicated for export, we
lose the simulation profile information after
gimp_export_options_get_image () is called.
This patch ensures the profile, simulation intent, and simulation
black point compensation toggles are carried over to the new image.
After the few specific args (drawable/filter ID, opacity, blend mode, op
name…), the op argument names can be passed either as string or with the
new argument name syntax. The error message though focus on argument
name type.
Also fix the argument count for the various possible cases (when
configuring with (gimp-drawable-filter-configure) or
(gimp-drawable-merge|append-new-filter), the start arg count is
different).
This syntax is now the official syntax for non-core PDB procedures.
I.e. that while core procedures will still use ordered arguments (e.g.:
`(gimp-image-get-layers 1)`), plug-in PDB procedures called from
Script-Fu will have named arguments in any order.
Say for instance that you want to call python-fu-foggify from Script-Fu.
Whereas we used to run:
> (python-fu-foggify RUN-NONINTERACTIVE 1 (car (gimp-image-get-layers 1)) "Clouds" '(50 4 4) 1.0 50.0)
Now we should call:
> (python-fu-foggify #:image 1 #:drawables (car (gimp-image-get-layers 1)) #:opacity 50.0 #:color '(50 4 4))
Now we can note:
* Every argument is preceded by a #:label which is the argument name.
This makes these calls much more readable (some plug-in procedures can
have dozen of arguments and these end up as list of integers, floats
and strings, which are hard to read and hard to debug) and semantic.
* Order doesn't matter anymore. For instance here, I put #:opacity
before #:color.
* As a direct consequence, we can drop any argument which we wish to
keep with default value. E.g. in the old style, we had to put the
#:run-mode, #:name ("Clouds") and #:turbulence (1.0) because we were
changing the last argument #:opacity (50.0). Now we can drop all 3
default arguments.
Having non-ordered argument is in fact the starter of this feature,
because it is already the case for calling PDB procedures in the libgimp
API (and therefore in all GIR bindings). By saying that the order of PDB
procedures is not part of the API, we actually allow to add arguments
and even to reorder them in the future without breaking existing scripts
in the 3.0 series.
This became even more serious when I was considering to make the generic
metadata arguments public. Since they are appended to the end, after all
plug-in-specific arguments, if I do this, adding any argument in an
export plug-in would break order. It won't matter anymore!
Note that it doesn't matter for core PDB procedures (where this syntax
is not used) because these are also C functions and therefore order and
number of arguments matter anyway. Also these don't have dozens of
arguments.
As a helper for Script-Fu developer, in particular as we already
released 2 RCs and therefore some people already started to port their
scripts, the old syntax will still work yet will produce a warning
showing how to call the same thing with the new syntax. For instance,
with the above first call, the warning will be:
> (script-fu:2059912): scriptfu-WARNING **: 22:54:47.507: Calling Plug-In PDB procedures with arguments as an ordered list is deprecated.
> Please use named arguments: (python-fu-foggify #:run-mode 1 #:image 1 #:drawables (2) #:name "Clouds" #:color '(50 4 4) #:turbulence 1.000000 #:opacity 50.000000)
Note that the argument name syntax is coming from the Racket scheme
variant: https://docs.racket-lang.org/arguments/index.html
Common Lisp has a similar syntax, either with just a colon, or also a
sharp + colon (it's unclear to me the difference, something about
interned vs. uninterned symbols).
After discussion with Liam on IRC, we decided to go with the #: syntax
of Racket.
A main consequence of this is that the Procedure Browser plug-in in GIMP
doesn't show now private PDB procedures. I was always finding this
annoying as their presence in the procedure browser would encourage
people to use these in plug-ins and scripts (even when sometimes we
added explicit description that these should not be used).
Now it's clearer. The procedure are much more hidden to plug-in
developers (and if they still use them, it's at their own risk,
especially of having broken plug-ins when we change signature of these
as they are not meant to be used, and therefore we don't promise
stability for these).
Core procedures are all the procedures created for libgimp basically. In
opposition, procedures created by plug-ins are not core procedures.
GimpProcedure class in libgimp now has a gimp_procedure_is_core() which
will tell you if a procedure is core or not.
Private procedures already existed, except that they were only marked as
"private" in libgimp (e.g. _gimp_font_get_lookup_name()) starting with
an underscore and marked as G_GNUC_INTERNAL. Now we also store this
information in the procedure object itself for reuse.
Certain cloud providers return a blobname
rather than the actual filename with
g_file_get_uri (). Since our code only checks
the suffix and extension of non-native files,
we received "Unknown File Type" when
trying to load images from those providers.
This patch replaces g_file_get_uri () so that
we get the display-name instead, which
should always have the extension. This
may be changed in the future when we
switch to a FileChooser portal.
This same pattern is also used on the
GimpThumbBox so we see the display-name
rather than the blob name.
Thanks to Khalid Abu Shawarib for the
additional information!
While testing an AppImage, I noticed a thick border around the
"Show All Files" in the File Open dialogue. This is because the
background color for the actionbar is not defined, and if the internal
padding is increased by the system theme, it's visible. Therefore
we define the color.
I also noticed that the GtkSwitch had a rectangle border rather than
a rounded one. This patch defines the border radius as well.
Using the app. prefix/group for the top menu works better for the
GIMP_GTK_MENUBAR variant of the menubar (which is what is used on macOS
to get the macOS-style menu).
The whole action group code should be reviewed and straightened up
eventually!
when creating a new image.
We add a new function `gimp_metadata_set_creation_date` to
`libgimpbase/gimpmetadata` to handle setting all relevant
metadata tags.
We add a local function `gimp_image_new_add_creation_metadata` to
add the creation date metadata to relevant functions that create
new images.
We write tags for both the creation date and several modified dates
for IPTC, XMP and Exif metadata. All these use different ways to
express date/time and timezones and I can already see we need to have
another look at other places where we handle modified dates.
This solves the second part of #7287, adding metadata about the
date/time a new image was created.
When starting from an image we created in GIMP, saving/exporting with
metadata and/or thumbnail (thumbnails are part of the exif metadata)
failed, because our metadata was not initialized for newly created
images.
To fix this, create a metadata object in `gimp_create_image`, that way
when creating a new image in the gui, but also when creating an
image programmatically, gets metadata attached at the start.
We need to do that here, because we need to have metadata available
even for images that we import that do not have metadata attached.
A flush happens when closing image displays, and with the idle code, it
means that the actual flush may happen once the image is already freed.
When I was saying that multi-threading is always full of surprises…
It became clear we need a RC3, mainly for 3 reasons (ordered with first
ones being more serious issues) for which I think more testing would be
better:
1. The changes in the image graph, regarding filters (#12614), and
possibly more than I am thinking of doing before RC3.
2. The change in multi-threading code for paint (#11389). I want to be
sure not to create new crashes (multi-threading is always full of
surprises!).
3. The change to a central plug-in API implementation (!2058) and I want
to make sure it doesn't bite us back with more testing (though it is
only for persistent plug-ins so it is fortunately not touching every
plug-in).
The fix is basically to make gimp_projection_flush() thread-safe, so
that it can be called from any thread.
The actual rendering was actually already run in the main thread since
it was in an idle function, but update_region could be touched both from
the main thread and another thread (e.g. the "paint" thread). An
alternative could have been to put some mutex to protect usage, but then
I realized that iter variable was also to be protected, and there was
some code where I am unsure if we had to protect larger parts of code
(in particular with gimp_projection_projectable_bounds_changed() which
was touching update region through gimp_projection_chunk_render_stop()
then directly). The nice headaches of multi-threading!
Moving the whole actual logic of gimp_projection_flush() in the main
thread seems much more robust and maintainable.
xgettext changed its default behavior since version 0.23 regarding
escaping of special characters into XML entities. Now we need to change
the gt:escapeRule value, differently depending on xgettext version (it
will fail in both cases with the wrong value, except the "wrong" value
is the opposite before and after).
This reverts commit 9b94e347bc.
I leave a comment though, because we are not 100% sure that the issue is
gone. In fact, the upstream report is still opened.
The good point is that on stable code, we only debug crashes by default,
while the specific hang we had was happening with debugging metadata
warnings. So hopefully we won't have random people reporting GIMP
hanging (only people explicitly trying to help debugging GIMP).
If the generated `gimp_welcome_dialog_n_items` variable
is 0, there are no release notes to show (likely because
this is a development version). Therefore, we don't create
the Release Notes tab in the Welcome Dialogue.
...trying to get index.
When changing images or detaching a Colormap dockable,
we may temporarily not have a selection when the GUI
actions update. This patch adds a check to confirm we
have a valid selection before trying to get an index
from it.
We validate arguments for a reason. This special flag must only be used
in special cases (when it's harder/not possible or not implemented yet
to validate properly).
In fact #12039 would have been much simpler to diagnose and debug if
this flag had not been there from the start, because we would have had
an error earlier, on core side, which we could have traced back much
more simply!
We had special code to pass around a special config object for some
filters but it was just looking if this first "non-standard" (after run
mode, image, drawables…) was an object and inserting the settings
object, which turns out to be NULL in most case (except for these
special filters from the filters_settings_actions list).
This is not right, first because we may override the default value in
such case, second because, even if this arg may be overrided later
depending on run mode, it is possible that this random other
(non-config) argument may not even allow NULL to begin with. This was
what was happening in #12039.
GIMP have its own hicolor in 'share/gimp/*/icons/hicolor' since 2.99.2.
Removing that package made no difference to the resulting AppImage and
I could not find any indication on our tracker about its necessity.
Committing every filter one by one had the same drawback as in #12614,
and as destructive effects in general: you have to go back to source
storage precision after every layer. This really shows its limits when
this precision is low (8-bit per component) and/or when the TRC loses
even more data (linear TRC in 8-bit is usually not a good idea) as shown
in the report.
So instead, use the render of the last active filter directly and switch
the drawable's buffer with it.
While it's normal to be limited to the storage precision at drawable
level, we want to have as high precision as possible during processing.
Two pieces of code were problematic in this regard:
1. GimpApplicator had a "gegl:convert-format" node which was converting
back to storage format after every effect. Instead only set this node
after the last effect.
2. "gimp:mask-components" operation was working with the input format.
Let's change this to work with the higher precision when comparing
input and aux format (typically when aux was the output of a previous
filter, now that we didn't convert format back to storage precision,
the aux precision may be bigger).
When creating a color widget in GimpProcedureDialog, we
were not taking into account whether the parameter's
has_alpha boolean was set to FALSE. As a result, all color
widgets allowed for transparency.
This patch checks if the GimpColor's GParamSpec has_alpha value
is FALSE, and if so, sets the color widget's type to
GIMP_COLOR_AREA_FLAT to enforce no transparency for that color.
Resolves #12719 and #12721
In b78f3dad, we assume that a filter is being created for a
single operation. However, certain tools like Bucket Fill might
pass a GEGL Graph node instead. This causes the call to
gegl_node_get_gegl_operation () to return NULL, which then
crashes when we attempt to get the Operation Class.
This path verifies that we have a single operation before
attempting to go further with getting its class.
Fixes: #11756
Context: Debian Bookworm only have GCC that links to MSVCRT C library.
Actually, crossroads is failing on our CI probably due to GCC-MSVCRT.
On Debian, there is GCC-UCRT too but it is marked as Experimental and
crossroad does not support it nor Clang-UCRT yet: GNOME/gimp!1860.
Some people reported crossroad working with GCC-MSVCRT in Fedora but
adding a brand new pipeline would be at least suboptimal to mantain.
So, we are temporarely moving from crossroad to quasi-msys2 project which
have UCRT support for both GCC and Clang (it takes compiler resources from
MSYS2). The compilers itself we will take from Debian Testing for parity
(they are standard GCC and Clang with proper CFLAGS set by quasi-msys2).
We may go back to Crossroad when it has UCRT support like quasi-msys2.
We always save the filter name in XCFs,
even if the user did not intentionally set
it. This means that "default" names like
Gaussian Blur are not translated when
saved and loaded in XCFs.
This patch adds a new property,
"custom-name", to GimpDrawableFilter.
It is FALSE by default, and only set to
TRUE if the user provides a custom filter
name (currently only possible in the
public filter API). Based off this value,
we either use the saved filter name or
get it from the operation when saving and
loading a filter from the XCF.
Resolves #12682
Some system themes add a gradient background-image to
text input and toggle widgets. On dark theme, this can
make the text unreadable if the background-image is a similar
color. This patch defines the background-image as none, to
prevent the system theme from leaking in.
What it was doing was casting the input buffer to another TRC, basically
pretending the data was what it was not. In particular, it was casting
linear input buffers to non-linear and all other TRCs to linear.
As was noted in #1958, this was in fact a useful trick, yet it's still a
trick. Basically when it's needed, it's either:
1. because the operation implementation does not work in the technically
correct space. Then the operation code should be fixed;
2. or because several work TRC are valid, then an option should be
proposed by the operation;
3. or for artistic reasons, which people are free to implement as
plug-ins or third-party filters, but it should not be a core GIMP
feature.
Therefore for most cases where it felt needed, the real solution will be
to improve the operations' implementations.
These were missing help ids and don't have tooltips either, while some
of these actions may not be clear to end users what they do.
This will allow us to have context sensitive help about these commands
in the manual.
This regression was added with MR !1551 (commit 7ccfad1716).
Localization was still working fine on the main processus, which made
the problem less obvious. But every plug-in would output such an error
on start:
> (border-average:257681): Gtk-WARNING **: 17:22:17.640: Locale not supported by C library.
> Using the fallback 'C' locale.
And the localization was indeed not working.
Apparently having a properly qualified locale, with both region and
encoding (e.g. "fr_FR.UTF-8") is fine, but any other contents was
breaking the whole locale.
Since it seems that this issue doesn't happen on Windows at all, let's
just not set LANG, except on Windows.
when loading an exr image.
While looking at the openexr fuzzed images I noticed we do not check
whether height or width are larger than our maximum.
Although this was caught in libgimp when trying to create the image,
let's add checks in the exr plug-in itself.
the offset to the dest buffer passed to the line-reading functions
wasn't counting bytes but items/values, which was slightly confusing.
Changed to not pass the offset at all, but rather a pointer to the
start of a line inside the buffer.
Also made rowstride count bytes, not values.
Made dest and rowstride local vars, as they are not used anywhere else.
that were written by older versions of GIMP.
The improved DDS reader that we got a year ago, caused us to be more
strict in determining what exact DDS format we are loading.
This causes failure in reading certain DDS images exported by older
versions of GIMP.
1. Both the A8 and A8L8 formats as written by GIMP, also wrote 0xff
in the masks of the green and blue channels, which should have been
set to 0, since they are unused. Because of this, they were not
recognized anymore by our import routine.
2. When the source layer didn't have an alpha channel, the BGR8 format
wrote a 24-bit format, which doesn't have any official representation
(only RGB8 exists). This also caused our import routine to fail for
this kind of image.
After updating our export in previous commits, this commit adjusts our
import routines to recognize and correctly load these images.
When the source image/layer didn't have an alpha channel, we were
exporting BGR8 as 24-bit B8G8R8, which is not an official D3D DDS
format.
For compatibility with other programs using DDS, let's instead use
D3DFMT_X8B8G8R8 which is 32-bit with the alpha channel being
ignored/set to 0.
See issue #12660 for more details.
When exporting a dds with types l8 or l8a8 we were also setting the
green and blue masks to 0xff instead of using 0 (since these channels
are not used for these formats).
See issue #12660
Set these channel masks to 0 to be more conforming to dds standards
and update our plug-in revision.
This is needed otherwise if we have a branch that relies on Debian testing and
other that relies on Debian stable their images would mix in the actual status.
When trying to load an exr type that GIMP can't handle we threw an
exception causing a crash of the plug-in.
This isn't very user friendly, so change this to show a less
disruptive error message that we can't load the image.
Removed "for reading" from the existing error message to better reflect
that it isn't necessarily always a problem reading the file.
Change the message for debugging proxy refs: say "DEBUG" instead of "ERROR".
This doesn't fix any logic.
The logic produces a spurious error msg often, scaring users.
The debug message can be seen and analyzed by devs.
Add a comment about what object proxies are normally reffed:
defaults for formal args of temporary procedures kept by persistent plugins.
Currently, we do not handle copying multiple channels.
The function call returns NULL but does not set an error
message - this causes a crash when we try to print out
error->message.
This patch changes the g_return_val_if_fail () call to an
IF statement, so that we can initialize the error object
with a message to prevent the crash.
It is not in fact a fix for #12640, only an improvement to our build
script, wrapping our calls to GIMP executables and outputting a
backtrace on a crash. This way, when people report issues during one of
the relevant calls, we may be able to diagnose.
It won't be useful for other types of failures (when the process doesn't
crash, but e.g. the script is wrong or other non-fatal bugs in GIMP).
The padding for image buttons on popovers like the layer lock
options was not defined. On system themes which set this padding
to 0px, it made it difficult to tell if the alpha lock was enabled
or not. This patch defines the padding to prevent this issue.
- Add Alignment for bitfields.
- BreakBefore*Operators: adhere to GIMP Coding Style.
- Align... AcrossComments: allows section comments in long lists w/o
disturbing alignment (e.g. the struct at top of bmp-load.c). Alignment
can still be reset with a newline.
It's very unclear who and when added that package to the deps list and if
it is needed to we bundle something more than the library (share/lensfun?).
Indeed, that GEGL op is reported to not work properly as a tool (2ba36733) and
have severe UX problems (#4695), being impossible to use even as experimental.
So, let's not install it to not bloat GIMP installation with not used code.
This seems to be a remnant of the time we custom builded libmypaint.
According to my tests, removing it from the list do not break build,
after all pacman auto installs it for being a libmypaint dependency.
When the user checks "Merge Filters" on interactive filters,
we move the filter to the bottom of the stack so it applies
directly onto the drawable (instead of merging the entire filter
stack).
However, we did not do this reordering for non-interactive filters,
resulting in incorrect output. This patch applies the same logic
so that when you apply a filter like Invert, it affects the drawable
only and does not cause problems for any existing NDE filters.
To contextualize: before, we used the custom Docker image for every
little thing (e.g. to compress docs), like firing a cannon at ants.
But this was changed, this "dep" is not needed since 876c709a.
According to my tests in our AppImage, 'libgs10' is enough. Indeed,
we use the Ghostscript library for over ten years (see 005b119f) so
there is no need to install 'ghostscript' package (which is bin-oriented).
We started to use !reference to rules as a workaround in a22393a6 to
merging rules with 'extends:', which isn't possible due to YAML spec:
https://gitlab.com/gitlab-org/gitlab/-/issues/213050
But simple extending, without merging, is totally supported by GitLab.
So let's clean our .yml since that workaround is needed in few places.
The About, Tips, and Welcome dialogues had Help IDs created,
but they were not being used on the dialogues themselves. This
meant there was no help button, and pressing F1 did not pull up
the help manual when pressed.
To be consistent, the Help ID was added to the gimp_dialog_new ()
calls for Tips and Welcome. Since About is not based on GimpDialog,
this patch adds it manually (after checking to make sure the user
has enabled help buttons in Preferences).
This patch also constrains the Tip dialogue's initial width to match
the About and Welcome dialogues.
The Previous and Next buttons have arrow icons. However, these
have not shown up on Windows since at least 2.10, as buttons
created with gtk_dialog_add_button () don't automatically make
their icons visible on all platforms.
This patch uses the existing "image" variable to store the icon
rather than passing it inline in gtk_button_set_image ().
This allows us to explicitly set it to be visible so it shows for
all users.
Our CI is complex, and while I and the maintainers know how it works by heart,
it can be very difficult for the others to understand it from the comments of
the .yml file. So, let's unify three separate sections into one for better QOL.
Since we use gimp_drawable_get_buffer () to get the
pixel data when composing or recomposing, NDE filters
were not being included in the final output.
This patch temporarily duplicates the layer, merges the
filters, and then retrieves the GeglBuffer from the merged
version of the layer rather than the raw pixels.
This patch adds CSS styling to define the color of the
underline/overline when dragging an item in a layer tree.
This prevents a system theme leak and keeps the color consistent
with the current theme's coloring.
Partially reverts change described in paragraph 2 of 9ab48164
Despite GIMP being built targeting to be relocatable, our
bundling script is very SLOW and pretty hard to make it
portable since it makes many ASSUMPTIONS (e.g. that all
deps are pre-compiled etc) which not always holds up.
These limitations could be fixed but would take time.
This was disrupting MSYS2 and crossroads builds, so
let's revert it being called by default for now.
This is needed for scripting output with 'gimp-console*.exe', which is
included in stable versions (but the user needs to change the .interp).
The need to manually change the .interp is ugly as hell (specially for
system-wide .exe installer and MSIX package) but a separate issue.
We were still calling palette.entry_get_color () rather than the new API
palette.get_colors(), which returns the full array of colors.
This patch updates the script to use the correct API.
Inno langs maintenance is semi-automatic since 21ffb589 and 4ec072ed
Right now, seems that everyone understands it, but who knows in the future?
So, just to make sure, being overly cautious, let's add one nice comment.
Following 4cbb9360
Most of the distros provides the dictionary pre-installed but
some like Gentoo not. So, let's bundle "share/libthai" for
maximum portability.
The only trace of reason for this dir being bundled was a pango crash: #2496.
Since the crash was gone, no other reason left, so it was discarded: c808d13b.
However, according to my tests, "word breaking" does not work without this.
(This is what thbrk.c#L22 source says but was never clear in our scripts).
So, let's bundle it with proper comments to make clear why this is needed.
Resolves #12623
Compose and Recompose are in the same plug-in.
When we converted compose.c to use GimpChoice in 7b29ac24,
we did so without checking if it was being called by
Compose or Recompose. As a result, we always overwrote
compose_type with 0 (RGB mode) on Recompose since it
did not have a "compose-type" GimpChoice property.
This patch adds a check to make sure we're not in a Recompose
call before trying to set compose_type from the GimpChoice
parameter.
This option is run by the CI and makes so that the test-file-plug-ins
plug-in is always installed in the CI, even on stable releases. But by
default, they are not installed on stable releases.
It was changed to "GIMP-continuous-ARCH.AppImage" because
I had hope of linking GitLab artifacts on gimp-web (which failed)
so let's use "GIMP-GIMP_VERSION-ARCH.AppImage" again.
Also, uppercase AppId 'Continuous' suffix to be consistent with Flatpak.
In particular, we could end up with mask of wrong bytes per pixel, which
was what was happening in the report.
This commit adds a new GimpDrawableFilterMask class because we needed to
implement a specific is_attached() method for effect masks.
Note: the file is added to POTFILES but the only localized string
already existed elsewhere. So this doesn't break string freeze.
Without this change, we could be using 5GB per job, which
makes the ccache too old so kills its purpose. Also, if
we consider the pipeline it could reach 10GB per runner.
So, let's limit the 'deps' jobs to 256MB, which should be
enough considering my tests and babl and GEGL coding pacing.
GIMP, however, needed way more in my tests, so I set 768MB.
Partially reverts e01973b9
This makes the AppImage .sh script multiarch aware and
make Debian pipeline a GL 'matrix' for easier maintenance.
As consequence, making an arm64 .appimage is pretty easy now,
so let's make one since this arch is not that rare in Linux.
Adding the mode and opacity arguments makes it very similar to
gimp_drawable_merge_new_filter() signature, but also to its own
Script-fu wrapper (gimp-drawable-append-new-filter).
It's just better to be consistent. Also if either of these args need to
be changed immediately afterwards, then we spare one additional
re-render for nothing (for instance in the PSD load plug-in!).
This patch loads legacy 'sofi' data, which represents
the original Color Overlay layer style. It also sets up
the ability to add the other legacy layer styles once
we've matched the right GEGL operations and properties.
Note that this can not read the modern descriptor format
for layer styles.
See: https://learn.microsoft.com/en-us/windows/win32/shell/app-registration#using-the-app-paths-subkey
Starting with Windows 7, Microsoft "strongly" recommends to install per user.
This still applies today for Windows 10: per-user is the default for our
MSIX installed from MS Store and for our .exe installer obtained by winget.
Note: this commit just change the "(recommended)" option in an Inno dialog.
Users can install GIMP in system-wide (admin mode) as always, nothing changed.
This is not a fix for #12359 yet, but an improvement to XCF loading.
When filters fail to load for any reason, we should still load the
layer. Only drop the broken filter.
I've tested lightly this removal. I don't think this code was really
needed or logical anyway, though maybe I am missing something because I
barely discover the existence of this "Image Selection" feature of dock
windows!
When loading a GimpConfig property for a filter, we assumed that
the string is always valid. This patch adds code to check if we read
in the string correctly - if we didn't (or if it was tampered with), we
don't try to deserialize an empty string.
The code to retrieve the alpha-variant of the indexed palette was wrong,
and therefore babl was creating a brand-new palette fornat. Not sure if
the palette was empty, or was random or anything. It's even weird it
even produced somewhat resembling colors.
This is useful right before releases according our release procedure:
https://testing.developer.gimp.org/core/maintainer/release/
Also, checking the variable content make the script more safe,
considering that in the future we will publish automatically from CI.
Filters with custom dialogues like Curves and Levels did not
have the existing filter set before being initialized. This meant
that if you have a different layer selected, editing an existing
filter would add a new filter to your selected layer rather than
editing the filter on its own layer.
This patch sets the NDE filter in the tool before initialization,
so that it can get the correct layer to edit and update the
filter settings on that one.
1. After discussions on IRC, we agreed that "A new perceptual blending
space was added in GIMP 3.0" was a nicer reason to display for
bumping the XCF version, because instead of focusing on fixes, we
focus on the new feature (a real "perceptual blending space" was
added for modes) and also because naming "perceptual" in some form
seems more helpful for people to figure out what is different.
2. Fixing sensitivity of the non-linear (formerly named perceptual)
actions when the blend or composite spaces are mutable.
In previous versions what has been stored/specified as perceptual blending or
compositing spaces has really been the non-linear variant of the images babl
space.
To maintain loading of old files, the code has been updated to actually mean
non-linear and a new perceptual value has been added to the GimpLayerColorSpace
enum, while preserving all old enum values.
This change bumps XCF file version to 23
As noted by Thomas Manni, editing NDE filters was still affected by
restrictions on existing layers, even if the edited layer did not have
those restrictions.
This patch alters gimp_item_tree_view_effects_edited_clicked () so that
it checks if the edited filter's drawable is visible or pixel locked,
rather than the currently selected layers. It also adds checks in
GimpFilterTool tool to verify an existing filter is being edited before
preventing certain operations.
This patch adds a gimp_color_wheel_set_triangle_locked ()
function which allows locking the rotation of the triangle
in the Color Wheel dialogue. Currently, the value is defaulted
to TRUE, to keep the triangle from rotating when the hue is
changed in the ring.
When searching backward, it will show '^^^' and forward 'vvv' instead of
'>>>' and also the searched text will appear next to the prompt between
parentheses. This makes searching a lot easier as we have clear feedback
of where we are at and what we are searching.
These are the common shell shortcuts for respectively searching backward
and forward in command history. I use the Python Console plug-in so much
for testing that it started to weigh on me on how ineffective it was not
to be able to search through the history and laboriously hit Up/Down
buttons instead.
While doing a search, most navigation keys would trigger to stop the
search (and stay at the current history item followed by whatever the
key was supposed to do, such as changing cursor position, etc.). Esc in
particular would just stop the search and do nothing else.
Ctrl-C though would reset the search and get the text back to what it
was before search started.
As a particularity in these NEWS, the changes for BMP are more accurate
in the NEWS file than in the commit because MR !1932 got mistakenly
squashed. For anyone looking to have even more details, they should read
the informative comments in the MR:
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1932/commits
In particular (gimp-drawable-filter-configure),
(gimp-drawable-merge-filter) and (gimp-drawable-append-filter) are
proper Script-fu methods.
I had to rename the PDB procedures for the 2 latter because they were
clashing with these wrapper. I had not realized that private PDB
procedures are still visible by Script-fu. This is not so glop. :-/
Right now, it doesn't look so useful compared to the -new- one-liner
variant procedures. But it will make sense when I will add aux input C
procedure wrappers.
It is this way possible to set a drawable as auxiliary input to a filter
in C and GObject-Introspected bindings.
Note that such filters can only be merged, not appended
non-destructively for the time being.
It can be reimplemented with (gimp-image-rotate) and
(gimp-item-transform-rotate-simple), with even more capabilities for the
latter.
The item rotate procedure is a bit more tricky though, since it takes
into account the selection. It means that either you want to just remove
the selection before (that's what I did here, because this script was
already losing the selection anyway), or you want to store the selection
(with (gimp-channel-copy)), then reapply it (very likely with
(gimp-channel-combine-masks)) at the end, after also rotating it
appropriately the same way as the image if needed.
For plug-in writers reference, these are equivalent:
- (plug-in-noisify RUN-NONINTERACTIVE theImage mLayer TRUE r g b a)
+ (gimp-drawable-merge-new-filter mLayer "gegl:noise-rgb" 0 LAYER-MODE-REPLACE 1.0
+ "independent" TRUE "red" r "green" g "blue" b "alpha" a
+ "correlated" FALSE "seed" (msrg-rand) "linear" TRUE)
Notes:
* When "independent" is FALSE, then you only need to set "red" (which is
equivalent to a "value" field) and "alpha".
* Original plug-in was using the second value ('g', a.k.a. noise_2 in
the PDB args) as alpha when the source drawable was grayscale. This
logic is meaningless now. Just set "alpha".
* The PDB procedure was wrapping the operation between
"gegl:cast-format" nodes to cast the input buffer to linear. This is
useless as the "gegl:noise-rgb" has already a "linear" argument
(defaulting to TRUE, but I specify it explicitly in this commit, for
clarity) which requests linear input when set.
For plug-in writers reference, these are equivalent:
- (plug-in-emboss RUN-NONINTERACTIVE img mask-emboss 315.0 45.0 7 TRUE)
+ (gimp-drawable-merge-new-filter mask-emboss "gegl:emboss" 0 LAYER-MODE-REPLACE 1.0 "azimuth" 315.0 "elevation" 45.0 "depth" 7 "type" "emboss")
Note: the last arg, emboss, must be replaced by a string, "emboss" when
it was TRUE, "bumpmap" when FALSE.
Similarly to "gegl:gaussian-blur", the call to wrap_in_gamma_cast() was
useless because "gegl:emboss" already sets its output format to linear,
as well as its input format (through GeglOperationAreaFilter parent
class).
GIMP_OFFSET_BACKGROUND doesn't exist since commit 2770cce833 and was
replaced by GIMP_OFFSET_COLOR + a specific GeglColor added in
gimp_drawable_offset().
For plug-in writers reference, these are equivalent:
- (plug-in-gauss RUN-NONINTERACTIVE image layer hblur vblur 0)
+ (gimp-drawable-merge-new-filter layer "gegl:gaussian-blur" 0 LAYER-MODE-REPLACE 1.0 "std-dev-x" hblur "std-dev-y" vblur "filter" "auto")
Note: the method arg { AUTO (0), FIR (1), IIR (2) } is transformed into
a string in lowercase. E.g. 1 becomes "fir".
At first, I was a bit annoyed by the wrap_in_gamma_cast() call which
converts the buffer to linear first, but looking at "gegl:gaussian-blur"
implementation, it is just a meta op to 2 "gegl:gblur-1d" which anyway
sets input format (to various formats, but always linear).
This legacy cast code must be a remnant from older times where it might
have been needed. Clearly it's not anymore.
This time, it's a Python plug-in, which is a bit more involved than C or
Script-fu usage (where we have variable args one-liner function) though
it's not too bad either. It's actually very similar (on purpose) to how
PDB procedures are run.
For plug-in writers reference, these are equivalent:
- (plug-in-threshold-alpha RUN-NONINTERACTIVE image layer threshold))
+ (gimp-drawable-merge-new-filter layer "gimp:threshold-alpha" 0 LAYER-MODE-REPLACE 1.0 "value" (/ threshold 255))
The main difference is that threshold arg was a [0; 255] int whereas
"value" is a [0.0; 1.0] double.
This commit also shows how to run filters in C plug-ins (file-ico here)
as a one-liner too, thanks to the varargs conviency function.
For plug-in writers reference:
- (plug-in-maze RUN-NONINTERACTIVE image active-layer 5 5 TRUE 0 seed 57 1)
+ (gimp-drawable-merge-new-filter active-layer "gegl:maze" 0 LAYER-MODE-REPLACE 1.0 "x" 5 "y" 5 "tileable" TRUE "algorithm-type" "depth-first"
+ "seed" seed
+ "fg-color" (car (gimp-context-get-foreground))
+ "bg-color" (car (gimp-context-get-background)))
Notes:
* FG and BG colors were hardcoded to current context colors. It also
means with the new API, you can use whatever else you want.
* The algorithm arg changes like this:
- 0 -> "depth-first"
- 0 -> "prim"
* multiple and offset args (the 2 last args) were bogus and were doing
nothing already.
In particular, I encountered some script-fu scripts calling some GEGL
ops with a seed, but this argument wouldn't be reproduced in the config
object. Technically it's just a uint. Let's just pass them as such.
For plug-in writers reference:
- (plug-in-edge RUN-NONINTERACTIVE image layer 2 1 0)
+ (gimp-drawable-merge-new-filter layer "gegl:edge" 0 LAYER-MODE-REPLACE opacity "amount" 2.0 "border-behavior" "loop" "algorithm" "sobel")
The warpmode (before-last) arg has to be replaced like this (types from
GeglAbyssPolicy enum type):
* NONE (0) -> "none"
* WRAP (1) -> "loop"
* SMEAR (2) -> "clamp"
* BLACK (3) -> "black"
For edgemode (last arg), just use the name value in lowercase as string:
{ SOBEL (0), PREWITT (1), GRADIENT (2), ROBERTS (3), DIFFERENTIAL (4), LAPLACE (5) }
E.g. "differencial" instead of formerly 4.
For plug-in developers reference:
- (plug-in-cubism RUN-NONINTERACTIVE image layer tile_size saturation 0)
+ (gimp-drawable-merge-new-filter layer "gegl:cubism" 0 LAYER-MODE-REPLACE 1.0 "tile-size" tile_size "tile-saturation" saturation "bg-color" '(0 0 0))
Now you can even choose the bg-color (not just an int/enum of black and
background color only).
For plug-in writers, here is how to replace it:
- (plug-in-c-astretch RUN-NONINTERACTIVE img drawable)
+ (gimp-drawable-merge-new-filter drawable "gegl:stretch-contrast" 0 LAYER-MODE-REPLACE 1.0 "keep-colors" FALSE)
Marshalled PDB procedures into script-fu can now convert a filter ID
into the proper object. For instance, here would be the code to append a
new gaussian blur filter to the drawable with ID 2 (with specific
settings), then making invisible:
```script-fu
(define filter (gimp-drawable-append-new-filter 2 "gegl:gaussian-blur" "hello" LAYER-MODE-COLOR-ERASE 1.0 "std-dev-x" 20 "abyss-policy" "none"))
(gimp-drawable-filter-set-visible filter FALSE)
(gimp-drawable-update 2 0 0 -1 -1)
```
I moved the code to transform scheme values into GValues depending on a
GParamSpec out of script_fu_marshal_procedure_call() into a shared
function script_fu_marshal_arg_to_value().
When calling gimp_drawable_filter_get_config() the first time, we don't
want the config's properties to be at default values, but instead to be
set same as they are on core app.
On further calls though, we don't touch the values, because they may be
out-of-sync until the next call to gimp_drawable_filter_update().
… gimp_drawable_filter_update() first.
Otherwise this is bug-prone. When people were to update the
configuration of the filter, they obviously intend this to be used when
appending/merging.
Also adding an example of using it in the C goat exercise, though I
leave it commented out because showing code for direct GEGL usage is
also of interest.
As a side update, I am adding proper support of the NULL or empty string
value for the filter name. In this case, the default human-readable
title of the operation will be used instead.
Without this, the filter order was right only when checking off then
then on the option, but the render was wrong when opening the filter
options dialog.
Similarly to the config arguments, the set functions are not directly
calling core. Instead they are queuing changes until
gimp_drawable_filter_update() is run.
It is now possible to sync the GimpDrawableFilterConfig with core.
Another (simpler on usage) possibility could have been to sync
automatically when a property is updated. But considering that some
filters can be quite slow to render (especially in real-life usage when
working on possibly very big files), and especially that on bindings
with no variable args, scripts will likely have to edit properties one
by one, it could make editing multiple properties very slow. Therefore
the chosen solution is that editing properties stay local on libgimp and
all changed properties are synced with core at once (with a frozen
render until the end for single computation) when calling
gimp_drawable_filter_update().
It was possible to set a GimpChoice property to a value out of the
allowed list. This got very likely broken when I re-parented
GimpParamSpecChoice to GParamSpecString which had a value_is_valid()
implementation, which was shadowing our custom value_validate().
This is fixed by now also implementing value_is_valid() for this param
spec type.
This is mostly an empty shell whose goal is to serve as base class for
specific dynamically generated per-operation subclasses, which will have
properties mimicking the arguments of the GEGL operation.
Most of the fundamental type args will just use the base GLib param spec
types instead of GEGL ones.
As a special case, the GeglParamEnum arguments are transformed into
GimpChoice param specs on libgimp side. The reason is that most of the
time, enum types are created within the scope of an operation code only
and cannot be properly reconstructed over the wire. I could just
transform these into an int type (which is mostly what is done in GEGL
right now when running an op with such arg), but GimpChoice allow much
nicer string-type args, which make much more semantic code. This class
was initially created for plug-ins, but it would work very well to run
GEGL ops on drawables. So let's do it.
Finally add a gimp_drawable_filter_get_config() to request the current
config of a filter.
Note that right now, we can't do much with this config object other than
observing an operation args and default values. Being able to update a
filter's settings will come up in further commits.
A few functions were added, but the main one is
gimp_drawable_get_filters() to request the list of filters applied
non-destructively on a drawable. We can't do much with these for the
time being, but this will come.
WIP.
Makes the Dock icon only appear when a script plugin has a dialog.
Unfortunately, on MacOS where "transient for" doesn't work,
we need a Dock icon for the separate process so user can "Show window."
See #12150
Done at runtime.
A build-time alternative is: package script-fu binary in a bundle, and set properties.
Fixes both the new-style dialog (GimpProcedureDialog) and the old-style dialog (deprecated.)
The gimp app and extension-script-fu (long-running)
are separate processes and "apps."
An app can be "active": in front and receiving GUI events.
As reported, on MacOS, when an extension-script-fu plugin yields,
the gimp app did not become active.
Also, on the second invocation of a plugin served by extension-script-fu,
the dialog could be hidden or require an extra click
because extension-script-fu was not active.
(Independently interpreted plugins did become active,
because it was a new process and gimpui_init activates on MacOS.)
On MacOS:
1. after the first dialog shown by extension-script-fu,
ensure subsequent calls to plugin make extension-script-fu active.
2. After a plugin yields, plugin manager ensure the Gimp app is active.
Note that this is done whenever a TEMPORARY procedure returns.
Most are calls to extension-script-fu plugins.
But some are also callbacks from Resource choosers running in the gimp app.
When they return, the gimp app remains active, and user must first click in
the plugin dialog to continue working.
Especially when the user clicks OK in a Resource Chooser, closing the chooser,
it would be nice if the plugin dialog became active.
That requires more, FUTURE development.
Special to MacOS: on Linux, "transient for foreign window" ensures this,
but that doesn't work on MacOS.
The fix is somewhat brute force and as simple as possible.
There is a more cooperative API for app activation on MacOS.
An app yields, and apps request, not force, self or other app be activated.
The fix does not use the cooperative API.
To do so would require a platform abstraction layer, in GIMP or Gtk.
The fix also sprinkles the code with #ifdefs.
That could be hidden if there were a platform abstraction layer PAL
The layer would be the greatest common denominator across platforms.
PAL methods would always be called in GIMP code,
but not do anything when the effect was accomplished another way.
For example "gimp_platform_request_app_active"
would request the app was active,
but do nothing on Linux where that is ensured by "transient for."
Previously, just hanging a read, extension-script-fu missed GUI events
that closed dialogs on MacOS.
The fix is a proper event loop for a plugin that persists, reads, and has GUI:
calling gimp_plug_in_persistent_enable and a main_loop,
instead of gimp_plug_in_persistent_process.
The fix is not conditional on MacOS, but seems events missed only on MacOS.
The previous fix for MacOS, #6577, only works for old-style GUI (script-fu-interface.c).
That was not the best fix, and doesn't work for new-style GUI (GimpProcedureDialog).
If symptoms still appear in 2.10.38
(#12150 says dialogs dissappear but a dock icon has spinning ball)
this should be backported to 2.10.
Partially revert f0fb4435
It is safer to wait for Inno to compile successfully before deleting the
.bak langs, which are the condition to auto repairing.
Note: I reinforce that, despite the name, this doesn't look like Vista.
Following de556c0734
Microsoft use of bezel in Win32 and UWP/WinUI3 apps is inconsistent:
sometimes the bezel is there, others not. However, when displayed
the bezel never is that dark. So let's at least hide it, just how
we do in the Devel warning and Inno do in most dialogs.
SSE2 (not the first SSE) instructions are required since 2012 on Windows 8.
Our minimum requeriment for 3.0 series is 10 so Inno built-in 'MinVersion',
by consequence, implies requesting SSE(2) without needing a custom dialog.
Then, let's cleanup this, which will make us gain a few (milli?)seconds.
Just to note, SSE2 (again, not SSE) is required even on Win 7 (since 2018).
This makes the range handles for the Levels tool and other
auto-generated range widgets adapt to any theme color,
just like the Gradient Editor range handles currently do.
It is like a compiler warning, and should not be a full g_warning,
which should mean something will probably fail.
Passing fewer args is a feature since 3.0: the PDB will use defaults.
This provides us fine-grained info on how much time each step take,
making easier to spot stuckness and to quickly understand the logs.
'gimp' jobs normally do not take advantage on this due to log limits
(they expand and crop the log), so I adapted them to only output errors.
---
Also, to reduce logs, all jobs were reviewed with proper GIT_* variables.
We were unconditionally using the selected layers' drawable
when setting up the filter tool's dialogue. As a result, it
would use the wrong drawable as the dialogue thumbnail if a
different layer was selected while editing an NDE Filter.
This patch checks if we're editing an NDE filter, and if so,
uses its drawable instead.
While we want to allow a flexible range for the
Box and Cylinder dimensions when called non-interactively,
having a large range in the GUI makes it difficult for
users to precisely set those values.
This patch adds calls to gimp_scale_entry_set_bounds ()
to match the 2.10 GUI ranges, while letting the values be
larger then that when called via the PDB.
When opening an old XCF, we try to match the fonts specified in the text
layers (and the text tool) with the closest font (if the exact font isn't available).
This patch improves the matching heuristic a bit.
Based on suggestions from Michael
Schumacher in issue #12239.
Until we implement native file picker dialogues,
Windows users can't load images from
Windows shortcut (.lnk) files.
This patch adds a plug-in to open these
.lnk files, extract the path, then try to read
it in via gimp_file_load ().
Similar to file-compressor, the error
messages are suppressed in the GUI so that
users don't get error messages if they click
on a non-image shortcut in the file picker.
Only export 1-bit TIFF for black and white indexed images without alpha
channel. 1-bit TIFF with alpha has poor software support:
- GIMP: cannot read its own exported files
- macOS Preview: ignores MINISWHITE/MINISBLACK
- Windows Photo Viewer: shows as invalid image
- InDesign: ignores alpha channel
- tiff2rgba: fails to process
- Photoshop/Illustrator: corrupted rendering
Any font file path that's invalid utf-8, and/or any metadata (psname,
fullname, family...etc) that's not valid utf-8 should be skipped and not
passed to fontconfig.
This issue has eluded us for a long time and it was recently fixed in
Pango (MR pango!745). We can't bump the minimum requirement because of
our bookworm baseline for GIMP 3.0.0, but we can at least warn when
building for macOS.
We still want the normal GIMP_RELEASE C macro to be set because the
whole development frame should have code behaving like release code, yet
only for the AppStream metadata testing, we want to allow a "TODO"
release date while in +git code.
While not an "official" tupl type for PAM files, software such as
mutools can export CMYK PAM files. This patch adds support
for loading such images.
Note that PAM files do not include color profile information. In
the future, we might add an option to convert using a pre-defined
color profile for this and other formats like EPS.
The "AppImage platform" don't have releases, every tool is blending edge.
Obviously, it is too prone to broke, and for the first time it got broken.
So, let's move it to a separate job and with less frequency to not broke CI.
Two tests were consistently timing out before this change:
save-and-export and ui. The gdk_test_simulate_key documentation mentions that
gtk_test_widget_send_key is the right approach for most testing purposes.
With this change, save-and-export started working for me, whereas ui now fails
properly - investigating this failure was the original point of the change.
Closes #12518
Certain Sony camera's have MakerNote tags in the Exif.SonyMisc3c range.
When exporting with EXIF metadata included this causes a failure saving
the metadata, which means that no metadata at all is saved to the image.
For now, let's exclude these tags, so that all other metadata tags at
least will be saved.
We will keep an eye on exiv2 issue
https://github.com/Exiv2/exiv2/issues/2670
to see if the actual cause will be solved.
A lot of the custom brand makernote tags have interpreted strings
available, even though their type is set to Byte.
Since having those interpreted doesn't have any negative side effects
(real Byte values are correctly converted) let's not exclude these
tags for interpreted string conversion.
Note: the original workaround was superseded by: 9ab48164
The actual workaround (which adress the same issue) is being dropped since,
according to my tests, seems that the MSYS2 issue was fixed. See: #10782
Inspired by Mark Sweeney's work.
This patch passes the user-defined button
icon size from GimpDisplayShell to
GimpStatusBar, and updates the
Soft Proofing button and current tool
icon sizes based off of it.
This patch creates a gimp_colormap_selection_colormap_changed ()
function that gets the new colormap count and updates the entries
and spinbutton maximum in the Colormap Selection widget.
Previously the palette view was being refreshed, but the rest of the
widgets in the dialogue were not being updated to match when a
new color was added.
The block size for layer info should be a multiple of 2.
We had erroneously thought it was a multiple of 4, based on what is used
for layer resources. But of course Photoshop is inconsistent and uses
a multiple of 2 here.
in gimp:offset filter.
Since gimp:offset is now an NDE filter,
always loading the background color from
context causes the color to change each
time the filter is redrawn. This is inconsistent
behavior.
This patch replaces the GimpContext
parameter with GeglColor, and updates
gimp_drawable_offset and related functions
to set the color directly. The libgimp version
loads the background color from context
and passes it on since the API is now
frozen.
Resolves #12478
There was existing code to scale the Lightness value of LAB
colors by 100 to match the 0.0 - 100.0 range used in babl.
However, it was not actually running because the `color_space`
value was not being properly cleaned before the comparison.
When loading channels, the alpha value is stored separately from
the RGB value as "opacity". After the switch to GeglColor, we were
overriding the opacity values by always using "R'G'B" format, so
the loaded opacity was always reset to 100%.
This patch pulls the opacity value before setting the color, then
restores the opacity afterwards.
Similar to 42300d9d, we want to prevent overly long color profile
labels from stretching out dialogues with GimpColorSelect too far.
This patch adds gtk_label_set_ellipsize () to both the color profile
and simulation profile labels, and adds them to a grid instead of
letting them free-flow.
The latest appimagetool inserts a runtime with static libfuse in the .appimage.
It also makes the .appimage run way faster and slightly better compressed.
Thanks for helping me with this, @samueru
This avoids calling host libs, fixing the last pendency on !1440 desc.
In other words, the AppImage now can be run, in thesis, in any distro.
Thanks for helping me with this, @samueru
Resolves #12468
In a2458f15, we converted xres and yres to gdouble since
gimp_image_get_resolution () requires doubles as arguments.
However, TIFFGetField () expects a float, and returns incorrect
values if a double is used as a parameter.
This patch converts xres and yres back to gfloat, and makes
new default_xres and default_yres variables as gdoubles to
use with gimp_image_get_resolution ().
We did not explicitly define the padding and margins for
the slider text and "progress" areas, which allowed for
system theme leaks. This patch defines these values and
makes the sliders visually closer to 2.10's style.
In 2.10, the "Layer Name" field in the Layer dialogue was
auto-focused (perhaps because it was the first field in the dialogue).
This patch restores this behavior so users can type the name and
press Enter/Return to continue their new layer workflow.
A patch was originally contributed by Andrzej Hunt in #11822 (cf.
0002-xcf-fix-channel-s-reference-counts.patch in the report).
The diagnostic of the double PROP_SELECTION issue is right, but not the
fix which was over-reffing, hence leaking channels and buffers, in the
normal cases, just to avoid double-free in broken edge cases.
The other issue is not possible though (unreffing the image's selection
when encountering an error in xcf_load_channel()) because we explicitly
check it it's the image mask AFAICS.
I added a second test which was not double-freeing yet which deserves a
bit of stderr messaging: when 2 different channels have PROP_SELECTION
set.
Relevant text from the commit message originally contributed by Andrzej
Hunt is the following (diagnostic and ASAN output still of interest):
----------------
xcf_load_channel creates a new channel using gimp_channel_new. This
channel has a floating reference (because GimpChannel is a subclass of
GimpItem, and gimp_item_init uses g_object_force_floating()).
Next, three different scenarios can occur:
- xcf_load_channel_props does nothing, and we either return channel, OR
in the error case we g_object_unref (channel) which frees channel.
The returned channel is either silently dropped (in the case where
it's already been set as the mask), or added to the image using
gimp_image_add_channel if not (which sinks the floating reference).
- xcf_load_channel_props encounters a single PROP_SELECTION. We create
a selection using gimp_selection_new (which again has a floating
reference), transfer ownership of the new selection to the image
using gimp_image_take_mask(), free the old channel, and finally set
channel to point to this new selection. Back in xcf_load_channel, IF
we hit the error case, we call g_object_unref (channel), which frees
the new selection - but we're still using it as the image's mask,
meaning we could eventually hit a use-after-free whenever someone
reads the mask.
- xcf_load_channel_props encounters 2 PROP_SELECTION's. After the first
PROP_SELECTION, channel is pointing to the image mask, which has
reference count == 1 (as explained above). When we hit the second
PROP_SELECTION: we create another new selection, followed by calling
gimp_image_take_mask() again. gimp_image_take_mask() call
g_object_unref() on the old mask, which frees it - but channel is still
pointing to this mask. We then call g_object_unref() on channel, which
is effectively a double-free.
We fix this by making sure to always ref_sink whatever object is put
into channel. gimp_image_take_mask also calls ref_sink, which means
we'll now bump the refcount up to 2 when the channel is being used as
the image's mask (and drop back to 1 if the mask is replaced, and down
to 0 when channel is unref'd).
See also ASAN output below from the 2x PROP_SELECTION scenario:
==6381==ERROR: AddressSanitizer: heap-use-after-free on address 0x6150000047d0 at pc 0x7fb5531ef31b bp 0x7ffe81e86cb0 sp 0x7ffe81e86ca8
READ of size 8 at 0x6150000047d0 thread T0
#0 0x7fb5531ef31a in g_type_check_instance_cast /home/ahunt/git/glib/_build/../gobject/gtype.c:4117:26
#1 0xb2346b in xcf_load_channel_props /home/ahunt/git/gimp/app/xcf/xcf-load.c:1742:41
#2 0xb1a3cc in xcf_load_channel /home/ahunt/git/gimp/app/xcf/xcf-load.c:2219:9
#3 0xb147eb in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:653:17
#4 0xb121bb in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#5 0x619ead in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:50:17
#6 0x51d414 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 0x507092 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 0x50d400 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 0x537452 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#10 0x7fb551e7c349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#11 0x4e0829 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
0x6150000047d0 is located 336 bytes inside of 504-byte region [0x615000004680,0x615000004878)
freed by thread T0 here:
#0 0x5e8612 in free /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:127:3
#1 0x7fb552d9ce08 in g_free /home/ahunt/git/glib/_build/../glib/gmem.c:199:3
#2 0x7fb552dc7a6b in g_slice_free1 /home/ahunt/git/glib/_build/../glib/gslice.c:1183:7
#3 0x7fb5531e7b04 in g_type_free_instance /home/ahunt/git/glib/_build/../gobject/gtype.c:2008:5
#4 0x7fb5531bfe3a in g_object_unref /home/ahunt/git/glib/_build/../gobject/gobject.c:3604:11
#5 0xd4d4d4 in gimp_image_take_mask /home/ahunt/git/gimp/app/core/gimpimage.c:3267:5
#6 0xb23438 in xcf_load_channel_props /home/ahunt/git/gimp/app/xcf/xcf-load.c:1739:13
#7 0xb1a3cc in xcf_load_channel /home/ahunt/git/gimp/app/xcf/xcf-load.c:2219:9
#8 0xb147eb in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:653:17
#9 0xb121bb in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#10 0x619ead in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:50:17
#11 0x51d414 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 0x507092 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 0x50d400 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 0x537452 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#15 0x7fb551e7c349 in __libc_start_main (/lib64/libc.so.6+0x24349)
previously allocated by thread T0 here:
#0 0x5e887d in malloc /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
#1 0x7fb552d9ccf2 in g_malloc /home/ahunt/git/glib/_build/../glib/gmem.c:106:13
#2 0x7fb552dc72e0 in g_slice_alloc /home/ahunt/git/glib/_build/../glib/gslice.c:1072:11
#3 0x7fb552dc78ae in g_slice_alloc0 /home/ahunt/git/glib/_build/../glib/gslice.c:1098:18
#4 0x7fb5531e6e0a in g_type_create_instance /home/ahunt/git/glib/_build/../gobject/gtype.c:1911:17
#5 0x7fb5531c215e in g_object_new_internal /home/ahunt/git/glib/_build/../gobject/gobject.c:1945:24
#6 0x7fb5531c1d1f in g_object_new_valist /home/ahunt/git/glib/_build/../gobject/gobject.c:2288:16
#7 0x7fb5531c0e8b in g_object_new /home/ahunt/git/glib/_build/../gobject/gobject.c:1788:12
#8 0xdb7260 in gimp_item_new /home/ahunt/git/gimp/app/core/gimpitem.c:722:10
#9 0xce1668 in gimp_drawable_new /home/ahunt/git/gimp/app/core/gimpdrawable.c:1067:14
#10 0xe283e9 in gimp_selection_new /home/ahunt/git/gimp/app/core/gimpselection.c:626:13
#11 0xb2342a in xcf_load_channel_props /home/ahunt/git/gimp/app/xcf/xcf-load.c:1735:15
#12 0xb1a3cc in xcf_load_channel /home/ahunt/git/gimp/app/xcf/xcf-load.c:2219:9
#13 0xb147eb in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:653:17
#14 0xb121bb in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#15 0x619ead in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:50:17
#16 0x51d414 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 0x507092 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 0x50d400 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 0x537452 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#20 0x7fb551e7c349 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:
0x0c2a7fff88a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2a7fff88b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
0x0c2a7fff88c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2a7fff88d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fff88e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c2a7fff88f0: fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd
0x0c2a7fff8900: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
0x0c2a7fff8910: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2a7fff8920: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fff8930: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fff8940: 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
==6381==ABORTING
( crash-c35bcae86d35ce7d0cd8ffcb41a470f37354e018 )
b9f81e1c broke CI because it is a CI-related change but not tested on CI.
Despite https://developer.gimp.org/core/maintainer/giving-developer-right/
not making previous CI test mandatory, it is reasonable to do, even the infra
being sick. That is not the first time our CI got broken by lack of testing.
Like in #11964 for Default theme, the nib handle for the ink
tool is invisible on the System theme. Fix this by adjusting
the solution in a4f9e7e89a for use with the System theme.
It seems any installation will have a lot of them (mostly because of
bitmap fonts which are now unsupported by Pango) and the message
startles people who believe there is something broken with GIMP.
Let's just not show this message on stable release builds, yet still
keep it on stable development builds (and all unstable builds, even
releases), because it is informative and keep us aware of this
limitation (which we hope to someday get rid of, i.e. get back support
of bitmap fonts, as well as any font format!).
My commit 0b792c22a4 was a beginner mistake as pdb/enums.pl is a
generated file. I also need to fix the source otherwise `git diff` will
always differe when generating the file.
Our CI in particular verifies that `git diff` is always empty so this
was breaking our gimp-debian-x64 CI job.
In activate_fractal (), we copy over preset Fractal values into the current
config object. Since "color-mode" is now a GimpChoice instead of an int,
this caused a crash when applied. This patch switches it to set a string in
g_object_set () rather than the original int.
In 9b917b8d, we defined the background and hover style
for the top menubar context menus. However, this did not
carry over to the menus for the on-canvas context menu.
This patch generalizes the CSS style so it affects both.
A regression introduced by a8b9bedf is that installing GIMP 3.0.0-RC1+git was
keeping GIMP 3.0.0-RC1 icon since an [InstallDelete] line was mislooked by me.
As a side note, to understand how the Windows versioning introduced by a8b9bedf
works, please read the latest base_gimp3264.iss file at 3.2.2 [Setup] section.
For this to work properly, I don't process them line by line, like all
other actions. Instead, I do a post-processing pass where I verify if
both variants were set, and if so, with an acceleration or with an empty
string. Indeed several cases are triggered:
1. We may migrate with 2 custom shortcuts on the same action;
2. we may mix 1 custom shortcut with one of the default shortcuts;
3. we may disable one of the default shortcut but not the other;
4. we may disable both shortcuts.
These were removed in commit 2c4f91f585, though I do wonder if this may
not have been a mistake since edit-paste and edit-paste-in-place are not
exact equivalent. They may still create floating items in some cases.
But that's good enough for now.
This is an improvement over commit ce2a9dc3eb which was only meant to
work for GIMP 3.0. This new code should work for 3.2 and any future
version too. It will try to migrate any configuration folder from GIMP
2.0 to whatever is the current version.
Should resolve #12436
Since we currently always apply filters with Aux nodes
destructively, we need to move them to the bottom of
the filter stack on creation. However, it's possible to have
the Preview checkbox unchecked when adding such a filter.
The current code does not add the filter to the stack until the
Preview is turned on. This can cause a crash when reordering
filters with Aux nodes, as they haven't actually been added yet.
Rather than duplicate code, this patch changes the code to always
apply the filters, then immediately set their visibility based on the
checkbox. This also adds a check to see if the filter stack actually
contains the filter before reordering.
This is a followup of previous commit. We must set the win_subsystem
option on executable() so that the result binary is compiled as a GUI
application (and doesn't output a console every time).
The previous commit is still needed and is what allows us to control
when to actually display a console.
This was a bug in the meson port which was not taking into account the
stable or release state of a build (unlike how it was in the old
autotools). The rules are:
* All unstable builds (release or not) have the console.
* Non-release builds in stable series have the console.
* Only release of stable series don't have the console.
* The RC of a stable release should behave as a stable release.
* compiler warned about terminating zero not copied
* removes all manual character counting
* static assert as a reminder that new string must be shorter, in case
someone want to reuse the code with different strings
Elide the underscore char from the blurb of the GParamSpec.
The tooltip remains redundant with the menu label.
We can't use an empty string (omit the tooltip)
because the blurb is also the description in the PDB Browser,
and the generated name of the arg is not descriptive.
FUTURE: let script author also declare a tooltip,
and a non-generated but unique name of the arg.
Change SF server to load /scripts, just like extensio-script-fu.
This restores SF server to v2 behaviour re:
1) the content of responses
2) the need for a run_mode arg in calls to scripts
Thus calls to scripts (submitted to the server)
are evaluated without a call via the PDB to extension-script-fu.
This means such a call yields the string repr
of the last evaluated expression of the script,
instead of the string repr of a call via the PDB,
which is #t since scripts are declared in the PDB as returning void.
This also means the run-mode argument is not required in such calls,
since it is a call to a run_func in Scheme, which has no run_mode arg.
This also means that the SF server will continue to run
even if extension-script-fu crashes.
A test is that a call to a simple "echo" script, installed to /scripts,
yields the same response from the server in both GIMP 2 and 3.
Resolves issue #12252
Unlike the layer and image commands for scale layers,
the Transform Tools use gimp_item_transform () rather than
GimpDrawable's scale/rotate code. Therefore, the filter's crop
was not being refreshed, resulting in the layer being cut off
after the transform.
This patch moves the gimp_drawable_filter_refresh_crop ()
code to gimp_item_transform () so that the new layer size
is taken into account in the filter.
027013c7 was fine but not good enough. Without this new commit,
if you stop the script after touching the Inno lang files and run
the script again it would not restore the patched lang files so
patch over patch, producing something like "GIMP 3.0.0 3.0.0".
So, this new commit identifies if the script wasn't completed and
repair Inno installation before applying the patches again.
Resolves #12403
gimp_filter_tool_set_transform_grid () is used to draw the on-canvas
transform grid for filters. It always assumes that the tool's selected
layer should be used to define these boundaries.
With NDE filters, you might be editing a filter on a different layer than
the actively selected one. This patch checks if an existing filter is being
edited, and if so, we grab the drawable from the filter rather than from
the tool.
In gimp_file_save (), we clear out the values
of any String parameters to prevent unexpected
results. However, GimpChoice is also a
String type. This causes the function to
fail because empty string is not a valid
option for GimpChoice.
This patch adds a prior check if the argument
is a GimpChoice, and sets it to its default
value instead to prevent this issue.
- Do not install Inno if it is already updated
- Delete unofficial langs after creating the .exe installer
- Ensure that all .isl files are kept as before the patching
This is an attempt to fix #12333 where from the look of the trace, the
segfault may happen if it tries to dereference a NULL view->priv->shell
whereas we have a view->priv->cursor_image. Even though I couldn't
reproduce, I'm wondering if it may possible to have no active image
display while the cursor is indeed hovering an image.
Furthermore this updated code is more logical anyway, because we should
use the "show all" value from the actual display shell the cursor is
hovering, not from the active display shell.
The welcome dialog creates a link to the release notes for stable
versions, but it also uses it for RC releases even if the
release notes for the final release haven't been written.
Check the version for "RC" to avoid creating dead links.
When we converted to GeglColor arrays in 6327d1b3, we
didn't adjust the call to gimp_gradient_select_preview_draw ()
that still assumed we passed in 4 doubles per pixel instead
of 1 GeglColor. This patch removes the division operation so
that we see the full gradient in the chooser button.
This replaces the GIMP_RGB_LUMINANCE () macro with
babl_process () to retrieve luminance from pixels
in GimpHistogram. This allows us to consider the
color space during the conversion, rather than assuming
sRGB always.
Resolves issue #12365
Per Kamil Burda, since we no longer have an array length parameter
for layer and channel procedures, the required minimum size of
procedure->num_args should be 3 and not 4.
...when drawable has alpha channel.
We always created GeglSamplers in RGB format,
but used the original drawable's format to create a
GeglBuffer. If the original drawable had an alpha
channel, this caused "glitchy" results since not
enough data would be copied into the new buffer.
This patch resolves the issue by making the format
match the original drawable's number of channels.
Resolves Issue #12362.
This was broken, see #12119. Now is fully bundled with DLLs and config, but
will not work on .exe installer because gegl have bugs: GNOME/gegl#394.
However, this should be bundled only in dev releases (due to "Debug" menu).
But not for 32-bit because MSYS2 doesn't provide 32-bit pango plugin for dot.
Fixes: #12351
In short, some time ago we were asked by a MSYS2 guy about the possibility of
they dropping pixbuf loaders and some of us said that we just need SVG/PNG for
UI. I tested and confirmed it so the debloating (c808d13b) kept only these two.
However, seems that was said in the same discussion that we also need others for
non-PAT pattern loading. After testing, let's bundle JPEG, GIF and TIFF loaders
following: https://testing.docs.gimp.org/3.0/en/gimp-concepts-patterns.html
BMP is already bundled for legacy clipboard (a4671d72) and will work here too.
PNG too, of course, otherwise GIMP UI wouldn't even load, as pointed above.
---
Other formats are supported by pixbuf but some can make patterns: unportable,
e.g. HEIC (my ponderation); or even buggy, e.g. WEBP (@ok ponderation). So,
let's NOT bundle all loaders like before the debloating, just the safe ones.
This finally makes our crossbuild scripts work like in all other platforms:
with GIMP_PREFIX separated from the system/MSYS2 prefix. Thanks, @Jehan.
For some reason this makes meson don't find only 'bzip2' headers provided by
the cross compiler so, in crossbuilds, let's use the ones provided by MSYS2.
Fixes: #4802 and #12148
This is needed to paste some images sent to Windows clipboard as .bmp.
---
Also, comment the reason to bundle the other loaders and the gio folder.
Since GimpUnit is now an object, if it's used in functions while
NULL it can cause issues. This patch initializes it to
gimp_unit_pixel () to remove the CRITICALs we received when
setting up rulers when "Show All" is enabled.
This file has stopped of being bundled in c808d13b as a consequence of a
bad practice of the past: not documenting the purpose of bundled files.
Let's bundle it again commenting the reason so the future generations can
understand why it is bundled: gspawn*-console is needed to open hyperlinks.
Of course, it does more than this, but one use case is enough to understand.
The warning "Couldn't export handle, unsupported windowing system" still will
be output on terminal since the fix (GNOME/gtk!7694) wasn't released yet.
---
Also, clarify commenting other bundled files and dirs in the bundling script.
Since the bug described on fbb484c5 is fixed, let's build them again
so we not mislook problems that could be present in vanilla Win builds.
Do not confuse with 'g-ir-doc', which is broken on Windows: #11200
This job fails because our test plug-ins isn't installed in stable or
release versions. However we are in a RC1 status which leaves stable
and release true.
Let's fix this by checking for "+git" at the end of the version string
and also installing our plug-in if that is found.
Intermediate RC versions used to be suffixed "-git" but gi-docgen
doesn't like this (or to be more accurate the packaging.version module
used by gi-docgen considers this an invalid version).
But it allows with a '+' (it calls it the local version segment). So
let's go with this new formatting.
Adds GIMP_MUTEX_VERSION var to make possible to change the way we handle
multiple GIMP installations without needing to manually change parts of
the script to MAJOR or GIMP_APP_VERSION like a zoombie.
Also, this reorganizes some sections of the .iss file (for the third time)
and make LZMA multi threading the default even for stable builds.
979a3c3c assumed that all bumpmaps in the Lighting Effects plug-in
would have an alpha channel, which is not always the case.
This patch adds a check via gimp_drawable_has_alpha (), and sets the
babl format accordingly.
Not sure why, but previous RCs' versions were written all lowercase and
with a tilde separator, so I just used the same syntax, but that won't
fly with how we will write it in the main meson file. So let's do a few
string fixes to make both syntax match.
We are very likely releasing on Monday 4, and not even now but after a
good night. The whole Gitlab infrastructure is clearly half-borked right
now, we are constantly waiting for runners, sometimes we get random
error 500 when loading Gitlab pages, sometimes some stuff get stuck on
display and we need to refresh.
Not only this, but the Flathub infra is also broken (I believe it's also
hosted by GNOME?) and all our builds are either failing or sometimes
going further then failing at "Committing builds" or other steps,
usually with some HTTP error.
It's not the wisest idea to make a RC1 release in such condition.
There were 2 issues:
* The tag needs to start with the project name in uppercase.
* For GEGL repo, the last item was some very old tag. Make a pattern a
bit more accurate (though it's only glob, so it's not that accurate
either, but hopefully will work out in future too).
Every artifact from our CI have a pretty name with some reason for it:
- Installer: it is this way on download.gimp.org since ever(?) and that's fine
- Store: follows Microsoft de facto spec of .msix files naming
- AppImage: follows AppImage draft spec of .appimage files naming
But the .flatpak just looks like AUR pkg. So, let's use reverse DNS
naming which is used at least for .flatpakref files. This makes more sense.
While they work well, the gegl_node_get_bounding_box ()
call causes the entire filter stack to refresh
each time we need to update the filter stack.
This slows down rendering significantly.
For 3.0 RC1, it's better to have good performance
and deal with the less common crop
issue for now. We'll work to find a better
performing solution for 3.0.
On Windows, it will basically be a copy of the main binaries. On other
OSes, it will be symlinks.
This will help for Windows installers where we want to use major version
only in registry and we need a binary named appropriately for this
apparently.
As for the "major" version, I will in fact use the next major when minor
is 99 (also called API major version), not that it will matter much very
soon!
… legacy to gegl parameters.
This commit removed 57 legacy PDB procedures which were replacing
outdated plug-ins (before transformed into GEGL ops) as far as I
understand.
These were all kept only as a legacy compatibility layer for third-party
scripts. Since we are breaking API anyway, let's remove as many as we
can. I've only kept the few which are still used at least once in our
core scripts or plug-ins.
Now as pippin notes, we still have no easy way to quickly run GEGL ops
on drawables in script-fu. Though we have at least access to GEGL API
for C plug-ins and all GObject-Introspected bindings. But that's true
for all other ops anyway.
I guess what should happen (quickly-ish) after 3.0 release is a libgimp
utility function which does the heavy lifting of creating a GEGL graph
for us, and for script-fu probably a special-case binding or something.
I realized it is redundant with gimp_fonts_get_list() which is a bit
more complicated to use but also more powerful. Let's see if we ever
need the simpler utility function in the future.
- s/gimp_buffers_get_list/gimp_buffers_get_name_list/
- s/gimp_context_get_dynamics/gimp_context_get_dynamics_name/
- s/gimp_context_set_dynamics/gimp_context_set_dynamics_name/
- s/gimp_dynamics_get_list/gimp_dynamics_get_name_list/
Named buffers and dynamics don't have their own classes. Using
*_get_name_list() will make sure that *_get_list() is available so that
we have constant naming if we add the new types, even during the 3.0
series. Same for the gimp_context_*() functions.
Note that the buffer API in particular has a few more functions which
we'd like to be able to reuse (e.g. gimp_buffer_rename()) with a proper
type. But we'll probably name this type GimpNamedBuffer anyway
(GimpBuffer is too similarly-named with GeglBuffer IMO) so it will be
easy to create new API for the new type.
See also #12268.
There are 2 *_get_list() for buffers and dynamics but since we don't
have clases for these, they still just return a list of names for now.
I opened #12268 for further thinking on these.
In a28b1bad, we ported the darktable detection code to use their
new API for darktable 4.6.1. However, the image and thumbnail loading
code was not ported as it still worked fine in that version. This patch
continues the port by making the the image and thumbnail functions
use the new API if darktable 4.6+ is installed.
Fixes: #12237
We were building with that option disabled here because it was making our
runners to randomly fail at building it. However, that option disabled also
makes some machines to fail, due to its low-level nature. So, there is no
fix for it(?), let's enable then and hope the runners willn't fail again.
Despite building GIMP with Clang helped a lot to make our deps builds robust,
it is very hard to maintain, not because of LLVM but because of freedesktop.
We needed to ensure that the branch of LLVM matched the one of freedesktop on
which GNOME SDK is based. That stopped to work resulting on bad inconsistency:
1) flathub never had a problem; 2) GNOME runners sometimes worked, others not;
3) locally it stopped to work completely, so the .json right now is unportable.
Some annoying bugs were:
- "error: Requested extension *llvm* not installed"
- "Similar refs found for *llvm*"
So, let's end this not using any extension anymore while keeping only the nice
improvements in the custom builds.
GNOME docker image and Flathub runner seems to use edge flatpak-builder,
which auto set -DCMAKE_INSTALL_LIBDIR option, crucial for some deps.
Pre-1.4.3 versions don't do this so the build fails in some machines.
Let's prevent this making the script more clear about flatpak-builder.
...with gtk_icon_theme_add_resource_path (). Per Wormnest in !1027, this function
might not even be necessary at all. But until removing it can be completely tested,
this patch at least removes the deprecation warning for GIMP 3.0 RC1.
Pelican did not like a quoted date and produced an error. Not sure what
changed, because pretty sure this output used to work fine, but…
whatever, let's fix it.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
Like GIFs, Amiga IFFs can have pixel aspect ratios that aren't 1 to 1.
We have a warning for users when they load these kind of IFFs, so
they know to switch Dot for Dot mode off.
However, unlike GIFs, we don't have a thumbnail loader for IFFs.
So, this warning pops up even when users are scrolling through the
file dialogue. Since many Amiga IFFs have alternate PAR values, this
means a lot of pop-ups. This patch adds essentially a "dummy" thumbnail
procedure so we can stifle this warning unless we're actually loading
the IFF image.
So this one is a complicated beast, because inside the flatpak's
sandbox, ~/.var/ will not be the same as on the host (even with home
permission). In particular, we won't be able to find the 2.10 config folder in
there when running GIMP 3.
Yet local ~/.var/app/org.gimp.GIMP/config/ is in fact be mounted to
/var/config/! So inside the sandbox, this is where we must look in to
find a previous 2.10 config folder.
With this change, both flatpak and non-flatpak GIMP should be able to
find a 2.10 config folder both in the host XDG_CONFIG_HOME and inside
~/.var/ by:
* First looking inside XDG_CONFIG_HOME;
* Then looking in ~/.var/app/org.gimp.GIMP/config/ (which in non-flatpak
environment will find a former flatpak config folder);
* Finally looking in /var/config/, but only is /.flatpak-info exists (so
we are in a flatpak, and in there, this is the mapping for the host
~/.var).
This is not tested inside the flatpak sandbox yet.
This was bothering me that we were keeping these macros marked as legacy
in our public headers. Now they aren't so we can delete the whole file
when we'll finally get rid of all usage later, without breaking API.
The param option just contains an options object, not a separate
capabilities. Also even when passing the options object across the wire,
the capabilities within this object are not part of the "options". These
are actually handled separated by GimpExportProcedure.
Therefore the changes are:
* GimpExportCapabilities moved to gimpbaseenums.h with a proper GType.
* "capabilities" properties are changed to flags param spec with type
GimpExportCapabilities.
* GimpParamSpecExportOptions doesn't have a capabilities variable
anymore.
* Consequently gimp_param_spec_export_options() doesn't have a
capabilities arg.
* Wire protocol updated as we don't need to pass any capabilities
neither for the param definition, nor for the argument values.
* GimpExportOptionsEditFunc renamed GimpExportGetCapabilitiesFunc and
returning GimpExportCapabilities flags, instead of setting the
"capabilities" property. I believe it makes it much more obvious what
this callback is for and how to use it.
* Annotations improved or completed.
* Don't make the GimpParamSpecExportOptions public anymore since it is
the same as its parent.
The whole widget was made deprecated in 2006 (commit 99f979e118) but it
is still being used by another widget. Since we can break API, I at
least hide the functions and type by making these private.
This will give us time to think if we really need this widget (or a
nicer implementation for this widget) or if we just want to get rid of
it.
This patch adds additional error handling
to the BMP plug-in. It also translates certain
variable names from German to English,
replaces magic numbers with existing
constants, and simplifies some formulas.
* Don't mention 2.99 anymore.
* GIMP_PKGCONFIG_VERSION was actually the version of libgimp regarding
our .pc file, not our pkg-config requirement (per the commit removing
autotools scripts). Now it looks like our pkg-config minimum
requirement used to be version 0.16, but I didn't add this check back.
Let's assume just saying "a recent version" in the INSTALL file is
enough, without hard-check in meson.
* Simplify the end part about failed configuration or optional features,
with a link to our build tutorial online instead of getting into
details and advices to set LDFLAGS or CPPFLAGS (which to be fair, am
not sure are very good advices at all in fact!).
* Fix a few more details.
Currently the search feature in the Layer dockable is also visible on
the Paths and Channels dockable as well. However, it has hardcoded
strings that refer to layers, and it uses gimp_item_list_get_items_by_substr ()
which only works on layers. We should hide it for 3.0RC1 and implement
it for the other two ItemTreeView children afterwards.
I'm surprised that Idriss and Shubham were not already in the file!
Also adding Denis for his design work, and Sevenix for the splash
screen.
Bruno was added for the awesome work in packaging and CI. Even though
it's not GIMP itself, it definitely counts as code and original work.
I didn't add the new GSoC contributors because Varun's work is
essentially in GEGL (which has its own credits) and there was no major
original feature pushed by Cheesequake unfortunately, only bugfixes. So
I'm unsure if we can add them.
While the work on NULL-terminated array types make it much easier in C,
bindings don't have enough information to create native array/list types
in some generic functions such as g_object_get|set(), or else we just
don't know the right annotations to use for this to be possible. This is
report gobject-introspection#492.
So for the time being, we are creating dedicated functions for GeglColor
arrays and for other core object arrays (arrays of images, items, etc.).
E.g. in Python, while you can set a single GimpImage like this:
> config.set_property('image', image)
… you need to set a list of images like this:
> config.set_core_object_array('images', [image1, image2])
Checking the log, it looks like this code has not been touched since
2007, so whatever this various was used for, it's clearly not been used
for a long time.
Fixes warning:
> libgimpwidgets/gimpcairo-utils.c:80:16: warning: variable 'total_length' set but not used [-Wunused-but-set-variable]
Fix warning:
> plug-ins/file-dds/dxt.c:113:1: warning: unused function 'pack_rgb565'
I don't just remove it as I guess it may be of use at some point for a
not-yet fully implemented feature yet?
Avoid the stack smashing bug from yesterday in other functions.
Additionally to fixing other functions, do not cast the pointer to size
in the PDB generation scripts so that we can quickly spot such bugs in
the future, through compilation time warnings, instead of hiding them.
Currently there are 5 separate plug-in-gauss
functions. IIR2 and RLE2 are not used, and
IIR and RLE are identical to each other.
Additionally, they all call a separate
gaussian_blur () function which multiples
two parameters by 0.32 to convert to the
actual GEGL operation.
This patch removes all functions except
for plug-in-gauss. It converts each
existing script that used one of the other
variants to use plug-in-gauss, and
multiples the coefficients by 0.32 so that
plug-in-gauss behaves the same as calling
gegl:gaussian-blur with a C plug-in.
There also exists a plug_in_pixelize2 ()
function in the PDB which allows the user to set
both the pixel width and height.
This patch converts this to become
plug_in_pixelize (), and removes the older
function which used a single width
parameter for both values.
When linking with clang/lld, I had the following linking error:
> ld.lld: error: undefined symbol: pow
As a side change, also adding math.h header include, even though it
didn't seem to break compilation. Just to be thorough.
Additionally to fixing a deprecation, I also ensure that we don't limit
pointer source to what the system considers the "Core Pointer" on
Wayland.
It is another bug similar to #8016 and possibly what !924 was trying to
fix, even though it turned out this was not the same problem which I
initially reported. In this other variant, when you were hitting Space,
it would originate from the "Core Keyboard" which was associated to a
"Core Pointer". On a laptop, this Core Pointer could be the trackpoint
for instance (in my case) so you could pan with Space + trackpoint move.
Yet say you add a graphics tablet, which is a separate pointer: you
could not pan with Space + stylus move!
Now you can, because when we are pan-spacing, events from all pointer
sources are accepted. Only when the panning comes from a pointer source
(middle click) do we listen only events from this same pointer device.
This reverts commit 413cf9ad85.
As discussed with mitch during last Wilber Week, and commented in !924,
the fix was creating new problem and was not right. We definitely want
to grab pointer events when panning (or other similar interactions).
Also I think I had not tested under Wayland back then, only verified I
didn't see any huge issue on X11, but the commit did not in fact fix the
original issue #8016 (this time, I verified!). The problem I was
encountering seem to be more in how Wayland works + libinput, not giving
full control on input devices to applications and trying to be "smart"
with an option ("Disable Touchpad While Typing") which is often useful,
but other times counter-productive (e.g. in GIMP when we want to
space-panning — which should not be considered typing —, or again
shortcuts in video games, and so on).
When the passed code had a bug, the plug-in was crashing along with the
code given in argument. Instead, we must catch all exceptions and pass
the error message raised by exec() to the core application.
Since commit 4e499810, GIMP could crash on switching to
multi-window mode on X11 Linux systems.
As suggested by Alx Sa it is enough to add a NULL check for
shell to avoid the crash.
From now, Windows contributors can use the default shell provided by the OS
(which is PS since Windows build 10.0.14971.0), like Linux and macOS users do.
We still use MSYS2 but not the POSIX shell. This change adds these features:
'1_build-deps-msys2.sh' is now '1_build-deps-msys2.ps1'
- Faster clonning by using 'git-scm' (the MSYS2 one had performance problems)
- Easier to use non-MSYS2 binaries, not only 'git-scm' but also official meson,
deps from vckpg etc. This is a needed step towards the future use of MSVC.
'2_build-gimp-msys2.sh' is now '2_build-gimp-msys2.ps1'
- By default, vanilla builds (normally triggered on PS) will create a bundle,
dropping the need of 'gimp.cmd' (that adressed .typelib and .interp limits),
which is inline with other (Cmake-based) projects like Darktable and Inkscape.
This change is important because even Windows devs more experienced than me
get confused with the relocatibility stuff, which is the default on Windows.
'2_bundle-gimp-uni_base.sh'
- As a result of the change above, bundling code was changed to be a bit faster.
It still is, however, painfully slow, since meson doesn't have a 'install()'
function like Cmake to prepend targets in Ninja's 'install_manifest.txt'.
Since we are not using a POSIX shell (nor 'mintty') anymore:
- GIMP can be built from every path easily with R. Click "Open Terminal", with
IDE integrations etc, without needing to manual tweak MSYS2 .ini files etc.
We could tweak MSYS2 to get the features above but not top-tier integration.
- Developers can be more aware of Windows native vars, paths etc, and avoid bugs
Some build files were improved to support the 'Windows way of doing things'.
- No need to close and reopen terminal anymore after running 'pacman -Suy'!
---
REGRESSION: Vala plug-ins are temporarely gone due to 'vapigen' bugs, a small
regression since this is a gnomeish language but I will investigate how to fix.
In 41894be7, GIMP_COLOR_PROFILE_POLICY_KEEP was accidentally
used instead of GIMP_METADATA_ROTATION_POLICY_KEEP as the
possible output of gimp_image_metadata_rotate_dialog ().
Fortunately they are currently the same value, but it would be best to
return the right enum type.
GimpControllerEditor's "Select Controller Event Action" dialogue has
a border around the standard icon. This is because it uses a GimpViewableDialog,
which normally shows the current image or layer as the right side icon (and thus
needs a border to potentially distinguish).
Since this is a special case, this patch retrieves the GimpViewRenderer for the icon
and then sets the border color to transparent.
After we converted most scripts in the repo to use new registration functions,
there are no *filters* left from version 2.
But version 2 filters are still supported, with a warning
to the console like "image procedures ... only one drawable ... are deprecated."
A version 2 filter uses
the deprecated registration function script-fu-register
and declares args img and drawable (singular) explicitly
(contrary to encouraged multi-layer capable.)
Until we actually obsolete scripts of this ilk,
we need this test plugin for testing.
Resolves #12226.
GimpGradientEditor's saved_color array was
converted to GeglColor as part of the color
space invasion. However, we were still
treating it as if it was a GimpRGB array, so
we'd use gegl_color_set_pixel () to convert
it for gimp_action_group_set_action_color ().
This resulted in the menu displaying empty colors.
This patch removes the unnecessary conversions
and passed the saved_color values directly so that
they show up in the menu.
Per Lloyd Konneker, all Python plug-ins except
histogram-export and gradients-save-as-css
have "python-fu-" in front of their name.
In fact, gradients-save-as-css does have
this prefix in some places already.
Since this is also how it was written in 2.10,
let's rename them now to be consistent.
As reported by Anders in !1919. This is because
gimp_pdb_execute_procedure_by_name() now expects a proper GimpArray for
float and int arrays, not a C array preceded by a size value.
Generated libgimp functions' arguments are normally tested through the
PDB, so that you get proper error messages when trying to call a
function with invalid arguments.
This is not true anymore for array arguments since the size argument is
not a PDB arg, only in the C function. Therefore I'm adding an
infrastructure asserting on invalid size, using the same PDB type
annotations as other args. It is important to assert valid input on
plug-in side (i.e. libgimp) so that the core doesn't make any assumption
on having received valid input when it has not.
Also changing size argument of gimppainttools PDB-generated functions to
proper gsize.
Yet they still are generated libgimp functions' arguments.
For instance gimp_context_get_line_dash_pattern() still has a num_dashes
integer argument and a dashes C array, but when calling the PDB
procedure "gimp-context-get-line-dash-pattern", we only set the
GimpArray.
This will allow simpler direct PDB calls too, included in script-fu,
where the size argument is really redundant.
GimpArray (and therefore the int32 array typedef) contains its own size.
We don't need to store the array size in a preceding argument.
Also adding gimp_int32_array_get_values() and gimp_int32_array_set_values()
to edit an existing GimpArray.
This comes with the fact we should start making the GimpArray type more
explicit, because clearly by trying to hide this type so much, it was
too much looking like the int32 array param spec was expecting a C array
(as was visible in the file-ico plug-in where we were getting a C array,
which was a bug only made invisible by the fact we were not setting the
C array back in the config object in the end).
Last but not least, I finally implemented int32 array (de)serialization.
As a side fix, the "images" arg in file-pdf-export-multi procedure is
now a proper image array (not an int32 array), and of course the "count"
arg was removed.
PDB code is now looking directly into the GimpArray length for
determining the data length.
Also adding a 'size' argument (number of elements, not bytes) to
gimp_value_(get|dup)_int32_array() to make it actually introspectable.
Until now, it was somehow introspected but was segfaulting on run.
I.e. that, e.g. in Python, calling Gimp.value_set_int32_array(v, [1, 2, 3])
followed by Gimp.value_get_int32_array(v) would actually make a
segmentation fault. Now the binding works flawlessly.
This will also make these functions much more usable in general.
… PDB type.
This is a first step for #7369. Clearly our GimpObjectArray was meant to
be used with C arrays, hence the wrapper function
gimp_value_set_object_array() which was taking a C array and actually
creating and setting a GimpObjectArray.
This is why our new type is actually a C array aliased as a boxed type
and containing its own size (thanks to NULL-termination).
Eventually GimpCoreObjectArray is meant to replace GimpObjectArray.
The only issue is that such a type does not allow NULL as a valid
element in such an array, but fact is that I don't think we currently
have any use case where this matters. If ever such a case arise in the
future, we may introduce back GimpObjectArray.
In this first commit, I replaced all itemarray PDB types with a new
drawablearray using this new boxed type when relevant.
For some symbols defined or deprecated in GIMP 2 and obsolete in GIMP 3.
ScriptFu automatically loaded these definitions
during development of GIMP 3 (from 2.99 to 3.0rc1).
That is no longer the case.
A third-party script CAN load them explicitly.
We discourage that, for scripts to be shared,
but it is convenient for private use.
PDB-compat-v2.scm is also an executable definition of renamings,
useful as a cross check of published documents re porting plugins
from v2 to v3.
So an editor recognizes them.
Renames script-fu.init to init.scm since that is a Scheme convention.
Scheme interpreter maintainers expect that name.
The same name as upstream TinyScheme.
When mingled with plugin scripts, they needed a non-standard suffix .init.
Which makes an editor not recognize them.
Which deviates from Scheme convention for the main init script: init.scm.
The separate directory is also a place for script authors
to put Scheme scripts they don't want loaded automatically,
but when a script calls Scheme load function.
No change to observable behavior in the app or ScriptFu tools.
This is rarely done.
Most script plugins call PDB functions that are GIMP INTERNAL (gimp-foo)
or filter plugins that wrap Gegl filters (plug-in-foo).
But a Scheme script plugin can call other script plugins (script-fu-foo).
When a script does call another script,
it can be within the interpreter (purely in Scheme),
or to an interpreter in another process (via the PDB, with binding.)
It can get complicated using the optional v3 binding of return values.
This tests and illustrates different cases.
Mostly one word substitutions.
A few function definitions were moved to the scope of
a single script that used them.
Those functions won't be available to third party scripts
except now by cut and paste.
For major release 3.0.
When the function is not trivially substituted with a call to a Scheme R5RS function.
In other words, compatibility definitions that are not just an alias from SIOD to R5RS
Scheme dialects.
The prior removal was based on comments in the code,
saying the functions could easily be removed.
It turns out the functions are used in the repo, and not easily replaced.
Third party scripts may suffer the same dilemma:
use SIOD functions that are not trivially replaced.
This commit only fixes the dilemma for the scripts in the GIMP repo.
Reverted and kept:
*pi* symbol for math constant
cons-array an obscure function of unknown origin
butlast a function in some Scheme dialects but apparently not in R5RS
These MIGHT be removed in the future, with more work.
Leaves the mechanism in place, but erases all rows of the alias map data.
Update devel-doc to say ScriptFu has its own mechanism for aliasing.
For major release 3.0
Resolves issue #12203.
Similar to d87c728f, dragging a layer over to a new image via
the tabs uses gimp_image_new_from_drawable () and only
copies a single layer. This patch adds the filter copy code
here as well.
This patch adds a pdb getter/setter for GimpStrokeOptions'
emulate-brush-dynamics property. This allows users to change
the "Direction" of strokes via Script-fu/Python API calls.
Resolves #12198.
When dragging a layer to the toolbox to create a new
image, we weren't copying over the filters. This is because
that action still uses gimp_image_new_from_drawable ()
rather than the multi-layer capable gimp_image_new_from_drawables ()
function.
For now, we'll fix the immediate problem by implementing the filter
copy code in this function. Long term, we should port that code to
use gimp_image_new_from_drawables () instead.
Per Anders Jonsson, the grid colors can have semi-transparency even
if the image itself has no alpha channel. This patch always sets the
GeglColor's babl format to contain an Alpha channel, rather than reusing
the image's color format. The index used for alpha is also updated to
adjust to the number of channels, since GimpRGB previously always used
index 3 for both RGB and Grayscale images.
Call them on different modes of image
and different sizes of image.
Motivated by faults discovered in denoise filter for small images.
No faults detected by new tests.
ScriptFu: tests: enhance testing of gegl wrapper plugins
Add tests on other image modes.
Add tests on small images.
No changes except to tests.
After changes to API:
Colormap=>Palette
Vectors=>Path
After changes to ScriptFu handling of color.
Misc upgrade of tests to use-v3 binding
Revise handling of GeglColor, formerly GimpRGB.
Marshall to/from Scheme lists of numeric.
Marshall from string CSS names and notations.
Conversion to/from GRAY, GRAYA, RGB, RGBA.
See color.scm test script.
Similar to previous commit. If we don't want people to use this function
yet need to export it, at least don't expose the declaration in shipped
headers and even less in the API docs.
Since we consider it private, yet it's still needed in libgimp and app,
let's at least put it in a private header because there is no need for
people to try it out.
I'm also editing a bit the annotations for gimp_main() and GIMP_MAIN().
As part of the color space invasion, we
converted the IFS Compose colors to
GeglColor. However, we forgot to initialize
them when we create a new AFFElement
in undo_update (). As a result, when we
try to clear them out later in aff_element_free (),
the plug-in crashes.
This patch resolves the issues by initializing
the five GeglColors on creation.
...to gimp_drawable_has_visible_filters ().
With NDE filters, it's now possible to have
filters that are not active but still attached
to a layer. This patch renames the API to
prevent confusion as seen in prior
commits.
Similar to afc0a6d1, we need to use gimp_drawable_get_filters () to
get the total number of filters rather than gimp_drawable_has_filters (),
which just returns if any filters in the stack are active/visible.
Because of this, we weren't updating the XCF version to 22 when we
saved a file that had all of its layer effects set to invisible/inactive.
Always update stored colors. When colors are perceptually identical, we
only bypass color rendering code, but not the color value update (even
small value updates need to be echoed across the code, so that what is
shown is always what is set).
With NDE, we can now edit a filter when another layer is selected. This
broke an assumption in GimpFilterTool that the selected layer is the same
as the layer the current filter is applied to.
This patch fixes the problem by checking if the filter is being editing, and then
using either the filter's drawable or tool->drawables->data accordingly.
The previous comment is wrong, because GIMP never had WMF export. Let's
clarify, however, that WMF support is still tricky because of some
options available at configure time regarding 'fontmap' and so on.
Prior commits porting these scripts to v3 dialect
incorrectly compared SF-TOGGLE args to #t and #f.
They are bound to TRUE and FALSE, 1 and 0,
before choice of dialect can take effect.
This was already the case because gegl_operation_get_format() had no
space (i.e. default, sRGB). it's not the source format.
But let's make it clearer because otherwise on a short skimming, it
looks like we are working on the source space.
Also adding a comment on why working on the source space is not a good
idea right now anyway (it's *very* slow for anything but sRGB).
Local certification with WACK is optional and useful to anticipate if
the MSIX will be refused by Partner Center's online certification.
(Just to note: On Windows SDK, certification is not equal to signing.
It's more a checklist process to see if the package is suitable to run.)
To avoid needing the full script to be run with admin rights (which
would be scary) this feature only works with a bunch of requirements:
1. sudo for Windows (so Windows 11 24H2)...
2. enabled in normal (aka inline) mode...
3. in a Windows account in admin group
The 2nd and, specially, the last one are harsh but this is sudo's design:
https://github.com/microsoft/sudo/issues/108https://github.com/microsoft/sudo/discussions/68
Running Color Balance on an image with profile was very slow.
This is because we have special conversion path for sRGB "R'G'B'" in
babl (since babl@90da256), but all the other color spaces are going
through the generic path which does the double conversion to linear RGB
then to 2.2 gamma. And that's slow.
I'm not 100% sure it's right, especially as I'm seeing some CLAMPing
going on (but I'm not sure if removing it is right either) which means
we will likely not cover the full target space in the end.
I'm letting it go because when we'll add proper version support to GEGL
ops, we will be able to improve the algorithm without breaking XCF files
with this filter.
At least now we don't have over-slow Color Balance.
As side improvements, I'm cleaning up a bit the code, which is mostly
micro-optimizations at this point.
This completes the GimpRGB API removal
project for the color space invasion.
Note that the GIMP_RGB_LUMINANCE macro is
temporarily moved to gimpcolor. It does not
require GimpRGB but was included in gimprgb.h.
We are getting HTTP error 429 probably because it's a highly requested file,
and this is causing pipelines to fail at CI lint. Let's fix this with mirrors.
Commit abf0c1c272 fixed the inconsistency of showing "R" for RGB's Red
channel selected whereas the actually displayed selection UI was "H" for
HSV's Hue channel.
As a consequence of this fix, now we were indeed displayed "R". Yet
people got used to working with the Hue channel (and LC plane) for
at least a dozen years. Let's make "H" the officially displayed channel.
During the GAction port, we removed gtk_alignment_new () from the
Animation Playback plug-in as it was deprecated in GTK 3.14.
However, this caused the drawing area to be put on the left side of
the window.
This patch reimplements the alignment feature using gtk_widget_set_halign ()
and gtk_widget_set_valign (), to keep the animation in the center of the dialogue.
Resolves #12160
Currently, GEGL Graph and filters with Aux nodes can only be
applied destructively. Therefore, we need to add a restriction so
they can't be applied when a layer group is selected.
Certain tools like Levels and Brightness-Contrast allow you
to convert it to another filter live. This happened by creating a new
tool, so if you were editing an existing filter, the connection was lost
and duplicate filters were created.
This patch copies any existing filter to the new tool and updates the
name and icon to the new filter type when saved.
During the GimpProcedureDialog port, newly generated widgets were
connected to bender_global_notify (). However, GimpProcedureConfig was
connected to it rather than a GtkWidget, which caused the function to return
without updating since it did not have access to the BenderDialog object.
This patch connects the function to the individual rotate, smoothing, and
anti-aliasing widgets to resolve the issue.
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.
