This commit introduces a new preference option that allows users to enable
or disable the functionality of using the TAB key to show or hide the toolbox in GIMP.
The settings is TRUE by default, preserving the existing behavior.
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.
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.
