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.
- Add Alignment for bitfields.
- BreakBefore*Operators: adhere to GIMP Coding Style.
- Align... AcrossComments: allows section comments in long lists w/o
disturbing alignment (e.g. the struct at top of bmp-load.c). Alignment
can still be reset with a newline.
It's very unclear who and when added that package to the deps list and if
it is needed to we bundle something more than the library (share/lensfun?).
Indeed, that GEGL op is reported to not work properly as a tool (2ba36733) and
have severe UX problems (#4695), being impossible to use even as experimental.
So, let's not install it to not bloat GIMP installation with not used code.
This seems to be a remnant of the time we custom builded libmypaint.
According to my tests, removing it from the list do not break build,
after all pacman auto installs it for being a libmypaint dependency.
When the user checks "Merge Filters" on interactive filters,
we move the filter to the bottom of the stack so it applies
directly onto the drawable (instead of merging the entire filter
stack).
However, we did not do this reordering for non-interactive filters,
resulting in incorrect output. This patch applies the same logic
so that when you apply a filter like Invert, it affects the drawable
only and does not cause problems for any existing NDE filters.
To contextualize: before, we used the custom Docker image for every
little thing (e.g. to compress docs), like firing a cannon at ants.
But this was changed, this "dep" is not needed since 876c709a.
According to my tests in our AppImage, 'libgs10' is enough. Indeed,
we use the Ghostscript library for over ten years (see 005b119f) so
there is no need to install 'ghostscript' package (which is bin-oriented).
We started to use !reference to rules as a workaround in a22393a6 to
merging rules with 'extends:', which isn't possible due to YAML spec:
https://gitlab.com/gitlab-org/gitlab/-/issues/213050
But simple extending, without merging, is totally supported by GitLab.
So let's clean our .yml since that workaround is needed in few places.
The About, Tips, and Welcome dialogues had Help IDs created,
but they were not being used on the dialogues themselves. This
meant there was no help button, and pressing F1 did not pull up
the help manual when pressed.
To be consistent, the Help ID was added to the gimp_dialog_new ()
calls for Tips and Welcome. Since About is not based on GimpDialog,
this patch adds it manually (after checking to make sure the user
has enabled help buttons in Preferences).
This patch also constrains the Tip dialogue's initial width to match
the About and Welcome dialogues.
The Previous and Next buttons have arrow icons. However, these
have not shown up on Windows since at least 2.10, as buttons
created with gtk_dialog_add_button () don't automatically make
their icons visible on all platforms.
This patch uses the existing "image" variable to store the icon
rather than passing it inline in gtk_button_set_image ().
This allows us to explicitly set it to be visible so it shows for
all users.
Our CI is complex, and while I and the maintainers know how it works by heart,
it can be very difficult for the others to understand it from the comments of
the .yml file. So, let's unify three separate sections into one for better QOL.
Since we use gimp_drawable_get_buffer () to get the
pixel data when composing or recomposing, NDE filters
were not being included in the final output.
This patch temporarily duplicates the layer, merges the
filters, and then retrieves the GeglBuffer from the merged
version of the layer rather than the raw pixels.
This patch adds CSS styling to define the color of the
underline/overline when dragging an item in a layer tree.
This prevents a system theme leak and keeps the color consistent
with the current theme's coloring.
Partially reverts change described in paragraph 2 of 9ab48164
Despite GIMP being built targeting to be relocatable, our
bundling script is very SLOW and pretty hard to make it
portable since it makes many ASSUMPTIONS (e.g. that all
deps are pre-compiled etc) which not always holds up.
These limitations could be fixed but would take time.
This was disrupting MSYS2 and crossroads builds, so
let's revert it being called by default for now.
This is needed for scripting output with 'gimp-console*.exe', which is
included in stable versions (but the user needs to change the .interp).
The need to manually change the .interp is ugly as hell (specially for
system-wide .exe installer and MSIX package) but a separate issue.
We were still calling palette.entry_get_color () rather than the new API
palette.get_colors(), which returns the full array of colors.
This patch updates the script to use the correct API.
Inno langs maintenance is semi-automatic since 21ffb589 and 4ec072ed
Right now, seems that everyone understands it, but who knows in the future?
So, just to make sure, being overly cautious, let's add one nice comment.
Following 4cbb9360
Most of the distros provides the dictionary pre-installed but
some like Gentoo not. So, let's bundle "share/libthai" for
maximum portability.
The only trace of reason for this dir being bundled was a pango crash: #2496.
Since the crash was gone, no other reason left, so it was discarded: c808d13b.
However, according to my tests, "word breaking" does not work without this.
(This is what thbrk.c#L22 source says but was never clear in our scripts).
So, let's bundle it with proper comments to make clear why this is needed.
Resolves #12623
Compose and Recompose are in the same plug-in.
When we converted compose.c to use GimpChoice in 7b29ac24,
we did so without checking if it was being called by
Compose or Recompose. As a result, we always overwrote
compose_type with 0 (RGB mode) on Recompose since it
did not have a "compose-type" GimpChoice property.
This patch adds a check to make sure we're not in a Recompose
call before trying to set compose_type from the GimpChoice
parameter.
This option is run by the CI and makes so that the test-file-plug-ins
plug-in is always installed in the CI, even on stable releases. But by
default, they are not installed on stable releases.
It was changed to "GIMP-continuous-ARCH.AppImage" because
I had hope of linking GitLab artifacts on gimp-web (which failed)
so let's use "GIMP-GIMP_VERSION-ARCH.AppImage" again.
Also, uppercase AppId 'Continuous' suffix to be consistent with Flatpak.
In particular, we could end up with mask of wrong bytes per pixel, which
was what was happening in the report.
This commit adds a new GimpDrawableFilterMask class because we needed to
implement a specific is_attached() method for effect masks.
Note: the file is added to POTFILES but the only localized string
already existed elsewhere. So this doesn't break string freeze.
Without this change, we could be using 5GB per job, which
makes the ccache too old so kills its purpose. Also, if
we consider the pipeline it could reach 10GB per runner.
So, let's limit the 'deps' jobs to 256MB, which should be
enough considering my tests and babl and GEGL coding pacing.
GIMP, however, needed way more in my tests, so I set 768MB.
Partially reverts e01973b9
This makes the AppImage .sh script multiarch aware and
make Debian pipeline a GL 'matrix' for easier maintenance.
As consequence, making an arm64 .appimage is pretty easy now,
so let's make one since this arch is not that rare in Linux.
Adding the mode and opacity arguments makes it very similar to
gimp_drawable_merge_new_filter() signature, but also to its own
Script-fu wrapper (gimp-drawable-append-new-filter).
It's just better to be consistent. Also if either of these args need to
be changed immediately afterwards, then we spare one additional
re-render for nothing (for instance in the PSD load plug-in!).
This patch loads legacy 'sofi' data, which represents
the original Color Overlay layer style. It also sets up
the ability to add the other legacy layer styles once
we've matched the right GEGL operations and properties.
Note that this can not read the modern descriptor format
for layer styles.
See: https://learn.microsoft.com/en-us/windows/win32/shell/app-registration#using-the-app-paths-subkey
Starting with Windows 7, Microsoft "strongly" recommends to install per user.
This still applies today for Windows 10: per-user is the default for our
MSIX installed from MS Store and for our .exe installer obtained by winget.
Note: this commit just change the "(recommended)" option in an Inno dialog.
Users can install GIMP in system-wide (admin mode) as always, nothing changed.
This is not a fix for #12359 yet, but an improvement to XCF loading.
When filters fail to load for any reason, we should still load the
layer. Only drop the broken filter.
I've tested lightly this removal. I don't think this code was really
needed or logical anyway, though maybe I am missing something because I
barely discover the existence of this "Image Selection" feature of dock
windows!
When loading a GimpConfig property for a filter, we assumed that
the string is always valid. This patch adds code to check if we read
in the string correctly - if we didn't (or if it was tampered with), we
don't try to deserialize an empty string.
The code to retrieve the alpha-variant of the indexed palette was wrong,
and therefore babl was creating a brand-new palette fornat. Not sure if
the palette was empty, or was random or anything. It's even weird it
even produced somewhat resembling colors.
This is useful right before releases according our release procedure:
https://testing.developer.gimp.org/core/maintainer/release/
Also, checking the variable content make the script more safe,
considering that in the future we will publish automatically from CI.
Filters with custom dialogues like Curves and Levels did not
have the existing filter set before being initialized. This meant
that if you have a different layer selected, editing an existing
filter would add a new filter to your selected layer rather than
editing the filter on its own layer.
This patch sets the NDE filter in the tool before initialization,
so that it can get the correct layer to edit and update the
filter settings on that one.
1. After discussions on IRC, we agreed that "A new perceptual blending
space was added in GIMP 3.0" was a nicer reason to display for
bumping the XCF version, because instead of focusing on fixes, we
focus on the new feature (a real "perceptual blending space" was
added for modes) and also because naming "perceptual" in some form
seems more helpful for people to figure out what is different.
2. Fixing sensitivity of the non-linear (formerly named perceptual)
actions when the blend or composite spaces are mutable.
In previous versions what has been stored/specified as perceptual blending or
compositing spaces has really been the non-linear variant of the images babl
space.
To maintain loading of old files, the code has been updated to actually mean
non-linear and a new perceptual value has been added to the GimpLayerColorSpace
enum, while preserving all old enum values.
This change bumps XCF file version to 23
As noted by Thomas Manni, editing NDE filters was still affected by
restrictions on existing layers, even if the edited layer did not have
those restrictions.
This patch alters gimp_item_tree_view_effects_edited_clicked () so that
it checks if the edited filter's drawable is visible or pixel locked,
rather than the currently selected layers. It also adds checks in
GimpFilterTool tool to verify an existing filter is being edited before
preventing certain operations.
When searching backward, it will show '^^^' and forward 'vvv' instead of
'>>>' and also the searched text will appear next to the prompt between
parentheses. This makes searching a lot easier as we have clear feedback
of where we are at and what we are searching.
These are the common shell shortcuts for respectively searching backward
and forward in command history. I use the Python Console plug-in so much
for testing that it started to weigh on me on how ineffective it was not
to be able to search through the history and laboriously hit Up/Down
buttons instead.
While doing a search, most navigation keys would trigger to stop the
search (and stay at the current history item followed by whatever the
key was supposed to do, such as changing cursor position, etc.). Esc in
particular would just stop the search and do nothing else.
Ctrl-C though would reset the search and get the text back to what it
was before search started.
As a particularity in these NEWS, the changes for BMP are more accurate
in the NEWS file than in the commit because MR !1932 got mistakenly
squashed. For anyone looking to have even more details, they should read
the informative comments in the MR:
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1932/commits
In particular (gimp-drawable-filter-configure),
(gimp-drawable-merge-filter) and (gimp-drawable-append-filter) are
proper Script-fu methods.
I had to rename the PDB procedures for the 2 latter because they were
clashing with these wrapper. I had not realized that private PDB
procedures are still visible by Script-fu. This is not so glop. :-/
Right now, it doesn't look so useful compared to the -new- one-liner
variant procedures. But it will make sense when I will add aux input C
procedure wrappers.
It is this way possible to set a drawable as auxiliary input to a filter
in C and GObject-Introspected bindings.
Note that such filters can only be merged, not appended
non-destructively for the time being.
It can be reimplemented with (gimp-image-rotate) and
(gimp-item-transform-rotate-simple), with even more capabilities for the
latter.
The item rotate procedure is a bit more tricky though, since it takes
into account the selection. It means that either you want to just remove
the selection before (that's what I did here, because this script was
already losing the selection anyway), or you want to store the selection
(with (gimp-channel-copy)), then reapply it (very likely with
(gimp-channel-combine-masks)) at the end, after also rotating it
appropriately the same way as the image if needed.
For plug-in writers reference, these are equivalent:
- (plug-in-noisify RUN-NONINTERACTIVE theImage mLayer TRUE r g b a)
+ (gimp-drawable-merge-new-filter mLayer "gegl:noise-rgb" 0 LAYER-MODE-REPLACE 1.0
+ "independent" TRUE "red" r "green" g "blue" b "alpha" a
+ "correlated" FALSE "seed" (msrg-rand) "linear" TRUE)
Notes:
* When "independent" is FALSE, then you only need to set "red" (which is
equivalent to a "value" field) and "alpha".
* Original plug-in was using the second value ('g', a.k.a. noise_2 in
the PDB args) as alpha when the source drawable was grayscale. This
logic is meaningless now. Just set "alpha".
* The PDB procedure was wrapping the operation between
"gegl:cast-format" nodes to cast the input buffer to linear. This is
useless as the "gegl:noise-rgb" has already a "linear" argument
(defaulting to TRUE, but I specify it explicitly in this commit, for
clarity) which requests linear input when set.
For plug-in writers reference, these are equivalent:
- (plug-in-emboss RUN-NONINTERACTIVE img mask-emboss 315.0 45.0 7 TRUE)
+ (gimp-drawable-merge-new-filter mask-emboss "gegl:emboss" 0 LAYER-MODE-REPLACE 1.0 "azimuth" 315.0 "elevation" 45.0 "depth" 7 "type" "emboss")
Note: the last arg, emboss, must be replaced by a string, "emboss" when
it was TRUE, "bumpmap" when FALSE.
Similarly to "gegl:gaussian-blur", the call to wrap_in_gamma_cast() was
useless because "gegl:emboss" already sets its output format to linear,
as well as its input format (through GeglOperationAreaFilter parent
class).
GIMP_OFFSET_BACKGROUND doesn't exist since commit 2770cce833 and was
replaced by GIMP_OFFSET_COLOR + a specific GeglColor added in
gimp_drawable_offset().
For plug-in writers reference, these are equivalent:
- (plug-in-gauss RUN-NONINTERACTIVE image layer hblur vblur 0)
+ (gimp-drawable-merge-new-filter layer "gegl:gaussian-blur" 0 LAYER-MODE-REPLACE 1.0 "std-dev-x" hblur "std-dev-y" vblur "filter" "auto")
Note: the method arg { AUTO (0), FIR (1), IIR (2) } is transformed into
a string in lowercase. E.g. 1 becomes "fir".
At first, I was a bit annoyed by the wrap_in_gamma_cast() call which
converts the buffer to linear first, but looking at "gegl:gaussian-blur"
implementation, it is just a meta op to 2 "gegl:gblur-1d" which anyway
sets input format (to various formats, but always linear).
This legacy cast code must be a remnant from older times where it might
have been needed. Clearly it's not anymore.
This time, it's a Python plug-in, which is a bit more involved than C or
Script-fu usage (where we have variable args one-liner function) though
it's not too bad either. It's actually very similar (on purpose) to how
PDB procedures are run.
For plug-in writers reference, these are equivalent:
- (plug-in-threshold-alpha RUN-NONINTERACTIVE image layer threshold))
+ (gimp-drawable-merge-new-filter layer "gimp:threshold-alpha" 0 LAYER-MODE-REPLACE 1.0 "value" (/ threshold 255))
The main difference is that threshold arg was a [0; 255] int whereas
"value" is a [0.0; 1.0] double.
This commit also shows how to run filters in C plug-ins (file-ico here)
as a one-liner too, thanks to the varargs conviency function.
For plug-in writers reference:
- (plug-in-maze RUN-NONINTERACTIVE image active-layer 5 5 TRUE 0 seed 57 1)
+ (gimp-drawable-merge-new-filter active-layer "gegl:maze" 0 LAYER-MODE-REPLACE 1.0 "x" 5 "y" 5 "tileable" TRUE "algorithm-type" "depth-first"
+ "seed" seed
+ "fg-color" (car (gimp-context-get-foreground))
+ "bg-color" (car (gimp-context-get-background)))
Notes:
* FG and BG colors were hardcoded to current context colors. It also
means with the new API, you can use whatever else you want.
* The algorithm arg changes like this:
- 0 -> "depth-first"
- 0 -> "prim"
* multiple and offset args (the 2 last args) were bogus and were doing
nothing already.
In particular, I encountered some script-fu scripts calling some GEGL
ops with a seed, but this argument wouldn't be reproduced in the config
object. Technically it's just a uint. Let's just pass them as such.
For plug-in writers reference:
- (plug-in-edge RUN-NONINTERACTIVE image layer 2 1 0)
+ (gimp-drawable-merge-new-filter layer "gegl:edge" 0 LAYER-MODE-REPLACE opacity "amount" 2.0 "border-behavior" "loop" "algorithm" "sobel")
The warpmode (before-last) arg has to be replaced like this (types from
GeglAbyssPolicy enum type):
* NONE (0) -> "none"
* WRAP (1) -> "loop"
* SMEAR (2) -> "clamp"
* BLACK (3) -> "black"
For edgemode (last arg), just use the name value in lowercase as string:
{ SOBEL (0), PREWITT (1), GRADIENT (2), ROBERTS (3), DIFFERENTIAL (4), LAPLACE (5) }
E.g. "differencial" instead of formerly 4.
For plug-in developers reference:
- (plug-in-cubism RUN-NONINTERACTIVE image layer tile_size saturation 0)
+ (gimp-drawable-merge-new-filter layer "gegl:cubism" 0 LAYER-MODE-REPLACE 1.0 "tile-size" tile_size "tile-saturation" saturation "bg-color" '(0 0 0))
Now you can even choose the bg-color (not just an int/enum of black and
background color only).
For plug-in writers, here is how to replace it:
- (plug-in-c-astretch RUN-NONINTERACTIVE img drawable)
+ (gimp-drawable-merge-new-filter drawable "gegl:stretch-contrast" 0 LAYER-MODE-REPLACE 1.0 "keep-colors" FALSE)
Marshalled PDB procedures into script-fu can now convert a filter ID
into the proper object. For instance, here would be the code to append a
new gaussian blur filter to the drawable with ID 2 (with specific
settings), then making invisible:
```script-fu
(define filter (gimp-drawable-append-new-filter 2 "gegl:gaussian-blur" "hello" LAYER-MODE-COLOR-ERASE 1.0 "std-dev-x" 20 "abyss-policy" "none"))
(gimp-drawable-filter-set-visible filter FALSE)
(gimp-drawable-update 2 0 0 -1 -1)
```
I moved the code to transform scheme values into GValues depending on a
GParamSpec out of script_fu_marshal_procedure_call() into a shared
function script_fu_marshal_arg_to_value().
When calling gimp_drawable_filter_get_config() the first time, we don't
want the config's properties to be at default values, but instead to be
set same as they are on core app.
On further calls though, we don't touch the values, because they may be
out-of-sync until the next call to gimp_drawable_filter_update().
… gimp_drawable_filter_update() first.
Otherwise this is bug-prone. When people were to update the
configuration of the filter, they obviously intend this to be used when
appending/merging.
Also adding an example of using it in the C goat exercise, though I
leave it commented out because showing code for direct GEGL usage is
also of interest.
As a side update, I am adding proper support of the NULL or empty string
value for the filter name. In this case, the default human-readable
title of the operation will be used instead.
Without this, the filter order was right only when checking off then
then on the option, but the render was wrong when opening the filter
options dialog.
Similarly to the config arguments, the set functions are not directly
calling core. Instead they are queuing changes until
gimp_drawable_filter_update() is run.
It is now possible to sync the GimpDrawableFilterConfig with core.
Another (simpler on usage) possibility could have been to sync
automatically when a property is updated. But considering that some
filters can be quite slow to render (especially in real-life usage when
working on possibly very big files), and especially that on bindings
with no variable args, scripts will likely have to edit properties one
by one, it could make editing multiple properties very slow. Therefore
the chosen solution is that editing properties stay local on libgimp and
all changed properties are synced with core at once (with a frozen
render until the end for single computation) when calling
gimp_drawable_filter_update().
It was possible to set a GimpChoice property to a value out of the
allowed list. This got very likely broken when I re-parented
GimpParamSpecChoice to GParamSpecString which had a value_is_valid()
implementation, which was shadowing our custom value_validate().
This is fixed by now also implementing value_is_valid() for this param
spec type.
This is mostly an empty shell whose goal is to serve as base class for
specific dynamically generated per-operation subclasses, which will have
properties mimicking the arguments of the GEGL operation.
Most of the fundamental type args will just use the base GLib param spec
types instead of GEGL ones.
As a special case, the GeglParamEnum arguments are transformed into
GimpChoice param specs on libgimp side. The reason is that most of the
time, enum types are created within the scope of an operation code only
and cannot be properly reconstructed over the wire. I could just
transform these into an int type (which is mostly what is done in GEGL
right now when running an op with such arg), but GimpChoice allow much
nicer string-type args, which make much more semantic code. This class
was initially created for plug-ins, but it would work very well to run
GEGL ops on drawables. So let's do it.
Finally add a gimp_drawable_filter_get_config() to request the current
config of a filter.
Note that right now, we can't do much with this config object other than
observing an operation args and default values. Being able to update a
filter's settings will come up in further commits.
A few functions were added, but the main one is
gimp_drawable_get_filters() to request the list of filters applied
non-destructively on a drawable. We can't do much with these for the
time being, but this will come.
WIP.
Makes the Dock icon only appear when a script plugin has a dialog.
Unfortunately, on MacOS where "transient for" doesn't work,
we need a Dock icon for the separate process so user can "Show window."
See #12150
Done at runtime.
A build-time alternative is: package script-fu binary in a bundle, and set properties.
Fixes both the new-style dialog (GimpProcedureDialog) and the old-style dialog (deprecated.)
The gimp app and extension-script-fu (long-running)
are separate processes and "apps."
An app can be "active": in front and receiving GUI events.
As reported, on MacOS, when an extension-script-fu plugin yields,
the gimp app did not become active.
Also, on the second invocation of a plugin served by extension-script-fu,
the dialog could be hidden or require an extra click
because extension-script-fu was not active.
(Independently interpreted plugins did become active,
because it was a new process and gimpui_init activates on MacOS.)
On MacOS:
1. after the first dialog shown by extension-script-fu,
ensure subsequent calls to plugin make extension-script-fu active.
2. After a plugin yields, plugin manager ensure the Gimp app is active.
Note that this is done whenever a TEMPORARY procedure returns.
Most are calls to extension-script-fu plugins.
But some are also callbacks from Resource choosers running in the gimp app.
When they return, the gimp app remains active, and user must first click in
the plugin dialog to continue working.
Especially when the user clicks OK in a Resource Chooser, closing the chooser,
it would be nice if the plugin dialog became active.
That requires more, FUTURE development.
Special to MacOS: on Linux, "transient for foreign window" ensures this,
but that doesn't work on MacOS.
The fix is somewhat brute force and as simple as possible.
There is a more cooperative API for app activation on MacOS.
An app yields, and apps request, not force, self or other app be activated.
The fix does not use the cooperative API.
To do so would require a platform abstraction layer, in GIMP or Gtk.
The fix also sprinkles the code with #ifdefs.
That could be hidden if there were a platform abstraction layer PAL
The layer would be the greatest common denominator across platforms.
PAL methods would always be called in GIMP code,
but not do anything when the effect was accomplished another way.
For example "gimp_platform_request_app_active"
would request the app was active,
but do nothing on Linux where that is ensured by "transient for."
Previously, just hanging a read, extension-script-fu missed GUI events
that closed dialogs on MacOS.
The fix is a proper event loop for a plugin that persists, reads, and has GUI:
calling gimp_plug_in_persistent_enable and a main_loop,
instead of gimp_plug_in_persistent_process.
The fix is not conditional on MacOS, but seems events missed only on MacOS.
The previous fix for MacOS, #6577, only works for old-style GUI (script-fu-interface.c).
That was not the best fix, and doesn't work for new-style GUI (GimpProcedureDialog).
If symptoms still appear in 2.10.38
(#12150 says dialogs dissappear but a dock icon has spinning ball)
this should be backported to 2.10.
Partially revert f0fb4435
It is safer to wait for Inno to compile successfully before deleting the
.bak langs, which are the condition to auto repairing.
Note: I reinforce that, despite the name, this doesn't look like Vista.
Following de556c0734
Microsoft use of bezel in Win32 and UWP/WinUI3 apps is inconsistent:
sometimes the bezel is there, others not. However, when displayed
the bezel never is that dark. So let's at least hide it, just how
we do in the Devel warning and Inno do in most dialogs.
SSE2 (not the first SSE) instructions are required since 2012 on Windows 8.
Our minimum requeriment for 3.0 series is 10 so Inno built-in 'MinVersion',
by consequence, implies requesting SSE(2) without needing a custom dialog.
Then, let's cleanup this, which will make us gain a few (milli?)seconds.
Just to note, SSE2 (again, not SSE) is required even on Win 7 (since 2018).
This makes the range handles for the Levels tool and other
auto-generated range widgets adapt to any theme color,
just like the Gradient Editor range handles currently do.
It is like a compiler warning, and should not be a full g_warning,
which should mean something will probably fail.
Passing fewer args is a feature since 3.0: the PDB will use defaults.
This provides us fine-grained info on how much time each step take,
making easier to spot stuckness and to quickly understand the logs.
'gimp' jobs normally do not take advantage on this due to log limits
(they expand and crop the log), so I adapted them to only output errors.
---
Also, to reduce logs, all jobs were reviewed with proper GIT_* variables.
We were unconditionally using the selected layers' drawable
when setting up the filter tool's dialogue. As a result, it
would use the wrong drawable as the dialogue thumbnail if a
different layer was selected while editing an NDE Filter.
This patch checks if we're editing an NDE filter, and if so,
uses its drawable instead.
While we want to allow a flexible range for the
Box and Cylinder dimensions when called non-interactively,
having a large range in the GUI makes it difficult for
users to precisely set those values.
This patch adds calls to gimp_scale_entry_set_bounds ()
to match the 2.10 GUI ranges, while letting the values be
larger then that when called via the PDB.
When opening an old XCF, we try to match the fonts specified in the text
layers (and the text tool) with the closest font (if the exact font isn't available).
This patch improves the matching heuristic a bit.
Based on suggestions from Michael
Schumacher in issue #12239.
Until we implement native file picker dialogues,
Windows users can't load images from
Windows shortcut (.lnk) files.
This patch adds a plug-in to open these
.lnk files, extract the path, then try to read
it in via gimp_file_load ().
Similar to file-compressor, the error
messages are suppressed in the GUI so that
users don't get error messages if they click
on a non-image shortcut in the file picker.
Only export 1-bit TIFF for black and white indexed images without alpha
channel. 1-bit TIFF with alpha has poor software support:
- GIMP: cannot read its own exported files
- macOS Preview: ignores MINISWHITE/MINISBLACK
- Windows Photo Viewer: shows as invalid image
- InDesign: ignores alpha channel
- tiff2rgba: fails to process
- Photoshop/Illustrator: corrupted rendering
Any font file path that's invalid utf-8, and/or any metadata (psname,
fullname, family...etc) that's not valid utf-8 should be skipped and not
passed to fontconfig.
This issue has eluded us for a long time and it was recently fixed in
Pango (MR pango!745). We can't bump the minimum requirement because of
our bookworm baseline for GIMP 3.0.0, but we can at least warn when
building for macOS.
We still want the normal GIMP_RELEASE C macro to be set because the
whole development frame should have code behaving like release code, yet
only for the AppStream metadata testing, we want to allow a "TODO"
release date while in +git code.
While not an "official" tupl type for PAM files, software such as
mutools can export CMYK PAM files. This patch adds support
for loading such images.
Note that PAM files do not include color profile information. In
the future, we might add an option to convert using a pre-defined
color profile for this and other formats like EPS.
The "AppImage platform" don't have releases, every tool is blending edge.
Obviously, it is too prone to broke, and for the first time it got broken.
So, let's move it to a separate job and with less frequency to not broke CI.
Two tests were consistently timing out before this change:
save-and-export and ui. The gdk_test_simulate_key documentation mentions that
gtk_test_widget_send_key is the right approach for most testing purposes.
With this change, save-and-export started working for me, whereas ui now fails
properly - investigating this failure was the original point of the change.
Closes #12518
Certain Sony camera's have MakerNote tags in the Exif.SonyMisc3c range.
When exporting with EXIF metadata included this causes a failure saving
the metadata, which means that no metadata at all is saved to the image.
For now, let's exclude these tags, so that all other metadata tags at
least will be saved.
We will keep an eye on exiv2 issue
https://github.com/Exiv2/exiv2/issues/2670
to see if the actual cause will be solved.
A lot of the custom brand makernote tags have interpreted strings
available, even though their type is set to Byte.
Since having those interpreted doesn't have any negative side effects
(real Byte values are correctly converted) let's not exclude these
tags for interpreted string conversion.
Note: the original workaround was superseded by: 9ab48164
The actual workaround (which adress the same issue) is being dropped since,
according to my tests, seems that the MSYS2 issue was fixed. See: #10782
Inspired by Mark Sweeney's work.
This patch passes the user-defined button
icon size from GimpDisplayShell to
GimpStatusBar, and updates the
Soft Proofing button and current tool
icon sizes based off of it.
This patch creates a gimp_colormap_selection_colormap_changed ()
function that gets the new colormap count and updates the entries
and spinbutton maximum in the Colormap Selection widget.
Previously the palette view was being refreshed, but the rest of the
widgets in the dialogue were not being updated to match when a
new color was added.
The block size for layer info should be a multiple of 2.
We had erroneously thought it was a multiple of 4, based on what is used
for layer resources. But of course Photoshop is inconsistent and uses
a multiple of 2 here.
in gimp:offset filter.
Since gimp:offset is now an NDE filter,
always loading the background color from
context causes the color to change each
time the filter is redrawn. This is inconsistent
behavior.
This patch replaces the GimpContext
parameter with GeglColor, and updates
gimp_drawable_offset and related functions
to set the color directly. The libgimp version
loads the background color from context
and passes it on since the API is now
frozen.
Resolves #12478
There was existing code to scale the Lightness value of LAB
colors by 100 to match the 0.0 - 100.0 range used in babl.
However, it was not actually running because the `color_space`
value was not being properly cleaned before the comparison.
When loading channels, the alpha value is stored separately from
the RGB value as "opacity". After the switch to GeglColor, we were
overriding the opacity values by always using "R'G'B" format, so
the loaded opacity was always reset to 100%.
This patch pulls the opacity value before setting the color, then
restores the opacity afterwards.
Similar to 42300d9d, we want to prevent overly long color profile
labels from stretching out dialogues with GimpColorSelect too far.
This patch adds gtk_label_set_ellipsize () to both the color profile
and simulation profile labels, and adds them to a grid instead of
letting them free-flow.
The latest appimagetool inserts a runtime with static libfuse in the .appimage.
It also makes the .appimage run way faster and slightly better compressed.
Thanks for helping me with this, @samueru
This avoids calling host libs, fixing the last pendency on !1440 desc.
In other words, the AppImage now can be run, in thesis, in any distro.
Thanks for helping me with this, @samueru
Resolves #12468
In a2458f15, we converted xres and yres to gdouble since
gimp_image_get_resolution () requires doubles as arguments.
However, TIFFGetField () expects a float, and returns incorrect
values if a double is used as a parameter.
This patch converts xres and yres back to gfloat, and makes
new default_xres and default_yres variables as gdoubles to
use with gimp_image_get_resolution ().
We did not explicitly define the padding and margins for
the slider text and "progress" areas, which allowed for
system theme leaks. This patch defines these values and
makes the sliders visually closer to 2.10's style.
In 2.10, the "Layer Name" field in the Layer dialogue was
auto-focused (perhaps because it was the first field in the dialogue).
This patch restores this behavior so users can type the name and
press Enter/Return to continue their new layer workflow.
A patch was originally contributed by Andrzej Hunt in #11822 (cf.
0002-xcf-fix-channel-s-reference-counts.patch in the report).
The diagnostic of the double PROP_SELECTION issue is right, but not the
fix which was over-reffing, hence leaking channels and buffers, in the
normal cases, just to avoid double-free in broken edge cases.
The other issue is not possible though (unreffing the image's selection
when encountering an error in xcf_load_channel()) because we explicitly
check it it's the image mask AFAICS.
I added a second test which was not double-freeing yet which deserves a
bit of stderr messaging: when 2 different channels have PROP_SELECTION
set.
Relevant text from the commit message originally contributed by Andrzej
Hunt is the following (diagnostic and ASAN output still of interest):
----------------
xcf_load_channel creates a new channel using gimp_channel_new. This
channel has a floating reference (because GimpChannel is a subclass of
GimpItem, and gimp_item_init uses g_object_force_floating()).
Next, three different scenarios can occur:
- xcf_load_channel_props does nothing, and we either return channel, OR
in the error case we g_object_unref (channel) which frees channel.
The returned channel is either silently dropped (in the case where
it's already been set as the mask), or added to the image using
gimp_image_add_channel if not (which sinks the floating reference).
- xcf_load_channel_props encounters a single PROP_SELECTION. We create
a selection using gimp_selection_new (which again has a floating
reference), transfer ownership of the new selection to the image
using gimp_image_take_mask(), free the old channel, and finally set
channel to point to this new selection. Back in xcf_load_channel, IF
we hit the error case, we call g_object_unref (channel), which frees
the new selection - but we're still using it as the image's mask,
meaning we could eventually hit a use-after-free whenever someone
reads the mask.
- xcf_load_channel_props encounters 2 PROP_SELECTION's. After the first
PROP_SELECTION, channel is pointing to the image mask, which has
reference count == 1 (as explained above). When we hit the second
PROP_SELECTION: we create another new selection, followed by calling
gimp_image_take_mask() again. gimp_image_take_mask() call
g_object_unref() on the old mask, which frees it - but channel is still
pointing to this mask. We then call g_object_unref() on channel, which
is effectively a double-free.
We fix this by making sure to always ref_sink whatever object is put
into channel. gimp_image_take_mask also calls ref_sink, which means
we'll now bump the refcount up to 2 when the channel is being used as
the image's mask (and drop back to 1 if the mask is replaced, and down
to 0 when channel is unref'd).
See also ASAN output below from the 2x PROP_SELECTION scenario:
==6381==ERROR: AddressSanitizer: heap-use-after-free on address 0x6150000047d0 at pc 0x7fb5531ef31b bp 0x7ffe81e86cb0 sp 0x7ffe81e86ca8
READ of size 8 at 0x6150000047d0 thread T0
#0 0x7fb5531ef31a in g_type_check_instance_cast /home/ahunt/git/glib/_build/../gobject/gtype.c:4117:26
#1 0xb2346b in xcf_load_channel_props /home/ahunt/git/gimp/app/xcf/xcf-load.c:1742:41
#2 0xb1a3cc in xcf_load_channel /home/ahunt/git/gimp/app/xcf/xcf-load.c:2219:9
#3 0xb147eb in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:653:17
#4 0xb121bb in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#5 0x619ead in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:50:17
#6 0x51d414 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#7 0x507092 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#8 0x50d400 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9
#9 0x537452 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#10 0x7fb551e7c349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#11 0x4e0829 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
0x6150000047d0 is located 336 bytes inside of 504-byte region [0x615000004680,0x615000004878)
freed by thread T0 here:
#0 0x5e8612 in free /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:127:3
#1 0x7fb552d9ce08 in g_free /home/ahunt/git/glib/_build/../glib/gmem.c:199:3
#2 0x7fb552dc7a6b in g_slice_free1 /home/ahunt/git/glib/_build/../glib/gslice.c:1183:7
#3 0x7fb5531e7b04 in g_type_free_instance /home/ahunt/git/glib/_build/../gobject/gtype.c:2008:5
#4 0x7fb5531bfe3a in g_object_unref /home/ahunt/git/glib/_build/../gobject/gobject.c:3604:11
#5 0xd4d4d4 in gimp_image_take_mask /home/ahunt/git/gimp/app/core/gimpimage.c:3267:5
#6 0xb23438 in xcf_load_channel_props /home/ahunt/git/gimp/app/xcf/xcf-load.c:1739:13
#7 0xb1a3cc in xcf_load_channel /home/ahunt/git/gimp/app/xcf/xcf-load.c:2219:9
#8 0xb147eb in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:653:17
#9 0xb121bb in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#10 0x619ead in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:50:17
#11 0x51d414 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#12 0x507092 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#13 0x50d400 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9
#14 0x537452 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#15 0x7fb551e7c349 in __libc_start_main (/lib64/libc.so.6+0x24349)
previously allocated by thread T0 here:
#0 0x5e887d in malloc /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
#1 0x7fb552d9ccf2 in g_malloc /home/ahunt/git/glib/_build/../glib/gmem.c:106:13
#2 0x7fb552dc72e0 in g_slice_alloc /home/ahunt/git/glib/_build/../glib/gslice.c:1072:11
#3 0x7fb552dc78ae in g_slice_alloc0 /home/ahunt/git/glib/_build/../glib/gslice.c:1098:18
#4 0x7fb5531e6e0a in g_type_create_instance /home/ahunt/git/glib/_build/../gobject/gtype.c:1911:17
#5 0x7fb5531c215e in g_object_new_internal /home/ahunt/git/glib/_build/../gobject/gobject.c:1945:24
#6 0x7fb5531c1d1f in g_object_new_valist /home/ahunt/git/glib/_build/../gobject/gobject.c:2288:16
#7 0x7fb5531c0e8b in g_object_new /home/ahunt/git/glib/_build/../gobject/gobject.c:1788:12
#8 0xdb7260 in gimp_item_new /home/ahunt/git/gimp/app/core/gimpitem.c:722:10
#9 0xce1668 in gimp_drawable_new /home/ahunt/git/gimp/app/core/gimpdrawable.c:1067:14
#10 0xe283e9 in gimp_selection_new /home/ahunt/git/gimp/app/core/gimpselection.c:626:13
#11 0xb2342a in xcf_load_channel_props /home/ahunt/git/gimp/app/xcf/xcf-load.c:1735:15
#12 0xb1a3cc in xcf_load_channel /home/ahunt/git/gimp/app/xcf/xcf-load.c:2219:9
#13 0xb147eb in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:653:17
#14 0xb121bb in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#15 0x619ead in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:50:17
#16 0x51d414 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#17 0x507092 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#18 0x50d400 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9
#19 0x537452 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#20 0x7fb551e7c349 in __libc_start_main (/lib64/libc.so.6+0x24349)
SUMMARY: AddressSanitizer: heap-use-after-free /home/ahunt/git/glib/_build/../gobject/gtype.c:4117:26 in g_type_check_instance_cast
Shadow bytes around the buggy address:
0x0c2a7fff88a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2a7fff88b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
0x0c2a7fff88c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2a7fff88d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fff88e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c2a7fff88f0: fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd
0x0c2a7fff8900: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
0x0c2a7fff8910: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2a7fff8920: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fff8930: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fff8940: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==6381==ABORTING
( crash-c35bcae86d35ce7d0cd8ffcb41a470f37354e018 )
b9f81e1c broke CI because it is a CI-related change but not tested on CI.
Despite https://developer.gimp.org/core/maintainer/giving-developer-right/
not making previous CI test mandatory, it is reasonable to do, even the infra
being sick. That is not the first time our CI got broken by lack of testing.
Like in #11964 for Default theme, the nib handle for the ink
tool is invisible on the System theme. Fix this by adjusting
the solution in a4f9e7e89a for use with the System theme.
It seems any installation will have a lot of them (mostly because of
bitmap fonts which are now unsupported by Pango) and the message
startles people who believe there is something broken with GIMP.
Let's just not show this message on stable release builds, yet still
keep it on stable development builds (and all unstable builds, even
releases), because it is informative and keep us aware of this
limitation (which we hope to someday get rid of, i.e. get back support
of bitmap fonts, as well as any font format!).
My commit 0b792c22a4 was a beginner mistake as pdb/enums.pl is a
generated file. I also need to fix the source otherwise `git diff` will
always differe when generating the file.
Our CI in particular verifies that `git diff` is always empty so this
was breaking our gimp-debian-x64 CI job.
In activate_fractal (), we copy over preset Fractal values into the current
config object. Since "color-mode" is now a GimpChoice instead of an int,
this caused a crash when applied. This patch switches it to set a string in
g_object_set () rather than the original int.
In 9b917b8d, we defined the background and hover style
for the top menubar context menus. However, this did not
carry over to the menus for the on-canvas context menu.
This patch generalizes the CSS style so it affects both.
A regression introduced by a8b9bedf is that installing GIMP 3.0.0-RC1+git was
keeping GIMP 3.0.0-RC1 icon since an [InstallDelete] line was mislooked by me.
As a side note, to understand how the Windows versioning introduced by a8b9bedf
works, please read the latest base_gimp3264.iss file at 3.2.2 [Setup] section.
For this to work properly, I don't process them line by line, like all
other actions. Instead, I do a post-processing pass where I verify if
both variants were set, and if so, with an acceleration or with an empty
string. Indeed several cases are triggered:
1. We may migrate with 2 custom shortcuts on the same action;
2. we may mix 1 custom shortcut with one of the default shortcuts;
3. we may disable one of the default shortcut but not the other;
4. we may disable both shortcuts.
These were removed in commit 2c4f91f585, though I do wonder if this may
not have been a mistake since edit-paste and edit-paste-in-place are not
exact equivalent. They may still create floating items in some cases.
But that's good enough for now.
This is an improvement over commit ce2a9dc3eb which was only meant to
work for GIMP 3.0. This new code should work for 3.2 and any future
version too. It will try to migrate any configuration folder from GIMP
2.0 to whatever is the current version.
Should resolve #12436
Since we currently always apply filters with Aux nodes
destructively, we need to move them to the bottom of
the filter stack on creation. However, it's possible to have
the Preview checkbox unchecked when adding such a filter.
The current code does not add the filter to the stack until the
Preview is turned on. This can cause a crash when reordering
filters with Aux nodes, as they haven't actually been added yet.
Rather than duplicate code, this patch changes the code to always
apply the filters, then immediately set their visibility based on the
checkbox. This also adds a check to see if the filter stack actually
contains the filter before reordering.
This is a followup of previous commit. We must set the win_subsystem
option on executable() so that the result binary is compiled as a GUI
application (and doesn't output a console every time).
The previous commit is still needed and is what allows us to control
when to actually display a console.
This was a bug in the meson port which was not taking into account the
stable or release state of a build (unlike how it was in the old
autotools). The rules are:
* All unstable builds (release or not) have the console.
* Non-release builds in stable series have the console.
* Only release of stable series don't have the console.
* The RC of a stable release should behave as a stable release.
* compiler warned about terminating zero not copied
* removes all manual character counting
* static assert as a reminder that new string must be shorter, in case
someone want to reuse the code with different strings
Elide the underscore char from the blurb of the GParamSpec.
The tooltip remains redundant with the menu label.
We can't use an empty string (omit the tooltip)
because the blurb is also the description in the PDB Browser,
and the generated name of the arg is not descriptive.
FUTURE: let script author also declare a tooltip,
and a non-generated but unique name of the arg.
Change SF server to load /scripts, just like extensio-script-fu.
This restores SF server to v2 behaviour re:
1) the content of responses
2) the need for a run_mode arg in calls to scripts
Thus calls to scripts (submitted to the server)
are evaluated without a call via the PDB to extension-script-fu.
This means such a call yields the string repr
of the last evaluated expression of the script,
instead of the string repr of a call via the PDB,
which is #t since scripts are declared in the PDB as returning void.
This also means the run-mode argument is not required in such calls,
since it is a call to a run_func in Scheme, which has no run_mode arg.
This also means that the SF server will continue to run
even if extension-script-fu crashes.
A test is that a call to a simple "echo" script, installed to /scripts,
yields the same response from the server in both GIMP 2 and 3.
Resolves issue #12252
Unlike the layer and image commands for scale layers,
the Transform Tools use gimp_item_transform () rather than
GimpDrawable's scale/rotate code. Therefore, the filter's crop
was not being refreshed, resulting in the layer being cut off
after the transform.
This patch moves the gimp_drawable_filter_refresh_crop ()
code to gimp_item_transform () so that the new layer size
is taken into account in the filter.
027013c7 was fine but not good enough. Without this new commit,
if you stop the script after touching the Inno lang files and run
the script again it would not restore the patched lang files so
patch over patch, producing something like "GIMP 3.0.0 3.0.0".
So, this new commit identifies if the script wasn't completed and
repair Inno installation before applying the patches again.
Resolves #12403
gimp_filter_tool_set_transform_grid () is used to draw the on-canvas
transform grid for filters. It always assumes that the tool's selected
layer should be used to define these boundaries.
With NDE filters, you might be editing a filter on a different layer than
the actively selected one. This patch checks if an existing filter is being
edited, and if so, we grab the drawable from the filter rather than from
the tool.
In gimp_file_save (), we clear out the values
of any String parameters to prevent unexpected
results. However, GimpChoice is also a
String type. This causes the function to
fail because empty string is not a valid
option for GimpChoice.
This patch adds a prior check if the argument
is a GimpChoice, and sets it to its default
value instead to prevent this issue.
- Do not install Inno if it is already updated
- Delete unofficial langs after creating the .exe installer
- Ensure that all .isl files are kept as before the patching
This is an attempt to fix #12333 where from the look of the trace, the
segfault may happen if it tries to dereference a NULL view->priv->shell
whereas we have a view->priv->cursor_image. Even though I couldn't
reproduce, I'm wondering if it may possible to have no active image
display while the cursor is indeed hovering an image.
Furthermore this updated code is more logical anyway, because we should
use the "show all" value from the actual display shell the cursor is
hovering, not from the active display shell.
The welcome dialog creates a link to the release notes for stable
versions, but it also uses it for RC releases even if the
release notes for the final release haven't been written.
Check the version for "RC" to avoid creating dead links.
When we converted to GeglColor arrays in 6327d1b3, we
didn't adjust the call to gimp_gradient_select_preview_draw ()
that still assumed we passed in 4 doubles per pixel instead
of 1 GeglColor. This patch removes the division operation so
that we see the full gradient in the chooser button.
This replaces the GIMP_RGB_LUMINANCE () macro with
babl_process () to retrieve luminance from pixels
in GimpHistogram. This allows us to consider the
color space during the conversion, rather than assuming
sRGB always.
Resolves issue #12365
Per Kamil Burda, since we no longer have an array length parameter
for layer and channel procedures, the required minimum size of
procedure->num_args should be 3 and not 4.
...when drawable has alpha channel.
We always created GeglSamplers in RGB format,
but used the original drawable's format to create a
GeglBuffer. If the original drawable had an alpha
channel, this caused "glitchy" results since not
enough data would be copied into the new buffer.
This patch resolves the issue by making the format
match the original drawable's number of channels.
Resolves Issue #12362.
This was broken, see #12119. Now is fully bundled with DLLs and config, but
will not work on .exe installer because gegl have bugs: GNOME/gegl#394.
However, this should be bundled only in dev releases (due to "Debug" menu).
But not for 32-bit because MSYS2 doesn't provide 32-bit pango plugin for dot.
Fixes: #12351
In short, some time ago we were asked by a MSYS2 guy about the possibility of
they dropping pixbuf loaders and some of us said that we just need SVG/PNG for
UI. I tested and confirmed it so the debloating (c808d13b) kept only these two.
However, seems that was said in the same discussion that we also need others for
non-PAT pattern loading. After testing, let's bundle JPEG, GIF and TIFF loaders
following: https://testing.docs.gimp.org/3.0/en/gimp-concepts-patterns.html
BMP is already bundled for legacy clipboard (a4671d72) and will work here too.
PNG too, of course, otherwise GIMP UI wouldn't even load, as pointed above.
---
Other formats are supported by pixbuf but some can make patterns: unportable,
e.g. HEIC (my ponderation); or even buggy, e.g. WEBP (@ok ponderation). So,
let's NOT bundle all loaders like before the debloating, just the safe ones.
This finally makes our crossbuild scripts work like in all other platforms:
with GIMP_PREFIX separated from the system/MSYS2 prefix. Thanks, @Jehan.
For some reason this makes meson don't find only 'bzip2' headers provided by
the cross compiler so, in crossbuilds, let's use the ones provided by MSYS2.
Fixes: #4802 and #12148
This is needed to paste some images sent to Windows clipboard as .bmp.
---
Also, comment the reason to bundle the other loaders and the gio folder.
Since GimpUnit is now an object, if it's used in functions while
NULL it can cause issues. This patch initializes it to
gimp_unit_pixel () to remove the CRITICALs we received when
setting up rulers when "Show All" is enabled.
This file has stopped of being bundled in c808d13b as a consequence of a
bad practice of the past: not documenting the purpose of bundled files.
Let's bundle it again commenting the reason so the future generations can
understand why it is bundled: gspawn*-console is needed to open hyperlinks.
Of course, it does more than this, but one use case is enough to understand.
The warning "Couldn't export handle, unsupported windowing system" still will
be output on terminal since the fix (GNOME/gtk!7694) wasn't released yet.
---
Also, clarify commenting other bundled files and dirs in the bundling script.
Since the bug described on fbb484c5 is fixed, let's build them again
so we not mislook problems that could be present in vanilla Win builds.
Do not confuse with 'g-ir-doc', which is broken on Windows: #11200
This job fails because our test plug-ins isn't installed in stable or
release versions. However we are in a RC1 status which leaves stable
and release true.
Let's fix this by checking for "+git" at the end of the version string
and also installing our plug-in if that is found.
Intermediate RC versions used to be suffixed "-git" but gi-docgen
doesn't like this (or to be more accurate the packaging.version module
used by gi-docgen considers this an invalid version).
But it allows with a '+' (it calls it the local version segment). So
let's go with this new formatting.
Adds GIMP_MUTEX_VERSION var to make possible to change the way we handle
multiple GIMP installations without needing to manually change parts of
the script to MAJOR or GIMP_APP_VERSION like a zoombie.
Also, this reorganizes some sections of the .iss file (for the third time)
and make LZMA multi threading the default even for stable builds.
979a3c3c assumed that all bumpmaps in the Lighting Effects plug-in
would have an alpha channel, which is not always the case.
This patch adds a check via gimp_drawable_has_alpha (), and sets the
babl format accordingly.
Not sure why, but previous RCs' versions were written all lowercase and
with a tilde separator, so I just used the same syntax, but that won't
fly with how we will write it in the main meson file. So let's do a few
string fixes to make both syntax match.
We are very likely releasing on Monday 4, and not even now but after a
good night. The whole Gitlab infrastructure is clearly half-borked right
now, we are constantly waiting for runners, sometimes we get random
error 500 when loading Gitlab pages, sometimes some stuff get stuck on
display and we need to refresh.
Not only this, but the Flathub infra is also broken (I believe it's also
hosted by GNOME?) and all our builds are either failing or sometimes
going further then failing at "Committing builds" or other steps,
usually with some HTTP error.
It's not the wisest idea to make a RC1 release in such condition.
There were 2 issues:
* The tag needs to start with the project name in uppercase.
* For GEGL repo, the last item was some very old tag. Make a pattern a
bit more accurate (though it's only glob, so it's not that accurate
either, but hopefully will work out in future too).
Every artifact from our CI have a pretty name with some reason for it:
- Installer: it is this way on download.gimp.org since ever(?) and that's fine
- Store: follows Microsoft de facto spec of .msix files naming
- AppImage: follows AppImage draft spec of .appimage files naming
But the .flatpak just looks like AUR pkg. So, let's use reverse DNS
naming which is used at least for .flatpakref files. This makes more sense.
While they work well, the gegl_node_get_bounding_box ()
call causes the entire filter stack to refresh
each time we need to update the filter stack.
This slows down rendering significantly.
For 3.0 RC1, it's better to have good performance
and deal with the less common crop
issue for now. We'll work to find a better
performing solution for 3.0.
On Windows, it will basically be a copy of the main binaries. On other
OSes, it will be symlinks.
This will help for Windows installers where we want to use major version
only in registry and we need a binary named appropriately for this
apparently.
As for the "major" version, I will in fact use the next major when minor
is 99 (also called API major version), not that it will matter much very
soon!
… legacy to gegl parameters.
This commit removed 57 legacy PDB procedures which were replacing
outdated plug-ins (before transformed into GEGL ops) as far as I
understand.
These were all kept only as a legacy compatibility layer for third-party
scripts. Since we are breaking API anyway, let's remove as many as we
can. I've only kept the few which are still used at least once in our
core scripts or plug-ins.
Now as pippin notes, we still have no easy way to quickly run GEGL ops
on drawables in script-fu. Though we have at least access to GEGL API
for C plug-ins and all GObject-Introspected bindings. But that's true
for all other ops anyway.
I guess what should happen (quickly-ish) after 3.0 release is a libgimp
utility function which does the heavy lifting of creating a GEGL graph
for us, and for script-fu probably a special-case binding or something.
I realized it is redundant with gimp_fonts_get_list() which is a bit
more complicated to use but also more powerful. Let's see if we ever
need the simpler utility function in the future.
- s/gimp_buffers_get_list/gimp_buffers_get_name_list/
- s/gimp_context_get_dynamics/gimp_context_get_dynamics_name/
- s/gimp_context_set_dynamics/gimp_context_set_dynamics_name/
- s/gimp_dynamics_get_list/gimp_dynamics_get_name_list/
Named buffers and dynamics don't have their own classes. Using
*_get_name_list() will make sure that *_get_list() is available so that
we have constant naming if we add the new types, even during the 3.0
series. Same for the gimp_context_*() functions.
Note that the buffer API in particular has a few more functions which
we'd like to be able to reuse (e.g. gimp_buffer_rename()) with a proper
type. But we'll probably name this type GimpNamedBuffer anyway
(GimpBuffer is too similarly-named with GeglBuffer IMO) so it will be
easy to create new API for the new type.
See also #12268.
There are 2 *_get_list() for buffers and dynamics but since we don't
have clases for these, they still just return a list of names for now.
I opened #12268 for further thinking on these.
In a28b1bad, we ported the darktable detection code to use their
new API for darktable 4.6.1. However, the image and thumbnail loading
code was not ported as it still worked fine in that version. This patch
continues the port by making the the image and thumbnail functions
use the new API if darktable 4.6+ is installed.
Fixes: #12237
We were building with that option disabled here because it was making our
runners to randomly fail at building it. However, that option disabled also
makes some machines to fail, due to its low-level nature. So, there is no
fix for it(?), let's enable then and hope the runners willn't fail again.
Despite building GIMP with Clang helped a lot to make our deps builds robust,
it is very hard to maintain, not because of LLVM but because of freedesktop.
We needed to ensure that the branch of LLVM matched the one of freedesktop on
which GNOME SDK is based. That stopped to work resulting on bad inconsistency:
1) flathub never had a problem; 2) GNOME runners sometimes worked, others not;
3) locally it stopped to work completely, so the .json right now is unportable.
Some annoying bugs were:
- "error: Requested extension *llvm* not installed"
- "Similar refs found for *llvm*"
So, let's end this not using any extension anymore while keeping only the nice
improvements in the custom builds.
GNOME docker image and Flathub runner seems to use edge flatpak-builder,
which auto set -DCMAKE_INSTALL_LIBDIR option, crucial for some deps.
Pre-1.4.3 versions don't do this so the build fails in some machines.
Let's prevent this making the script more clear about flatpak-builder.
...with gtk_icon_theme_add_resource_path (). Per Wormnest in !1027, this function
might not even be necessary at all. But until removing it can be completely tested,
this patch at least removes the deprecation warning for GIMP 3.0 RC1.
Pelican did not like a quoted date and produced an error. Not sure what
changed, because pretty sure this output used to work fine, but…
whatever, let's fix it.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
Like GIFs, Amiga IFFs can have pixel aspect ratios that aren't 1 to 1.
We have a warning for users when they load these kind of IFFs, so
they know to switch Dot for Dot mode off.
However, unlike GIFs, we don't have a thumbnail loader for IFFs.
So, this warning pops up even when users are scrolling through the
file dialogue. Since many Amiga IFFs have alternate PAR values, this
means a lot of pop-ups. This patch adds essentially a "dummy" thumbnail
procedure so we can stifle this warning unless we're actually loading
the IFF image.
So this one is a complicated beast, because inside the flatpak's
sandbox, ~/.var/ will not be the same as on the host (even with home
permission). In particular, we won't be able to find the 2.10 config folder in
there when running GIMP 3.
Yet local ~/.var/app/org.gimp.GIMP/config/ is in fact be mounted to
/var/config/! So inside the sandbox, this is where we must look in to
find a previous 2.10 config folder.
With this change, both flatpak and non-flatpak GIMP should be able to
find a 2.10 config folder both in the host XDG_CONFIG_HOME and inside
~/.var/ by:
* First looking inside XDG_CONFIG_HOME;
* Then looking in ~/.var/app/org.gimp.GIMP/config/ (which in non-flatpak
environment will find a former flatpak config folder);
* Finally looking in /var/config/, but only is /.flatpak-info exists (so
we are in a flatpak, and in there, this is the mapping for the host
~/.var).
This is not tested inside the flatpak sandbox yet.
This was bothering me that we were keeping these macros marked as legacy
in our public headers. Now they aren't so we can delete the whole file
when we'll finally get rid of all usage later, without breaking API.
The param option just contains an options object, not a separate
capabilities. Also even when passing the options object across the wire,
the capabilities within this object are not part of the "options". These
are actually handled separated by GimpExportProcedure.
Therefore the changes are:
* GimpExportCapabilities moved to gimpbaseenums.h with a proper GType.
* "capabilities" properties are changed to flags param spec with type
GimpExportCapabilities.
* GimpParamSpecExportOptions doesn't have a capabilities variable
anymore.
* Consequently gimp_param_spec_export_options() doesn't have a
capabilities arg.
* Wire protocol updated as we don't need to pass any capabilities
neither for the param definition, nor for the argument values.
* GimpExportOptionsEditFunc renamed GimpExportGetCapabilitiesFunc and
returning GimpExportCapabilities flags, instead of setting the
"capabilities" property. I believe it makes it much more obvious what
this callback is for and how to use it.
* Annotations improved or completed.
* Don't make the GimpParamSpecExportOptions public anymore since it is
the same as its parent.
The whole widget was made deprecated in 2006 (commit 99f979e118) but it
is still being used by another widget. Since we can break API, I at
least hide the functions and type by making these private.
This will give us time to think if we really need this widget (or a
nicer implementation for this widget) or if we just want to get rid of
it.
This patch adds additional error handling
to the BMP plug-in. It also translates certain
variable names from German to English,
replaces magic numbers with existing
constants, and simplifies some formulas.
* Don't mention 2.99 anymore.
* GIMP_PKGCONFIG_VERSION was actually the version of libgimp regarding
our .pc file, not our pkg-config requirement (per the commit removing
autotools scripts). Now it looks like our pkg-config minimum
requirement used to be version 0.16, but I didn't add this check back.
Let's assume just saying "a recent version" in the INSTALL file is
enough, without hard-check in meson.
* Simplify the end part about failed configuration or optional features,
with a link to our build tutorial online instead of getting into
details and advices to set LDFLAGS or CPPFLAGS (which to be fair, am
not sure are very good advices at all in fact!).
* Fix a few more details.
Currently the search feature in the Layer dockable is also visible on
the Paths and Channels dockable as well. However, it has hardcoded
strings that refer to layers, and it uses gimp_item_list_get_items_by_substr ()
which only works on layers. We should hide it for 3.0RC1 and implement
it for the other two ItemTreeView children afterwards.
I'm surprised that Idriss and Shubham were not already in the file!
Also adding Denis for his design work, and Sevenix for the splash
screen.
Bruno was added for the awesome work in packaging and CI. Even though
it's not GIMP itself, it definitely counts as code and original work.
I didn't add the new GSoC contributors because Varun's work is
essentially in GEGL (which has its own credits) and there was no major
original feature pushed by Cheesequake unfortunately, only bugfixes. So
I'm unsure if we can add them.
While the work on NULL-terminated array types make it much easier in C,
bindings don't have enough information to create native array/list types
in some generic functions such as g_object_get|set(), or else we just
don't know the right annotations to use for this to be possible. This is
report gobject-introspection#492.
So for the time being, we are creating dedicated functions for GeglColor
arrays and for other core object arrays (arrays of images, items, etc.).
E.g. in Python, while you can set a single GimpImage like this:
> config.set_property('image', image)
… you need to set a list of images like this:
> config.set_core_object_array('images', [image1, image2])
Checking the log, it looks like this code has not been touched since
2007, so whatever this various was used for, it's clearly not been used
for a long time.
Fixes warning:
> libgimpwidgets/gimpcairo-utils.c:80:16: warning: variable 'total_length' set but not used [-Wunused-but-set-variable]
Fix warning:
> plug-ins/file-dds/dxt.c:113:1: warning: unused function 'pack_rgb565'
I don't just remove it as I guess it may be of use at some point for a
not-yet fully implemented feature yet?
Avoid the stack smashing bug from yesterday in other functions.
Additionally to fixing other functions, do not cast the pointer to size
in the PDB generation scripts so that we can quickly spot such bugs in
the future, through compilation time warnings, instead of hiding them.
Currently there are 5 separate plug-in-gauss
functions. IIR2 and RLE2 are not used, and
IIR and RLE are identical to each other.
Additionally, they all call a separate
gaussian_blur () function which multiples
two parameters by 0.32 to convert to the
actual GEGL operation.
This patch removes all functions except
for plug-in-gauss. It converts each
existing script that used one of the other
variants to use plug-in-gauss, and
multiples the coefficients by 0.32 so that
plug-in-gauss behaves the same as calling
gegl:gaussian-blur with a C plug-in.
There also exists a plug_in_pixelize2 ()
function in the PDB which allows the user to set
both the pixel width and height.
This patch converts this to become
plug_in_pixelize (), and removes the older
function which used a single width
parameter for both values.
When linking with clang/lld, I had the following linking error:
> ld.lld: error: undefined symbol: pow
As a side change, also adding math.h header include, even though it
didn't seem to break compilation. Just to be thorough.
Additionally to fixing a deprecation, I also ensure that we don't limit
pointer source to what the system considers the "Core Pointer" on
Wayland.
It is another bug similar to #8016 and possibly what !924 was trying to
fix, even though it turned out this was not the same problem which I
initially reported. In this other variant, when you were hitting Space,
it would originate from the "Core Keyboard" which was associated to a
"Core Pointer". On a laptop, this Core Pointer could be the trackpoint
for instance (in my case) so you could pan with Space + trackpoint move.
Yet say you add a graphics tablet, which is a separate pointer: you
could not pan with Space + stylus move!
Now you can, because when we are pan-spacing, events from all pointer
sources are accepted. Only when the panning comes from a pointer source
(middle click) do we listen only events from this same pointer device.
This reverts commit 413cf9ad85.
As discussed with mitch during last Wilber Week, and commented in !924,
the fix was creating new problem and was not right. We definitely want
to grab pointer events when panning (or other similar interactions).
Also I think I had not tested under Wayland back then, only verified I
didn't see any huge issue on X11, but the commit did not in fact fix the
original issue #8016 (this time, I verified!). The problem I was
encountering seem to be more in how Wayland works + libinput, not giving
full control on input devices to applications and trying to be "smart"
with an option ("Disable Touchpad While Typing") which is often useful,
but other times counter-productive (e.g. in GIMP when we want to
space-panning — which should not be considered typing —, or again
shortcuts in video games, and so on).
When the passed code had a bug, the plug-in was crashing along with the
code given in argument. Instead, we must catch all exceptions and pass
the error message raised by exec() to the core application.
Since commit 4e499810, GIMP could crash on switching to
multi-window mode on X11 Linux systems.
As suggested by Alx Sa it is enough to add a NULL check for
shell to avoid the crash.
From now, Windows contributors can use the default shell provided by the OS
(which is PS since Windows build 10.0.14971.0), like Linux and macOS users do.
We still use MSYS2 but not the POSIX shell. This change adds these features:
'1_build-deps-msys2.sh' is now '1_build-deps-msys2.ps1'
- Faster clonning by using 'git-scm' (the MSYS2 one had performance problems)
- Easier to use non-MSYS2 binaries, not only 'git-scm' but also official meson,
deps from vckpg etc. This is a needed step towards the future use of MSVC.
'2_build-gimp-msys2.sh' is now '2_build-gimp-msys2.ps1'
- By default, vanilla builds (normally triggered on PS) will create a bundle,
dropping the need of 'gimp.cmd' (that adressed .typelib and .interp limits),
which is inline with other (Cmake-based) projects like Darktable and Inkscape.
This change is important because even Windows devs more experienced than me
get confused with the relocatibility stuff, which is the default on Windows.
'2_bundle-gimp-uni_base.sh'
- As a result of the change above, bundling code was changed to be a bit faster.
It still is, however, painfully slow, since meson doesn't have a 'install()'
function like Cmake to prepend targets in Ninja's 'install_manifest.txt'.
Since we are not using a POSIX shell (nor 'mintty') anymore:
- GIMP can be built from every path easily with R. Click "Open Terminal", with
IDE integrations etc, without needing to manual tweak MSYS2 .ini files etc.
We could tweak MSYS2 to get the features above but not top-tier integration.
- Developers can be more aware of Windows native vars, paths etc, and avoid bugs
Some build files were improved to support the 'Windows way of doing things'.
- No need to close and reopen terminal anymore after running 'pacman -Suy'!
---
REGRESSION: Vala plug-ins are temporarely gone due to 'vapigen' bugs, a small
regression since this is a gnomeish language but I will investigate how to fix.
In 41894be7, GIMP_COLOR_PROFILE_POLICY_KEEP was accidentally
used instead of GIMP_METADATA_ROTATION_POLICY_KEEP as the
possible output of gimp_image_metadata_rotate_dialog ().
Fortunately they are currently the same value, but it would be best to
return the right enum type.
GimpControllerEditor's "Select Controller Event Action" dialogue has
a border around the standard icon. This is because it uses a GimpViewableDialog,
which normally shows the current image or layer as the right side icon (and thus
needs a border to potentially distinguish).
Since this is a special case, this patch retrieves the GimpViewRenderer for the icon
and then sets the border color to transparent.
After we converted most scripts in the repo to use new registration functions,
there are no *filters* left from version 2.
But version 2 filters are still supported, with a warning
to the console like "image procedures ... only one drawable ... are deprecated."
A version 2 filter uses
the deprecated registration function script-fu-register
and declares args img and drawable (singular) explicitly
(contrary to encouraged multi-layer capable.)
Until we actually obsolete scripts of this ilk,
we need this test plugin for testing.
Resolves #12226.
GimpGradientEditor's saved_color array was
converted to GeglColor as part of the color
space invasion. However, we were still
treating it as if it was a GimpRGB array, so
we'd use gegl_color_set_pixel () to convert
it for gimp_action_group_set_action_color ().
This resulted in the menu displaying empty colors.
This patch removes the unnecessary conversions
and passed the saved_color values directly so that
they show up in the menu.
Per Lloyd Konneker, all Python plug-ins except
histogram-export and gradients-save-as-css
have "python-fu-" in front of their name.
In fact, gradients-save-as-css does have
this prefix in some places already.
Since this is also how it was written in 2.10,
let's rename them now to be consistent.
As reported by Anders in !1919. This is because
gimp_pdb_execute_procedure_by_name() now expects a proper GimpArray for
float and int arrays, not a C array preceded by a size value.
Generated libgimp functions' arguments are normally tested through the
PDB, so that you get proper error messages when trying to call a
function with invalid arguments.
This is not true anymore for array arguments since the size argument is
not a PDB arg, only in the C function. Therefore I'm adding an
infrastructure asserting on invalid size, using the same PDB type
annotations as other args. It is important to assert valid input on
plug-in side (i.e. libgimp) so that the core doesn't make any assumption
on having received valid input when it has not.
Also changing size argument of gimppainttools PDB-generated functions to
proper gsize.
Yet they still are generated libgimp functions' arguments.
For instance gimp_context_get_line_dash_pattern() still has a num_dashes
integer argument and a dashes C array, but when calling the PDB
procedure "gimp-context-get-line-dash-pattern", we only set the
GimpArray.
This will allow simpler direct PDB calls too, included in script-fu,
where the size argument is really redundant.
GimpArray (and therefore the int32 array typedef) contains its own size.
We don't need to store the array size in a preceding argument.
Also adding gimp_int32_array_get_values() and gimp_int32_array_set_values()
to edit an existing GimpArray.
This comes with the fact we should start making the GimpArray type more
explicit, because clearly by trying to hide this type so much, it was
too much looking like the int32 array param spec was expecting a C array
(as was visible in the file-ico plug-in where we were getting a C array,
which was a bug only made invisible by the fact we were not setting the
C array back in the config object in the end).
Last but not least, I finally implemented int32 array (de)serialization.
As a side fix, the "images" arg in file-pdf-export-multi procedure is
now a proper image array (not an int32 array), and of course the "count"
arg was removed.
PDB code is now looking directly into the GimpArray length for
determining the data length.
Also adding a 'size' argument (number of elements, not bytes) to
gimp_value_(get|dup)_int32_array() to make it actually introspectable.
Until now, it was somehow introspected but was segfaulting on run.
I.e. that, e.g. in Python, calling Gimp.value_set_int32_array(v, [1, 2, 3])
followed by Gimp.value_get_int32_array(v) would actually make a
segmentation fault. Now the binding works flawlessly.
This will also make these functions much more usable in general.
… PDB type.
This is a first step for #7369. Clearly our GimpObjectArray was meant to
be used with C arrays, hence the wrapper function
gimp_value_set_object_array() which was taking a C array and actually
creating and setting a GimpObjectArray.
This is why our new type is actually a C array aliased as a boxed type
and containing its own size (thanks to NULL-termination).
Eventually GimpCoreObjectArray is meant to replace GimpObjectArray.
The only issue is that such a type does not allow NULL as a valid
element in such an array, but fact is that I don't think we currently
have any use case where this matters. If ever such a case arise in the
future, we may introduce back GimpObjectArray.
In this first commit, I replaced all itemarray PDB types with a new
drawablearray using this new boxed type when relevant.
For some symbols defined or deprecated in GIMP 2 and obsolete in GIMP 3.
ScriptFu automatically loaded these definitions
during development of GIMP 3 (from 2.99 to 3.0rc1).
That is no longer the case.
A third-party script CAN load them explicitly.
We discourage that, for scripts to be shared,
but it is convenient for private use.
PDB-compat-v2.scm is also an executable definition of renamings,
useful as a cross check of published documents re porting plugins
from v2 to v3.
So an editor recognizes them.
Renames script-fu.init to init.scm since that is a Scheme convention.
Scheme interpreter maintainers expect that name.
The same name as upstream TinyScheme.
When mingled with plugin scripts, they needed a non-standard suffix .init.
Which makes an editor not recognize them.
Which deviates from Scheme convention for the main init script: init.scm.
The separate directory is also a place for script authors
to put Scheme scripts they don't want loaded automatically,
but when a script calls Scheme load function.
No change to observable behavior in the app or ScriptFu tools.
This is rarely done.
Most script plugins call PDB functions that are GIMP INTERNAL (gimp-foo)
or filter plugins that wrap Gegl filters (plug-in-foo).
But a Scheme script plugin can call other script plugins (script-fu-foo).
When a script does call another script,
it can be within the interpreter (purely in Scheme),
or to an interpreter in another process (via the PDB, with binding.)
It can get complicated using the optional v3 binding of return values.
This tests and illustrates different cases.
Mostly one word substitutions.
A few function definitions were moved to the scope of
a single script that used them.
Those functions won't be available to third party scripts
except now by cut and paste.
For major release 3.0.
When the function is not trivially substituted with a call to a Scheme R5RS function.
In other words, compatibility definitions that are not just an alias from SIOD to R5RS
Scheme dialects.
The prior removal was based on comments in the code,
saying the functions could easily be removed.
It turns out the functions are used in the repo, and not easily replaced.
Third party scripts may suffer the same dilemma:
use SIOD functions that are not trivially replaced.
This commit only fixes the dilemma for the scripts in the GIMP repo.
Reverted and kept:
*pi* symbol for math constant
cons-array an obscure function of unknown origin
butlast a function in some Scheme dialects but apparently not in R5RS
These MIGHT be removed in the future, with more work.
Leaves the mechanism in place, but erases all rows of the alias map data.
Update devel-doc to say ScriptFu has its own mechanism for aliasing.
For major release 3.0
Resolves issue #12203.
Similar to d87c728f, dragging a layer over to a new image via
the tabs uses gimp_image_new_from_drawable () and only
copies a single layer. This patch adds the filter copy code
here as well.
This patch adds a pdb getter/setter for GimpStrokeOptions'
emulate-brush-dynamics property. This allows users to change
the "Direction" of strokes via Script-fu/Python API calls.
Resolves #12198.
When dragging a layer to the toolbox to create a new
image, we weren't copying over the filters. This is because
that action still uses gimp_image_new_from_drawable ()
rather than the multi-layer capable gimp_image_new_from_drawables ()
function.
For now, we'll fix the immediate problem by implementing the filter
copy code in this function. Long term, we should port that code to
use gimp_image_new_from_drawables () instead.
Per Anders Jonsson, the grid colors can have semi-transparency even
if the image itself has no alpha channel. This patch always sets the
GeglColor's babl format to contain an Alpha channel, rather than reusing
the image's color format. The index used for alpha is also updated to
adjust to the number of channels, since GimpRGB previously always used
index 3 for both RGB and Grayscale images.
Call them on different modes of image
and different sizes of image.
Motivated by faults discovered in denoise filter for small images.
No faults detected by new tests.
ScriptFu: tests: enhance testing of gegl wrapper plugins
Add tests on other image modes.
Add tests on small images.
No changes except to tests.
After changes to API:
Colormap=>Palette
Vectors=>Path
After changes to ScriptFu handling of color.
Misc upgrade of tests to use-v3 binding
Revise handling of GeglColor, formerly GimpRGB.
Marshall to/from Scheme lists of numeric.
Marshall from string CSS names and notations.
Conversion to/from GRAY, GRAYA, RGB, RGBA.
See color.scm test script.
Similar to previous commit. If we don't want people to use this function
yet need to export it, at least don't expose the declaration in shipped
headers and even less in the API docs.
Since we consider it private, yet it's still needed in libgimp and app,
let's at least put it in a private header because there is no need for
people to try it out.
I'm also editing a bit the annotations for gimp_main() and GIMP_MAIN().
As part of the color space invasion, we
converted the IFS Compose colors to
GeglColor. However, we forgot to initialize
them when we create a new AFFElement
in undo_update (). As a result, when we
try to clear them out later in aff_element_free (),
the plug-in crashes.
This patch resolves the issues by initializing
the five GeglColors on creation.
...to gimp_drawable_has_visible_filters ().
With NDE filters, it's now possible to have
filters that are not active but still attached
to a layer. This patch renames the API to
prevent confusion as seen in prior
commits.
Similar to afc0a6d1, we need to use gimp_drawable_get_filters () to
get the total number of filters rather than gimp_drawable_has_filters (),
which just returns if any filters in the stack are active/visible.
Because of this, we weren't updating the XCF version to 22 when we
saved a file that had all of its layer effects set to invisible/inactive.
Always update stored colors. When colors are perceptually identical, we
only bypass color rendering code, but not the color value update (even
small value updates need to be echoed across the code, so that what is
shown is always what is set).
With NDE, we can now edit a filter when another layer is selected. This
broke an assumption in GimpFilterTool that the selected layer is the same
as the layer the current filter is applied to.
This patch fixes the problem by checking if the filter is being editing, and then
using either the filter's drawable or tool->drawables->data accordingly.
The previous comment is wrong, because GIMP never had WMF export. Let's
clarify, however, that WMF support is still tricky because of some
options available at configure time regarding 'fontmap' and so on.
Prior commits porting these scripts to v3 dialect
incorrectly compared SF-TOGGLE args to #t and #f.
They are bound to TRUE and FALSE, 1 and 0,
before choice of dialect can take effect.
This was already the case because gegl_operation_get_format() had no
space (i.e. default, sRGB). it's not the source format.
But let's make it clearer because otherwise on a short skimming, it
looks like we are working on the source space.
Also adding a comment on why working on the source space is not a good
idea right now anyway (it's *very* slow for anything but sRGB).
Local certification with WACK is optional and useful to anticipate if
the MSIX will be refused by Partner Center's online certification.
(Just to note: On Windows SDK, certification is not equal to signing.
It's more a checklist process to see if the package is suitable to run.)
To avoid needing the full script to be run with admin rights (which
would be scary) this feature only works with a bunch of requirements:
1. sudo for Windows (so Windows 11 24H2)...
2. enabled in normal (aka inline) mode...
3. in a Windows account in admin group
The 2nd and, specially, the last one are harsh but this is sudo's design:
https://github.com/microsoft/sudo/issues/108https://github.com/microsoft/sudo/discussions/68
Running Color Balance on an image with profile was very slow.
This is because we have special conversion path for sRGB "R'G'B'" in
babl (since babl@90da256), but all the other color spaces are going
through the generic path which does the double conversion to linear RGB
then to 2.2 gamma. And that's slow.
I'm not 100% sure it's right, especially as I'm seeing some CLAMPing
going on (but I'm not sure if removing it is right either) which means
we will likely not cover the full target space in the end.
I'm letting it go because when we'll add proper version support to GEGL
ops, we will be able to improve the algorithm without breaking XCF files
with this filter.
At least now we don't have over-slow Color Balance.
As side improvements, I'm cleaning up a bit the code, which is mostly
micro-optimizations at this point.
This completes the GimpRGB API removal
project for the color space invasion.
Note that the GIMP_RGB_LUMINANCE macro is
temporarily moved to gimpcolor. It does not
require GimpRGB but was included in gimprgb.h.
We are getting HTTP error 429 probably because it's a highly requested file,
and this is causing pipelines to fail at CI lint. Let's fix this with mirrors.
Commit abf0c1c272 fixed the inconsistency of showing "R" for RGB's Red
channel selected whereas the actually displayed selection UI was "H" for
HSV's Hue channel.
As a consequence of this fix, now we were indeed displayed "R". Yet
people got used to working with the Hue channel (and LC plane) for
at least a dozen years. Let's make "H" the officially displayed channel.
During the GAction port, we removed gtk_alignment_new () from the
Animation Playback plug-in as it was deprecated in GTK 3.14.
However, this caused the drawing area to be put on the left side of
the window.
This patch reimplements the alignment feature using gtk_widget_set_halign ()
and gtk_widget_set_valign (), to keep the animation in the center of the dialogue.
Resolves #12160
Currently, GEGL Graph and filters with Aux nodes can only be
applied destructively. Therefore, we need to add a restriction so
they can't be applied when a layer group is selected.
Certain tools like Levels and Brightness-Contrast allow you
to convert it to another filter live. This happened by creating a new
tool, so if you were editing an existing filter, the connection was lost
and duplicate filters were created.
This patch copies any existing filter to the new tool and updates the
name and icon to the new filter type when saved.
During the GimpProcedureDialog port, newly generated widgets were
connected to bender_global_notify (). However, GimpProcedureConfig was
connected to it rather than a GtkWidget, which caused the function to return
without updating since it did not have access to the BenderDialog object.
This patch connects the function to the individual rotate, smoothing, and
anti-aliasing widgets to resolve the issue.
This file was added in commit 21ffb58903 to replace the list in
4_dist-gimp-inno.ps1. The older list used to be verified for missing
langs in the test-installer-langs.sh unit test, but the test was removed
and never replaced. This is why now when a new language is added and it
is missing in iso_639_custom.xml, it goes unnoticed until failing in
dist-installer-weekly job.
Rather than the previously reverted commit, the proper solution is:
* gimp_color_selector_set_color() must not test for perceptual identity
because GimpColorSelector is too much of a generic class. In some
case, such a test may be worth it to limit costly updates (in
particular when it implies some rendering of color surfaces), but this
would happen in specific subclasses.
* In GimpColorSelection, the GimpColorScales show numbers, so any change
in them will likely trigger other scales to change as a side effect.
Therefore when handling the "color-changed" signal on these scales,
however small the change may be, we want to run the update.
Now removing this test in gimp_color_selector_set_color() also revealed
a serious bug which I fix in this commit, which is that the binding
between the "value" of a GimpLabelSpin with the "value" of its
adjustment was still triggering repeated property-setting, which was
enough to freeze the GUI for a while. The logic of using only the
GtkAdjustment's value as a source while also binding both properties was
not robust enough. Instead the GimpLabelSpin will now store its own
value and the binding will simply keep it in sync with the one in the
adjustment.
Note that this is also part of the solution for #10998, because it means
there were cases where the color displayed in scales of the color
selection dialog was not actually the color set as foreground or
background.
This reverts commit bdddc94151.
This commit was not fixing the issue the proper way and was creating new
issues.
The real problem was that for very small increments at a time, a color
change could be perceptually identical to the previous color and
therefore not trigger color updates down to subclasses.
The reverted commit was trying to work around this by not updating the
GimpColorSelector color when it was perceptually identical (therefore
next check may be a bigger color distance), but this was definitely not
right. It was creating inconsistency in the stored color with the
actually selected one and that was the root for more issues.
See the next commit for a proper fix.
Oh and by the way, there was no leak, unlike what the reverted commit
message was saying. The old color was freed. ;-)
By default, the GimpColorSelect widget is set to show HSV with Hue
selected but we weren't selecting the channel which was defaulting to
"Red" of RGB. Therefore there was some inconsistency when first opening
the color selection dialog which was showing HSV colors on the left, yet
with "Red" selected on the right.
This fixes the inconsistency, which also allows parent or container code
to set the default they want (which is indeed RGB).
Do not only show the space, but also the model. For instance both RGB
and HSV can have the same profiles.
As for LCH, we must not show any space (it is based on CIELAB).
Note that I use the string "Model: %s" which is already used in
libgimpcolor, so I am not breaking string freeze. The "%s - %s" string
though is not localized, even though ideally it should be (and possibly
even be a better joining string in English), but I don't want to break
string freeze for this.
This issue is part of the fix for #10998, more as a UX issue than a bug
per-se. Depending on how you were selecting a color, now you might
select it as HSV, LCh or some other model (this was **not** the case
before, even though the GUI was similar. Yet the stored color was always
RGB. Now it's actually "whatever you choose"). As a consequence, it is
possible that choosing a color in another model may convert to slightly
different numbers, especially within decimal places. I don't think it
was the main issue, but it certainly doesn't help. Now we may be making
clearer what color model is being used in the GimpColorSelect color
areas.
This eliminates the CRITICAL, which was harmless anyway.
As discussed in the issue, there are more issues:
1. The "shift-start" action is not documented in the user manual.
2. The "shift-start" action quietly does nothing in the case
it has nothing to do. Better GUI would be to disable the menu item in that case.
3. The "shift-start" action is non-intuitive, even bizarre.
It could probably be eliminated.
I myself don't understand the use case, and confused it for Path>Reverse.
An alternative fix is to disable the menu item when a handle is the operand.
This fix is better because it gives the user more places to RMB a context menu,
and the context menu mutates less.
Probably needs backport to 2.10.
Gradient Flare still used gimp_dialog_run ()
for its GimpProcedureDialog, so the Reset
button was treated as Cancel. This fixes it
so that it's usable.
Code that updates the main dialogue preview and the editing dialogue
preview were conflicting with each other, setting various strings to NULL.
This patch turns off the main dialogue preview updating code when the edit
dialogue is open, to prevent this overwriting behavior.
* Do not force-clip effects with a mask. Otherwise when adding a filter,
it initially renders fine (and can cross its input extents), but once
applied, it's suddenly clipped. That's not what we want.
* Fix gimp_filter_stack_get_bounding_box() computation.
* Fix the crop_before area when there was a selection. We have in fact
to start at 0×0 on input and only use width×height dimensions.
Previously filters were cropped to the layer size in the
"crop_before" node. This was fine when we had destructive-only
filters, but now that we can multiple active layers, this causes
new layers to crop the prior ones if they're larger than the layer
(e.g. If gegl:drop-shadow goes out of the layer boundaries)
This patch sets the crop_before to the current sizes, then searches
the filter stack to see if there's a filter that needs a larger width
or height (or if it needs a smaller x or y values), then sets the crop
to that size. This crop update is also run when a filter is raised or
lowered.
This fixes building with the option -Dwindows-installer=true. We should
**never** hardcode the build directory like what was done in this
script.
Also bumping gimp-data where some scripts had similar issues which were
only visible with -Dwindows-installer=true.
Previously we used gimp_drawable_has_filters ()
to detect if a layer had any filters set.
However, this function only gets active
filters, leading to filters with their
visibility set to FALSE not being copied.
This patch checks the number of children
in the filter stack container instead to get
an accurate filter count.
This patch ports the Add/Subtract mode
shortcuts from GimpSelectionTool to
GimpPaintSelectionTool, implementing
the unfinished gimp_paint_select_tool_modifier_key ()
function. The UI itself is left unchanged.
When setting a new palette, we must not use the new palette format
restriction (especially if it has none!), but the indexed image's
format, which is unchanged anyway. So move the call to
gimp_palette_restrict_format() into gimp_image_colormap_update_formats()
and use the correct format to restrict to.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/12108#note_2238182
gimp_size_entry_eevl_unit_resolver () loops through all valid units
to find a match for user's inputted value in GimpSizeEntry.
It runs until gimp_unit_get_by_id () returns NULL, where it does a
final check on GIMP_UNIT_PERCENT.
Due to a small logic error, we kept setting the GimpUnit to
gimp_unit_percent () each time it was NULL, so the loop ran forever.
Per Jehan, this patch breaks the logic up so that we terminate the
loop once the percent check fails.
Some filters such as gegl:spiral have properties which limit
their width and height, separate from the gegl:crop nodes in
GimpDrawableFilter. As a result, they won't scale when the layer
or image is resized even if the crop is updated.
This patch checks if there's a "width" or "height" property with
the "output-extent" role in the filter, and updates those properties
to make sure it resizes correctly. Renders made from selections
are not modified, as the user specifically chose that size.
Building with clang i have "missing sentinel in function call" warning. The C callers to such functions use the C NULL definition (ie ((void*)0)), which is a valid sentinel. However the C++ NULL definition (ie 0L), is not a valid sentinel without an explicit cast to a pointer type.
Commit 5b981adc7f was not taking into account that on Windows, the
gimp_resource_select_*() functions were made invisible and still needed
to be in the def file.
So this makes the 2 functions technically still exposed in the binary
even though the functions stay officially private (they are not in
header) and people are not supposed to use them directly in plug-ins.
… to GIMP_PDB_PROC_TYPE_PERSISTENT, let's rename some procedures.
s/gimp_plug_in_extension_enable/gimp_plug_in_persistent_enable/
s/gimp_plug_in_extension_process/gimp_plug_in_persistent_process/
s/gimp_procedure_extension_ready/gimp_procedure_persistent_ready/
Even though it's not public yet (and won't really be for GIMP 3.0), I
created a new concept of "GIMP Extension" (.gex files) which bundles
various types of data for GIMP, such as plug-ins but also brushes and
other resources, themes, icons, etc.
Having 2 different concepts named the same is confusing, especially
since one of them is not really self-explaining IMO (why are "always-ON"
plug-ins called "extensions"?). So even though this is the older
concept, and since we are anyway massively breaking the API for GIMP
3.0, let's rename this older concept. "Persistent Plug-Ins" is much more
self-defining.
The Fade curve is meant to use the widget's foreground color. The current
code detects this by checking if the curve's predefined color has an alpha
value of 0 - if it does, INPUT_COLOR (i) returns NULL and sends a NULL color
variable to gimp_curve_view_set_curve ().
However, since the GeglColor port, the "color" variable is an empty
GeglColor object rather than a pure NULL value. Thus, the line was always
drawn with the default GeglColor value which is difficult to see in light mode.
This patch adds a tertiary conditional statement so that a pure NULL is sent if
the alpha value is 0, rather than the color variable.
It may be more efficient this way on supported compilers.
Some of the private functions cannot be marked with this macro because
they are used across GIMP libraries (for instance some libgimp
functions are used in libgimpui, but are not meant to be public), while
they are not made public in headers. These are still considered private,
as far as API stability is concerned.
Preferences > Image Import and Export tab has various Export Policies,
which are mostly for safety reasons. One may want to default at never
exporting specific metadata. This got broken and anyway the logic was
not good enough.
Now these policies are followed in interactive mode, unless an export
has already happened for this specific export plug-in on this specific
file (in this case, we reuse the last values). We don't want settings to
unexpectedly change in such a case.
In last-vals and non-interactive run-mode though, we don't follow the
Preferences policies, since in the former case, we want to reuse exactly
the same settings (e.g. we don't want an Export discarding metadata
which explicitly checked in the Export As) and in the latter case, it is
the developer's responsibility to set up expected options.
gimp_image_metadata_load_prepare(), gimp_image_metadata_load_finish()
and gimp_image_metadata_save_finish() are only ever used internally now,
so there is no need to expose them.
If we realize that we need them as public functions later, or someone
reports a valid use case, we can always bring them back later.
Also improves a bit various annotations.
No changes except to tests.
Many tests of TinyScheme compliance to R5RS re numbers.
Tests issue 1049 "prints floats with commas" in non-English locale.
Some tests pass in English but fail in German.
Prepatory to a fix, so we know the fix works and doesn't break anything else.
The Default box.vertical style covers up
the Sample Point indexes that are drawn
with Cairo. This patch adds a style for the
GimpSamplePointEditor that sets its inner
box.vertical to transparent in order to
to make the indexes visible.
Following 78665ca372
Since our official builds tends to be vanilla (only using meson
standard options), there is no need to shipping these lua files.
This commit can be reverted in the future if Lua is stable again.
Symbolic layer tree icons are often invisible
when not selected on System themes in
light mode. This patch adds a CSS rule
to ensure the layer tree icons are visible
on light backgrounds.
As suggested by reviewers, use a better word.
Regular denotes size.
Procedure is the same word used in the classes in the code.
Procedure denotes a general procedure, without specialization.
Renames only where visible externally by script authors.
Internally, some functions are still named "_regular".
That can be changed later as a style issue.
Ported all supported/shipped Scheme plugins in the repo
that formerly called script-fu-register.
No test plugins were ported.
The plugins now use the new dialog, GimpProcedureDialog.
These are the plugins that are not filters i.e. not GimpImageProcedure,
which were ported earlier to script-fu-register-filter.
The test plugin Demo>Sphere demonstrates that while script-fu-register
is now deprecated, it still works, showing the old dialog.
Misc bug fix to prior commits.
Misc porting of same plugins to v3 binding of PDB return values.
Misc fixes: invalid default font names, and deprecated PDB calls.
Building on prior commits, with a few small fixes to them.
First demonstrable changes towards #12605.
Font map plugin is ported as a test case.
Old-style plugins using script-fu-register still work.
Fixes:
> PyGTKDeprecationWarning: Using positional arguments with the GObject constructor has been deprecated.
> Please specify keyword(s) for "label" or use a class specific constructor.
> See: https://wiki.gnome.org/PyGObject/InitializerDeprecations
This fixes a similar deprecation warning on various pieces of code:
> DeprecationWarning: Testing an element's truth value will always return True in future versions. Use specific 'len(elem)' or 'elem is not None' test instead.
> samples = log.find ("samples") or empty_element
GEGL graph is a free-form effect which can just run any other effect. It
is very useful for GEGL operation developers, but it's dangerous because
it allows running any of the operations, even the ones which cannot be
run through a GUI in GIMP, or the ones otherwise forbidden as layer
effects. In particular, you could run some of the sink effects to
overwrite local files, even with a vanilla GIMP.
So by default, we forbid the GEGL Graph tool to be used as a
non-destructive effect, and we discard any gegl:gegl layer effect found
in a XCF. Yet we leave a way for developers to create and load a GEGL
Graph effect through an environment variable which can be discovered
through appropriate warnings (on XCF load) and tooltip (in GEGL Graph
dialog).
As suggested by pippin, it would at least prevent loading XCF which
would override local files using default GEGL operations. Normally these
ops which writes to file cannot be created through the GUI, but a XCF
using one such op could easily be constructed.
Of course, this doesn't block third-party ops doing similar things
without being sink operation subclasses.
E.g. changing from non-linear to linear without bit-depth change would
trigger a CRITICAL on mask conversion, because masks are always linear
anyway. Only the bit-depth change should trigger a conversion.
Rather than showing actions as active when they'll just be no-op, make
these inactive.
There are more to fix this way, but these 2 had been really annoying me
for some time because they are very often run.
On generating our PDB files, we were
getting warnings about uninitialized strings.
This is because descriptions and authors
had been left off three .pdb files. Adding
these in resolved the warnings.
A new PDB author entry was also added
for Idriss Fekir.
The IPTC TimeCreated tag does not allow fractions of a second, while
Xmp.Photoshop.DateCreated (which includes the time) does allow this.
In our metadata editor we base our date/time on the last value and then
synchronize it with the IPTC date and time values.
While doing that, we did not check if the seconds had a fractional part.
To fix this we first check for the presence of a fraction by checking
for a dot in the time string.
Complicating factor is that a timezone difference may follow that,
which we want to keep if present. So we check for that too and
concatenate the parts we want.
These function names look like they should be applied to a
GimpPaletteEntry, which is a type which doesn't exist in libgimp. This
naming is much more appropriate.
Fix a generic case when gimp_window_set_transient() is called on an
already mapped window: the handle argument was missing.
The part in bmp-export though, in fact, I am still a bit at a loss.
Somehow calling gimp_window_set_transient() was making the dialog not
showing up at all, yet kinda blocking the bmp plug-in (waiting for a
response to the non-displayed dialog) and various features in the main
GIMP GUI too.
Calling gtk_widget_show() first, before setting transient was enough to
make the dialog finally work as it should, but this is really not ideal.
I compared to other cases in other plug-ins where the set_transient()
function was called before the dialog was shown and it is working fine.
I just cannot find the proper reason. So this will do for now.
They are now replaced by the more generic gimp_palette_[gs]et_colormap(),
hence making less of a particular concept of "image colormap". It's just
a palette attached to the image (and restricted to the image format).
When I see that we are just using R'G'B' format with no space
everywhere, I'm pretty sure some of this code must be wrong (even though
for some formats, maybe only sRGB is supported, I am guessing that for
some others, the palette may be in specific color spaces).
This will have to be improved with time.
In particular, palette's colors will want to be shown in their own space
(which may in fact be the image's space, for indexed image's colormap;
or in various spaces for named palettes).
Also make sure gimp_data_copy() also copies the proper palette format
restriction and apply it when necessary (e.g. setting the stored
colormap which is done when popping an image undo).
Otherwise we were losing format/space information, which was corrupting
color space when undoing then redoing.
It was an equality because I think the conversion from palette format to
"RGBA float" should go through the exact same babl code path, however it
is done in the API. And that is the case on my machine where I get
indeed perfect equality. But apparently not on the CI.
Though I guess investigating further would not be a bad idea, let's
consider this a minor issue (as a general rule, comparing float with
epsilon is still a recommended software usage), and just add a comment.
If execinfo.h was not found, do not try to compile gimpbacktrace-linux.c
because the backtrace() API is not optional there.
Also I'm further improving the meson summary, regarding "Dashboard
Backtraces". Rather than just yes/no to say if the traces are detailed,
let's go for finer-grained state, saying if the traces are completely
deactivated ("no", e.g. when execinfo.h is not found), or "rough" (when
libunwind and libbacktrace are not found) or "partially detailed" (one
of these is not found) and finally "detailed".
Also add info on missing dependency between parentheses to help
packagers find the proper dependencies to get to the "detailed" state.
GBytes are a bit annoying to handle, so I'm renaming the PDB procedure
to a private _gimp_palette_get_bytes() instead, and making a wrapper
function which returns a C array and both the number of colors or number
of bytes. The latter is needed for introspection (otherwise the binding
can't know the size of the C array), but for the C API, both these
returned integers can be considered redundant (since one can be computed
from the oher), so only one at a time is mandatory.
When we want to set a full palette based on an existing one, no need to
request the full colormap from core to libgimp then back. Just set the
palette which is nothing more than an empty shell around a resource ID.
I had this case with the palette of an indexed image which had its own
reference to the image. So the image would never be freed until the
palette is freed, while the palette is freed in GimpImage's dispose()
code.
Make this a weak reference from GimpData instead.
This is not necessarily a core bug, so I can't put this message as a
WARNING or CRITICAL. It may just be a plug-in which left some image
over. Nevertheless it is still useful information for plug-in
developers, same as it can also help core developers to discover actual
core bugs (see next commit).
I had the case when gimp_exit_idle_cleanup_stray_images() would clean up
some images on exit, apparently after the GtkApplication is itself
already gone.
We have a bunch of special-casing format passing through the PDB, but
either we were only passing the encoding, or else we were reconstructing
the full format through private intermediate functions. In the
space-invasion world, this is not right. Let's have a proper "format"
type for PDB which does all the relevant data-passing for us, once and
for all!
Note that I am creating a wrapper boxed type GimpBablFormat whose only
goal is to have recognizable GValue since Babl types don't have GType-s.
Moreover I'm not using the GeglParamSpecFormat either, because it just
uses pointers which again are a bit annoying in our various PDB code.
Having a simple boxed arg is better.
Since I use the Python console a lot myself to test GIMP API, the
ability to recall previously ran commands is extremely useful. Let's
just add support for this as an AUX argument. This was already done in
the Script-fu console, now in the Python console too!
gimp_scanner_parse_string() transforms the empty string into NULL, which
might be what we want elsewhere, but definitely not for GStrv since NULL
is the end flag for the string array.
A path on Windows contains backslashes, which got interpreted as
escape sequences in script-fu when selecting a filename by the call
to g_string_append_printf.
This caused failures in e.g. Stencil Chrome after selecting an
environment map image.
Use script_fu_strescape to escape the filepath, so that we correctly
interpret the Windows path.
See also
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1851#note_2225989
febb2126 was proposed temporarely while we had hope of having a fix.
Now, we have !1860 (apparently 99% done) but the main maintainer of
crossbuilds refused to look at it because he is focused on core code
until 3.0 so, with this timeframe, the commit lost its reason to exist.
So, to avoid keeping runners work unnecessarelly with abandoned jobs,
let's not trigger them ('when: never') as I proposed on IRC months ago.
On Linux the string for GPS coordinates was broken when the
string it was strtok:d from was freed. Move the free until we
have finished using the resulting string.
gimp_drawable_filter_apply () uses the current
selection as a boundary to draw/redraw a
filter. When editing a filter, if there's an
active selection created after the filter is
added, it interferes with the filter's redraw.
This patch adds a new gimp_drawable_filter_apply_with_mask ()
function, which can be called if we want
to use the existing filter's boundaries to
draw the new filter.
Symptom is "Arg 3 invalid or out of range". Issue not formally reported.
Broke because Distress Selection plugin signature changed: arg Threshold type Int=>Float
Refactor: extract methods for int and float range errors
Enhance by naming the called PDB procedure
This helps script authors find the location of an error.
These errors can occur either when first authoring a plugin,
when a user stresses a plugin in a way not previously tested,
or when a called PDB procedure or plugin changes an argument type or range.
Note that calls from SF scripts to other SF plugins
are not always via a PDB call and then not range checked.
Issue #3471 Unexpected results from luma darken only blend mode
Having the blend mode be perceptual results in the unexpected
result that a color with a lower actual XYZ "Y" value - that's
also clearly visibly darker than the underlying layer - can be
considered as "lighter" than a color with a higher "Y" value.
Reviewer's (Jehan) note: this only changes the default's blend space,
but in fact, we should probably even make the blend space immutable for
these 2 layer modes because the algorithm doesn't make sense in
perceptual (see #3471). We are not doing this right now in order to
not break existing XCF files using these modes in perceptual. We'll have
to figure out later how to have an immutable blend space going forward
while allowing the broken blend space but only for existing XCF images.
This should also fix the build on Windows wich fails with:
> ../app/app.c:537:7: error: call to undeclared function 'gimp_signal_private'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
Right now, running GIMP non-interactively (i.e. either as gimp-console
or with --no-interface) without --quit, the process was still exiting
immediately, yet not properly cleaning after itself. This is a
regression, since there used to be use cases with people wanting
long-running GIMP (for instance with a long-running plug-in waiting for
input through whatever inter-process communication method).
With this commit:
* GIMP now continues running when run non-interactively without --quit;
* It will catch SIGINT (typically Ctrl-C) and will quit cleanly when the
signal happens.
* At the end of the normal process (processing command line options,
such as opening images or running batch commands) and before going
on-hold, it will display some info text saying that the process can be
exited with SIGINT and informing that --quit exists if you were in
fact intending to quit immediately after the normal process actions.
* This also fixes the "gimp_finalize: list of contexts not empty upon
exit" WARNING we had when it was exiting without --quit (because of no
proper cleanup).
Note that I add some CLI text which ideally should be localized. But
since we are in string freeze, I am letting them untranslated with a
TODO (also assuming CLI-using people have more chances being used to
English, which may be or not a wrong assumption; but anyway most people
don't read the terminal output, and people running GIMP
non-interactively are even less).
Since this was not just an enhancement but also really a regression fix,
I prefer to do this now despite the string freeze and lack of
localization.
No intended change to function.
Style changes for easier reading.
Use v3 binding of PDB returns (elide many car), TRUE=>#t, etc.
Also condense trailing right parens to one line
Was "GRAY" without alpha.
Now "*" i.e. any image mode, w or w/o alpha.
The effect is more or less the same,
and should be exactly the same if the user submits a GRAY.
When the user does not choose a file of a secondary image,
use a copy of the primary image as the secondary image.
Rather than throw an error.
The filter still has effects, if not quite the same as when user
chooses a secondary image that is not the primary image.
Represent passed Gfile args having unknown files
or invalid GFile by an empty string.
Instead of by an error string.
A script can treat an empty string as a None choice of file,
or as a user error.
This was mixing 2 features: the debug on crash and performance logs in
the Dashboard dockable.
1. DrMingw is for debug on crash on Windows and has already a report in
the meson summary. So I remove it from the test.
2. Linux specifically with libbacktrace and/or libunwind and Windows but
only x86 (32/64) only are supported. Test updated.
3. Summary field updated to "Detailed backtraces (Dashboard)" for more
clarity.
Script authors declare defaults by name strings.
Which can be valid name, or empty string, or "from context".
ScriptFu declares formal arguments to the PDB,
either with a default GimpResource, or defaulting dynamically from context.
Works with both new-style dialogs (ProcedureDialog and ProcedureConfig)
or with old-style dialog (script-fu-interface.c)
This feature was broken during the initial
port to GimpProcedureConfig, due to the
Out Level parameters not being properly
clamped when interacted with. This patch
fixes the clamping and restores the call
to level_in_draw () to show the arrows.
It also sets the gamma widget's increments
to match 2.10's range.
Since the port to GimpProcedureDialog,
the Threshold label was not being shown
due to it accidentally having an invalid
tag, <-->.
This patch renames it to just "Threshold"
and updates the range to be clearer,
which was the purpose of the original
extended label.
Resolves #12034
Previously, we used the Filter Tool's drawable when updating an
existing filter. However, if the user has a different layer selected than
what the edited filter is attached to, the edited filter is always put at
the top of the filter stack.
This patch retrieves the drawable from the existing filter itself, rather
than assuming the filter tool's drawable is the same one.
GimpRGB replaced with gdouble arrays.
Note that some temporary intermediate
GimpRGBs objects were added, which will
be removed when map-object and
gimpoperationgradient are fully converted
in a separate commit.
When converting an image TRC (or a precision+TRC change), we used to
convert the profile to a linear (resp. sRGB TRC) variant or use the
builtin profile, which we'd set on the image.
Pippin is telling me that "it used to be that linear and non-linear
precision gave different results, rather than only about how things were
stored". Yet this is not needed anymore. Nowadays "RGBA foo" + any
profile is linear anyway, disregarding the profile's TRC.
Furthermore, this way, we don't lose the original TRC in a non-linear ->
linear -> non-linear roundtrip and we simplify the code, which fixes
such problems as shown in #3495 as a side effect.
The code was perfectly working already, yet we were blocking the
non-interactive case only to stop automatic runs, such as generating
thumbnails. The chosen solution is not perfect either as it would break
on the odd case where a given raw data file's expected dimensions were
the default. Yet it's a start.
Fortunately I caught this one, because the string values of the
GimpChoice argument would have been part of the API and confusing bits
per pixel and per channel is not so good for a graphic program! 😅
Only places this was alright were the grayscale ones, with no alpha
(where there is only one channel, so bpc and bpp are the same). I
hesitated a lot of I should write BPC to be consistent with other args
or not. In the end, I stick to BPP there, since I find it somehow
clearer this way.
Luckily this doesn't break string freeze because there was no mention of
what the bit-sizes represent in the arg labels.
We check the width of the zoom label (if it exists) and use it to size the
combobox's entry field. Otherwise, we default to the existing formula.
Also removes Windows special-casing for PERCENT_SPACING constant,
as Pango now uses harfbuzz on Windows as well.
This patch temporarily reverts 02546da7,
due to performance issues with our use
of Babl. After 3.0, we'll try to improve
these operations so they can be more
color correct.
However, GimpRGB, GimpHSV, and GimpHSL are
replaced with double arrays.
There are certain operations where we're
not yet getting sufficient performance with
Babl. For these legacy operations, we'll
use the original GimpHSV/HSL conversions
internally. This will allow us to replace
them in the future without plug-in
developers relying on them.
The name for internal data may be localized. This is the case at least
for some dynamic gradients (Foreground to Background and others).
Nevertheless they have unique collection name. So let's simply rely on
this for internal data.
See point 2 in: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1830#note_2218014
I also change the standard alias fonts to also have unique collection
names. These seem to be the only other internal data which had no unique
collection until now, which is now fixed.
This ensures that the devs who follows Debian instructions at gimp-web-devel
can build a full-featured GIMP and maybe we have a full-featured AppImage.
- Simplify three functions into 'bund_usr' (similar to 'bundle' in Win script)
- Add 'wipe_usr' function (similar to 'clean' in Win script)
- Verbose the steps of AppImage making
- Log (go)appimagetool bundling of deps (not only the the .appimage making)
- Change AppRun to be more clear about our .appimage compatibility
This refactoring is not perfect but is good enough to anyone understand
how our AppImage is made just reading the script.
Resolves #12018
During the port to GimpProcedureDialog, we accidentally
inverted the set_sensitive () logic for using RLE and the
RGB format. RLE was being locked for indexed images while
the RGB format was being locked for RGB images.
This patch inverts the two conditions to fix the issue.
..with gimp_bilinear_rgb ().
This function takes in a double array of raw pixels,
a boolean to determine if the pixels have an alpha channel,
and a reference to return the final pixel to.
Resolves #10822
After improvements by Lloyd Konneker and Jehan,
Script-fu's implementation of GimpProcedureDialog retains
defaults for GimpResources.
This patch ports lava.scm to use the new API, and also switches
the default gradient to Incandescent.
gimp_brushes_popup() was triggering a popup allowing to change not only
the brush, but also the "paint mode", the opacity and the spacing. As
far as I could see, this was used nowhere for the paint mode and
opacity.
As for the spacing, it looks like gfig was indeed getting this data,
except that the GimpBrushSelect was disabling the effect on this scale
by setting change_brush_spacing to FALSE when calling
gimp_brush_factory_view_new(), and even setting this to TRUE, it was not
working fine anyway. Rather than debugging this, let's simplify the API.
Such settings seems like additional paint settings which don't have to
be in the brush selection. If someone wants people to also select an
opacity, spacing or paint mode, it would be much more efficient to add
separate plug-in arguments for these.
Additionally, I fix GimpBrushFactoryView not to show the spacing scale
when change_brush_spacing was set to FALSE anyway. This is just a bogus
widget then, which can only confuse people.
Also fixes the passing of the resource param definitions through PDB.
There was some weird assumption, with a comment, in commit 73733335c8
that this was unneeded, which meant that we were not able to properly
recreate the right param spec over the wire.
After commit #a7bc5f07, these plug-ins assert in local_grad_data_refresh().
A comment is clearly stating that the widget must be allocated, so make
sure that the callback is only connected at allocation.
GimpOperationHueSaturation did not do
conversions since the source was already
HSL, so its GimpHSL object was replaced
with a float array.
Van-Gogh plug-in's RGB -> HSL
conversion was replaced with an
HSL float Babl format with gegl_buffer_sample ().
Since no conversion operations are performed, just getting the
RGBA values from the gradient and then using them, this replaces
GimpRGB and GimpRGB * with gdouble * equivalents.
Per Anders Jonsson, removing this fixes
the issue with the grid colors on System
themes. As it does not work anyway
(the grid would be red if it did) and the
theme code is much better than it was
six years ago, lets remove it.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
- There is no reason whatsoever to make gimp_param_resource_value_set_default()
a no-op on core side. Also remove the whole commenting on this basic
function, especially as it's mostly wrong (why would core not use
default values? Why would we not transfer ownership? That's the whole
point of g_value_set_object() which increases the reference, hence
transfer ownership to the new reference…)
- Also removes the comment on GimpParamResource which is just explaining
basic GObject stuff and would only confuse contributors.
- Small indentation or coding-style fixes.
Now you can declare a default value when declaring resource arguments to
a PDB procedure.
Add default behavior to GimpParamSpecResource.
Add field and override g_param_spec_value_set_default.
Fix the plugins that have resource arguments.
Some plugins temporarily use a hardcoded default instead of declared default.
ScriptFu plugins, TODO.
Misc fix to the test plugin for this case: test-dialog.py.
Dev>Demo>Test dialog...
TODO 10822 Lava plugin issue depends on this.
Note film.c fixed but still doesn't work.
As discussed in !1725, there is an init order issue, which is that you
cannot obtain any of these ID objects as long as the GimpProcedure is
not created. In particular, now that GimpResource arguments can have
defaults, we will want to query such resource in the create_procedure()
implementation of a plug-in (where the GimpProcedure is not running yet,
as we are defining it!).
Anyway I don't really see the point of these multiple-level hash tables
all storing a reference to the same object. Let's just store in the
GimpPlugIn's hash tables once and give the same reference to any
procedure (anyway we make it clear that these objects belong to libgimp
and must not be freed, so it's a bug all the same if someone frees
them). Then it also fixes the init order issue.
As far as I understand, the created types are never "unregistered" and
will live in the process until it ends. It cannot even have a custom
class_finalize() (looking at g_type_register_static()'s code, a CRITICAL
is emitted if you try to provide a class_finalize() implementation).
So let's just free the allocated pspecs at the end of class_init()
instead.
This is a regression brought with commits 9b5463b5c5 and f7aaba9fc9.
Technically the bug already existed, but it was brought to light after
the reordering of our param bit flags, because GEGL_PARAM_PAD_INPUT
(which is set on all op properties) and GIMP_PARAM_DONT_SERIALIZE are
now the same value. It used to be same as GIMP_CONFIG_PARAM_AGGREGATE,
which, by chance only, didn't have unfortunate consequence on
serialization, yet that was also a bug. The real fix is that we should
not propagate GEGL bit flags in our operation config types.
Resolves #11993
In !1319, we added the ability to merge down filters destructively
in the Filter Tool GUI. This accidentally allowed you to merge down
a filter on a layer group. This patch adds checks to prevent this
option from being used, in the same way we hide the option when
editing an existing layer effect.
We didn't have a "destructive-action" class anymore and the
"suggested-action" was hidden by further CSS rule, so it needed to be
moved down so that it gets precedence.
We used to have these as red and green buttons originally (e.g. pasting
as floating selection, the "New Layer" and "Anchor" were the suggested
actions, i.e. green, whereas "Delete Layer" was destructive, red). For
GIMP 3.0, we keep grayscale design. We'll see if this will change later,
but at least, now we have something again.
The colors are assumed to be sRGB since they come from a
pre-defined array and are used for the item color tags in the
GUI. This replaces the call to gimp_rgb_composite () with the
direct implementation of the GIMP_RGB_COMPOSITE_NORMAL
code.
It also ensures that only one call is made to gegl_color_set_rgba (),
rather than two if the color is inherited.
We weren't updating the precision of layer effect masks when
converting the layer's precision. This patch updated with the
format from gimp_image_get_mask_format ().
Note that in the future, this code should be moved to
gimp_drawable_real_convert_type () once that function is used
in all the child classes of GimpDrawable.
This patch removes the two instances of
gimp_rgb_luminance_uchar () and one
instance of gimp_rgb_luminance () from
the codebase.
* plug-ins/common/checkerboard.c:
Use gegl_color_get_pixel () to get the
luminance value at the same time we're
getting the RGBA value from the GeglColor.
* plug-ins/gradient-flare/gradient-flare.c:
Replace with GIMP_RGB_LUMINANCE ()
macro, which does not use GimpRGB.
gimp_file_save () is used to save both XCF
and export formats like PNG. XCF does
not have a GimpExportOption parameter,
but we were unconditionally copying it.
This patch adds a check for this.
Previously, the "menuitem menuitem" style was cascading down
to the top menubar's subitems. This patch explicitly defines the
CSS to match the 2.10 style and prevent cascading.
As noted by bootchk, docs of gtk_application_is_inhibited() says:
> Determines if any of the actions specified in flags are currently inhibited (possibly by another application).
The last part, between parentheses imply that it's possible for another
application to inhibit GIMP. So we should not rely on this function to
verify we inhibited the logout. Just check of we have an inhibition
cookie.
This handle is one of the opaque window handles as returned by
gimp_dialog_get_native_handle() or gimp_progress_get_window_handle() and
therefore it works even across processes. Now any export procedure using
the GimpExportProcedureDialog will call "plug-in-metadata-editor" as a
transient window of itself when clicking the "Metadata (edit)" button.
In particular, the Metadata editor won't be hidden by mistake when
appearing or similar issues.
Nevertheless it only works for systems where we have a transient window
implementation (so far, only X11 and Wayland, since the Windows
implementation is currently commented out because of #10229, and we have
no macOS implementation).
Note though that setting destroy-with-parent doesn't work, most likely
because the GimpExportProcedureDialog is still waiting for the Metadata
editor procedure to return (commit 54d01b5a0b), otherwise we end up with
a bad state in GIMP Protocol.
A proper solution to this will likely be to create a temp procedure from
metadata-editor to request it to close from another plug-in.
The purpose of this flag is to have some procedure arguments for which
you wish to ignore last values, or restored values. This may be needed
for arguments which are really volatile and likely won't survive a
session (or even from a run to another).
This will be used in my next commit.
Note: this is very close to GIMP_CONFIG_PARAM_IGNORE, except that this
latter is used for obsolete properties instead, so I felt that it may
not have been the best idea to mix these semantically different flag.
Also GIMP_CONFIG_PARAM_IGNORE properties are not serialized but they are
deserialized, which is not exactly what we want (in most case, it would
work the same, but it also means that if last-used values were to
contain some deprecated value for a property for which we added this
flag, there would be at least one run where a buggy behavior would
happen).
… more robust.
GIMP_PARAM_NO_VALIDATE and GIMP_CONFIG_PARAM_DONT_COMPARE were the same
value, most likely because when GIMP_CONFIG_PARAM_DONT_COMPARE got added
(commit c5c807d191), the comment to keep in sync
libgimpbase/gimpparamspecs.h and libgimpconfig/gimpconfig-params.h was
missed.
Instead, since libgimpconfig can include libgimpbase, do the other way
around: first non-GLib param flags are in libgimpbase, then we add a
GIMP_PARAM_FLAG_SHIFT, then we increment from it in libgimpconfig, and
finally we increment from GIMP_CONFIG_PARAM_FLAG_SHIFT if ever we add
more flags in app/ (right now GIMP_SYMMETRY_PARAM_GUI is apparently the
only one, but this may change).
Resolves #11980
In 443947c6, the now unnecessary g_free (drawables) was
removed from heif_av1_export (). However, it was accidentally
left in heif_export (). This patch removes it to prevent a crash
from double freeing the drawables list.
This should be enough to not "annoy" developers with repetitive ninja and
not too relevant appimagetool output. This makes easier to devs to look at
the runner log without needing to revert 9653e50e (the revert/split would
make us lose .appimage in some custom Deb pipelines and 50% of ccache hits).
Previously, we called gimp_display_shell_appearance_update ()
which updates the "Show" settings in the View menu *before*
we had updated the Display object in GimpContext.
This meant that the wrong settings were being applied when
switching images.
This patch moves the call after we run gimp_context_set_display ()
to make sure we've got the right active Display.
As I recall, this is something we in fact used to have in gimp-2-10
branch and which we lost when switching from appstream-util to
appstreamcli validation tool (the later is now recommended, but it's
also less featureful, they don't even have a relax test!). So that was a
regression in the build system.
Note that it's not just not to have to put a date too early in our
AppStream metadata, but it's also that this way, we won't forget to
update it upon release (hence shipping with a wrong release data in
metadata). Indeed, when building a non-release version, date="TODO" will
pass the test, yet moving on to a point release version, the validation
test will now fail on a TODO date.
The other way around, we were going to have the quick'n dirty exit for
the whole 3.0 stable branch, which is obviously not what we want. We
want the clean exit for all developer builds, even within a stable
branch.
I had just forgotten to add it, though fortunately (or not) it doesn't
break string freeze because the <release> description fields are not
localized right now.
Cf. discussions in #8628 and this infrastructure report:
https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/473
The color for the nib handle is pulled from
the widget's background-color style.
However, this was not defined - so it was
always (0, 0, 0).
This patch adds a GimpBlobEditor CSS
class and defines the background and
border color for it to resolve the issue.
The lua.interp file is there. Lua plug-ins are not needed at build time,
except that when I had a non-supported interpreter as my system's `lua`
binary (see #11876), so calling in-build GIMP would startup the lua goat
exercise, get the error reported in #11876, and (this part is the real
problem), it would somehow freeze the in-build-gimp.sh script. I'm not
sure how exactly, the gimp-console would in fact end correctly (and
generate the image it is supposed to), but leaving around a lua process.
And somehow the script would not continue, it would not call any further
command line, nor would it even crash. So I just had a stuck build.
In my OS, lua 5.1 binary is called 'lua-5.1' (with hyphen), so I add
this in the list. Also I improve the summary output to display the found
lua binary, which is useful for debugging and for packagers to know
which lua binary is being used (especially now that we install a
lua.interp, even on Linux).
GimpExportOptions is incomplete.
It exists so the API is stable.
For now, ScriptFu eat and ignore actual args,
binding to NULL, in calls to PDB procedures
file-export-foo having formal args of this type.
Unlikely that in the future ScriptFu will do anything else:
if a plugin needs export options, use another language.
The few file exporters used by existing ScriptFu scripts
(file-gbr-export and file-pat-export)
don't honor export options.
luajit download server to tarballs stopped to work, which is expected,
since it was advised by the team in https://luajit.org/download.html:
"Please do not use obsolete versions from older tarballs or zip files.
Please remove any outdated links to these downloads — these links will
cease to work soon."
We also will not use the official git server since it does not support
all git clone features, which makes flatpak-builder cloning stage fail.
---
Regarding lua-lgi, we will not use the latest commit since seems that
our goat exercises or gobject-introspection or lua-lgi iteself is broken
since lua-lgi commit: 3f47eb57ef5a84be878ce33c15b7ff037059b08d
Currently, the default maximum size of GIH cell-width and cell-height
is 1000. These values are increased to the current image size when
exporting via a GUI. However, it is not updated when overwritten or
exported without a GUI. If the cell-width or height was previously set
to a larger value than 1000, this throws a critical and resets the value to
1. This likely causes the "slow" exporting noted in #10816, since the cell
becomes 1x1 even for large images.
This patch sets the default value to GIMP_MAX_IMAGE_SIZE, so that
if run non-interactively, we don't run into issues with the image dimensions
going beyond the bounds of the parameter maximum.
It was made impossible to paste into a channel, as this was creating a
normal layer instead. We need to use floating selections when the pasted
target is a GimpChannel type.
Note that the UX is very ugly right now for these (except for the layer
mask case as I improved this a lot with commits 04810ec95e and
28457ce337), so I opened issue Teams/GIMP/Design/gimp-ux/89 to design
further evolutions.
This is a follow-up of commit c5db158f58, where the flickering issue was
happening when creating new windows when already in multi-window mode. I
had the same issue again when I had several tabs opened in SWM and
switched to MWM. Then it would undraw displays to move them to their own
window. In the short time when this occurs, we don't want to process
events. So now I changed the "drawn" status when undrawing ("unrealize"
event) a shell.
I also changed the implementation of gimp_displays_accept_focus_events().
What we need is to check the active shell only of each window. In SWM in
particular, it is normal that non-visible tab shells get unrealized.
First, make the script versioning system able to detect release candidates.
Otherwise, we willn't be able to use the "GIMP.GIMPPreview" identity (that
was previously tied to GIMP_UNSTABLE var, which is not set to 1 on RCs).
---
This also fixes the pseudo-revision trick when we have a zeroed micro version,
which is the case of the release candidates and the first stable version.
The versioning now have a different aproach from 8c99efd7.
I had added an assert in commit 98ebe96c1f specifically to catch other
cases where we may have run gimp_ui_manager_update() with inconsistent
user context, and I failed to catch the obvious CRITICAL (the damn Error
Console was catching it!).
Anyway we had this other obvious case when creating new displays in
gui_display_create() which would trigger the ui update with still
inconsistent context.
Now I'm in fact wondering why GimpContext is simply not returning the
active GimpDisplay's image and connecting to the "image" property of set
display so that it's always synchronized. But since we are so close to
GIMP 3, and I don't want to do too important restructuration of code
(why did we do this complicated update in 2 parts? Maybe there was a
good reason…) at this point, I'll just do the simple skip for now and
look more closely at GimpContext implementation after the release.
The previous PDB generation was losing pre-formatting inside
triple-backticked blocks. In particular we were losing indentation
(which was already ugly in C, but even syntactically wrong when
displaying Python code samples). And it was also making us add
double-newlines between every code lines, which was annoying.
This updated code now leaves triple-backticked sections as-is.
Unfortunately I was completely unable to do this by modifying the
existing functions, which were modifying the input arg in-place. So I
made them into functions returning the result. But then there is another
part of code (niceargs()) where changing array contents doesn't work
properly, and worse it seems to corrupt the array somehow (because I
have generation breakage in completely-different pieces of the PDB
generation code). I believe there is some passing-by reference/value
concepts in perl which I don't quite get (they use `&`, `\` and other
symbols and even searching for these, I don't quite understand how to
use them the right way) but I've spent already too much time on this. So
since I've got something working now by having duplicate functions, I'll
let someone else from the future, who knows better perl, re-merge these
functions if they know how.
The 'help' field needs to be single-quoted so that @-values do not look
like perl variables, hence breaking GIR annotations.
Fixing:
> Possible unintended interpolation of @Gimp in string at /home/jehan/dev/src/gimp/pdb/groups/item.pdb line 64.
I double-checked the gi-docgen docs and realized the "Note:" were all on
the same line as previous text. I had forgotten it just removed one
newline. So if I want a new paragraph (double-newline in markdown), I
need 3 newlines in the pdb file.
All the functions working with object's IDs are mostly internal. They
are still made public because they can be useful and are relevant in
specific use cases (i.e. using IDs to reference items in specific
widgets, such as drop-down lists, or when temporarily storing an item as
integer, etc.).
Yet it should be made clear that these usages are the exception rather
than the norm.
I had this one case at GIMP exit where destroying editor->selection
inside gimp_colormap_editor_set_context() was segfaulting, very likely
because the widget was already destroyed so the pointer was dangling.
Therefore set a weak pointer, and clear it in dispose, so that whatever
comes first at destruction time will reset the pointer to NULL.
This fixes a never-ending flickering blocking the GUI, until a manual
focus event (such as moving a window in front) breaks the infinite loop
of handling focus events.
Followup to 34af64b70f
The menu definition in image-menu.ui.in.in didn't have the same
capitalization as in the plug-ins that uses it, so it was never
used, and would never be shown translated.
Though the output of `lua -v` is on stdout and was also on stdout by
default, even back with version 5.1, it turns out that lua's print
function was considered configurable back then. And this is very likely
why we now have this report of someone whose lua is on stderr.
So let's still look on stdout, then fallback to stderr it the format
doesn't match.
As Cheesequake noted in !1673, there may be cases where one would want
to run gimp_help_connect() while also setting a tooltip. So they also
run gimp_help_set_help_data(), even though the latter is implied by the
former. Worse, it makes the order matter too much because if you call
gimp_help_connect() after gimp_help_set_help_data(), the tooltip would
be removed.
Now the reason is that gimp_help_connect() was clearly made to be run on
windows whereas gimp_help_set_help_data() was for other widgets, which
usually don't need to react to F1. Yet the previous commit does add
F1-connect for the lock buttons, which kind of makes sense. So why not
just add this tooltip argument.
As a side fix, I am removing a bunch of gimp_help_connect() on each
button in the layers effect popover. Just run it once on the top
container.
This patch adds gimp_help_connect () calls before
gImp_set_help_data () to set up F1 keybind to work
properly. It also adds lock_visibility_help_id to channel
view.
Resolves #11718
Thanks to Anders for noticing this one! Sorry to translators if you
already worked on this and wondered what this AA was (answer: nothing
but a typo!).
...when the height is larger than the width.
Due to a copy/paste error, the width was used
for both layer width and height. Since we only
had two sample files and both images were
wider than they were tall, this was not noticed.
Copying filters over from one image to a partial copy was broken on
multiple level by doing it on an additional loop, and assuming that the
originally selected layers and the newly created ones had the same
structure:
1. First the actually copied layers may be more numerous. For instance,
we'd also copy parent layers. Typically copying a layer under a layer
group, both the layer and its parent layer group would be in the clip
image.
2. Second, because this structure may change, the assumptions made so
that filters were not copied to the right image.
3. And as a last consequence, sometimes we could have crashes, assuming
the same structure and therefore directly dereferencing a NULL
pointer. I had such a crash when copy-pasting a layer group, while
also selecting its children layers (though this crash also got hidden
by my previous commit, but just by chance).
Instead just copy filters in the same time as layers are copied, so that
we can easily associate the filter from the correct original layer we
copied from.
Like ranks, the number of selection modes are defined by gihparams.dim.
However, we were unconditionally setting GimpProcedureConfig's
"selection-modes" parameter to the gihparams.selection array, which
might have more elements than we had dimensions. This caused a crash.
This patch moves the selection-modes code into the check for
gihparams.dim > 0, and copies only the relevant values into a separate
array to set them.
app/text/gimptextlayout.c gives warnings
on MSYS2 about xres and yres not being
initialized.
plug-ins/file-tiff/file-tiff-load.c gives
warnings about read_unit not being
initialized.
plug-ins/file-bmp/bmp.c has a typo on
the label of the rgbx-8888 option for
rgb-format.
This replaces most of the remaining
gimp_procedure_dialog_get_int_combo ()
parameters with defined GimpChoice
parameters.
The only exceptions are where we retrieve
the values from a library (such as file-aa)
or the integer value itself is intuitive
(such as bit-depth or rotation degree)
Some parts of the README got obscured or dated with time. Let's improve them:
- Remove redundant text about keeping GIMP buildable (it's already said on
Cod. Style and Dev rights pages on gimp-web-devel, and not flatpak specific)
- Remove text about 1-hour timeout which isn't true according to my tests,
specially after the improvements of splitted jobs and updated build options
- Reorder Anitya text to before "module dropping" text, it's linear this way
("module dropping" by checking runtime is last step of module cycle of life)
- Remove very confusing "flatpak run... gimp" line which was breaking the
explanation flow about "module dropping" and it's not too useful since the
manifest (which is only a bit different) can be acessed in-source with tags
- Changed title from "Mantaining the manifest" to "Mantaining the modules"
- Added not so clear "Versioning the flatpak" to separate it from other modules
text. The title is not perfect, but at least make a needed pause on reading
Ported from: 37b173e3a9
and ac0069eb20
The reason for this change is because part of our API (babl, gegl and
gimp headers) directly links to gexiv2 then exiv2 headers so these two
should be provided, even if they aren't on babl/gegl/gimp namespaces.
This change is useful to beta. But, despite we not using extensions on
GIMP nightly to need these headers, doesn't hurt syncing this change.
Indeed, this commit clarify "why" we aren't cleaning these headers.
This adds a bit more verbosity to the installer script while omitting some.
The version params (e.g. gimp_version) are dropped since now config.h is
mandatory (this is a natural conclusion of the generation of assets).
Main dev branch of GIMP always depends on the HEAD of babl and GEGL
anyway, but that's just so that we maybe have less people reporting GIMP
not building because they use a stable release version of GEGL (though
it won't take care of the case of people using an older 0.4.49 build
which also won't have the newer API).
In GTK2 and GIMP 2.10, you can use the mouse scroller to
switch between dockable tabs if you hover over the bar.
This behavior was removed from GtkNotebook in GTK3.
This patch follows other GTK3 applications in re-implementing
the behavior with a scroll-event callback.
I broke MR !1660 commits into 2 commits so that the strings are added
now (freeing this up for the upcoming string freeze), with this commit.
A next commit will be needed when we'll have the proper version update
infrastructure on GEGL side, because right now, all we can do when
filter versions don't match is ignoring the filter.
Otherwise, building the devel docs errors out like this:
```
FAILED: devel-docs/reference/gimp/libgimp-3.0
...
WARNING: Unknown namespace ExportReturn
[enum@ExportReturn.EXPORT].
^~~~~~~~~~~~~~~~~~~~~~~~~~
```
Signed-off-by: Nils Philippsen <nils@tiptoe.de>
There are needed at build time because we run various Python scripts
through GIMP, and we made the Python 3 plug-ins non-optional now.
Thanks to Bruno for noticing this needed to be updated in INSTALL.
- Fix annotations for gimp_export_options_get_image() to make it
actually introspectable with the GimpImage being both input and
output. Even though the logic doesn't change much (the input image may
be overriden or not), it doesn't matter for introspection because
images are handled centrally by libgimp and therefore must not be
freed. Actually deleting the image from the central list of images
though remains a manual action depending on code logic, not some
automatic action to be handled by binding engines.
- Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image()
because ignoring the returned value is rarely a good idea (as you
usually want to delete the image).
- Remove gimp_export_options_new(): we don't need this constructor
because at this point, the best is to tell plug-in developers to just
pass NULL everywhere. This leaves us free to create a more useful
default constructor if needed, in the future. Main description for
GimpExportOptions has also been updated to say this.
- Add a data_destroy callback for the user data passed in
gimp_export_procedure_set_capabilities().
- Fixing annotations of 'export_options' object from pdb/pdb.pl: input
args would actually be (nullable) and would not transfer ownership
(calling code must still free the object). Return value's ownership on
the other hand is fully transfered.
- Add C and Python unit testing for GimpExportOptions and
gimp_export_options_get_image() in particular.
- Fix or improve various details.
Note that I have also considered for a long time changing the signature
of gimp_export_options_get_image() to return a boolean indicating
whether `image` had been replaced (hence needed deletion) or not. This
also meant getting rid of the GimpExportReturn enum. Right now it would
work because there are no third case, but I was considering the future
possibility that for instance we got some impossible conversion for some
future capability. I'm not sure it would ever happen; and for sure, this
is not desirable because it implies an export failure a bit late in the
workflow. But just in case, let's keep the enum return value. It does
not even make the using code that much more complicated (well just a
value comparison instead of a simple boolean test).
This patch creates a GimpExportOptions class in both
libgimpbase and in libgimp. Currently it is a mostly empty
object, but it will be added to after 3.0 to allow for
additional export options (like resizing on export while
leaving the original image intact)
libgimp/gimpexport.c was removed, and most of its content
was copied into libgimp/gimpexportoptions.c. gimp_export_image ()
was replaced with gimp_export_options_get_image () in all
export plug-ins.
GimpExportProcedure has a new function to set the default
image capabilities for each plug-in on creation. It also sets up
a new callback function, which allows the options to respond to
user setting changes (such as toggling 'Save as Animation' in the
GIF or WEBP Plug-in).
This is a followup of previous commit. As well diagnosed by Anders, this
value relies on "gegl:gaussian-blur" operation's argument's range.
Also adding a comment to make it easier for future developers seeing
this value.
gimp-buffer-get-image-type returns the output of
gimp_babl_format_get_image_type (), which itself returns
a GimpImageType enum. However, the PDB claims that
it's a GimpImageBaseType enum instead. This patch fixes
the documentation to match the actual output enum type.
gimp_cairo_set_source_rgb () and
gimp_cairo_set_source_rgba () are no longer
used in the code base, so let's remove them
as part of the move to GeglColor.
Liam was hitting Backspace on "histogram" which is an action section and
would likely not return a proper GimpAction through
gimp_action_view_get_accel_action().
Therefore let's make sure we initialize properly the action to NULL.
The submenu labels for tool-options-popup were
hardcoded as English in GimpToolOptionsEditor's calls
to the Save, Restore, and Delete Tool Presets buttons.
This meant that these menus always fail when called in
non-English UIs, since we compare the path name and
submenu labels to only load the correct submenu items.
This patch attaches the English labels to the submenu
object so that we can retrieve it for comparison in
gimp_menu_model_get_submodel ().
This reverts commit f7e7f396aa.
See issue #8269.
For GIMP 2.10, I'll just revert this commit so that we get back to pre-2.10.32
situation. ~~For 3.0, we'll try to do something better.~~
-> Let's delay improving the situation even for GIMP 3.0, in which case
it's better to at least keep the same render as for the 2.10 series and
avoid confusion. I'll take more time after release to study better the
situation and see what we should actually do.
(cherry picked from commit 2fd738bb3e)
to stop for instance
When using the scale tool and the layer has a selection, then after
finishing the scaling we get a critical in the terminal like this:
(gimp-2.99.exe:31824): GLib-GObject-CRITICAL **: 18:22:05.689:
../glib-2.80.2/gobject/gsignal.c:1184: no emission of signal
"tool-changed" to stop for instance '000002e8a0f91df0'
This commit moves the call to `g_signal_stop_emission_by_name` inside
the if active_tool != tool_type.
gimp_item_mask_bounds() does not actually return if there is intersected
contents between the item and the image's selection, but whether there
is a selection. So when it returns FALSE, it will also return the full
item's dimensions.
'matrix' would save a lot of code and facilitate maintenance but,
according to my tests in a branch that I already deleted, this
doesn't work for our needs considering GitLab CI limitations.
This patch resizes the selection mode
icons based on the user's icon size
settings. It creates a new function in
gimpenumwidgets.c to update sizes,
then connects to GimpGuiConfig's icon
size update notifications in GimpSelectionOptions.
This is the only "language" from the list whose name is special and
should be localized at runtime, yet before we set any Preferences
language. It needs to be localized as the System Language itself which
will be run-dependant.
For instance, if your system is in French, it will be displayed as
"Langue système" but if you change your system to Korean, at next run,
it would show "시스템 언어". It is a per-run localization, independant
from the language selected in Preferences, and even less dependant from
build-time system language.
As reported by pippin, when gimp-data submodule is not initialized,
meson configuration fails with:
> meson.build:1830:0: ERROR: Nonexistent build file 'gimp-data/meson.build'
This does not give a lot of info, and while the solution can also be
found in INSTALL.in (INSTALL in tarballs) and on developer website, it's
nicer if the build itself could give a clearer information.
Now it will say instead:
> ERROR: Problem encountered: gimp-data submodule not present. Run: git submodule update --init
… found at build-time.
It was working on a machine with default paths and system-installed
packages (e.g. a typical Linux distributions) but needs to be manually
set up e.g. on Windows.
In particular, we don't want the build to succeed when various obvious
issues occur, which may even end up in a successful-looking build (yet
with no proper language lists), like we had in !1597.
Note that we still need the iso_639.mo files at runtime. Only the XML
files don't need to be parsed anymore at runtime (they are parsed at
build-time now).
Unlike the GimpTranslationStore which can use a list of pre-localized
languages (each language in its own name), the GimpLanguageStore must be
displayed in the currently used locale.
Our GimpTranslationStore contains self-localized names of all languages
we support.
As for GimpLanguageStore, it contains all known languages with their
name in the current locale. When moving to ISO 639-3 list, we had all
possible language, included ancient ones, extinct ones, and so on. With
the iso-codes installation on my machine, this meant a struct with 7910
languages! When showing the Text tool options for the first time, GIMP's
UI is frozen for a few seconds because of this, while it constructs the
GimpLanguageEntry making use of the GimpLanguageStore.
By only listing part 1 and part 2 languages (as well as the rare
languages which are not in these list yet which we still support, i.e.
right now only 'ckb' (Central Kurdish), see #11626), the list lowers to
189 languages, which is still good and are the main languages or
language families AFAIU. And now the Text tool options are constructed
instantly.
Note that this is in fact even less than when we were just using
iso_639.xml (I counted 487 languages stored there), but I believe it to
be enough for the usage we have in the Text tool.
Instead of always parsing the ISO-639 listing at each and every startup,
let's just generate the list of languages, their English name, and the
self-localized names as static struct.
This will just be much faster, and no worrying on the size of the XML
(or json) to parse.
We have translations for ckb (Central Kurdish), which is only
available in iso codes 639_3. For our language selection we only
parse 639(_2), which causes this language to show up as `??? (ckb)`.
This is of course not a good user experience since users need to know
that ckb is the abbreviation of their language.
We fix this by parsing `iso_639_3.xml` instead of `iso_639.xml`. This
works, but, since this file is a lot bigger, it takes a lot more time
(more than 1 second difference) to parse this.
Now, this is only done on startup, but this can certainly be a
noticeable delay.
A recent addition to load layers in Sketchbook TIFFs contained a typo in
code specific to big endian machines, making it fail to build there,
which wasn’t caught in CI.
In addition to this fix, use the appropriately named macro to convert
from little endian to big endian.
Signed-off-by: Nils Philippsen <nils@tiptoe.de>
… to keyboard input.
Removing a GtkBindingSet entry actually removes it from all GtkTreeView.
It's not limited to the ones contained in GimpContainerTreeView (which
makes sense, since it relies on the class) so it broke various
interactions across the software.
Let's just connect to signal key-press-event instead and block further
propagation. Not sure anyway why GTK has so many ways to handle key
interactions!
I'm also moving the implementation to GimpItemTreeView because this
enhanced keyboard handling is really about the items tree dockables
only, for the time being at least.
… icon name.
As akk was reporting on IRC, the huge question mark from the
dialog-question icon really makes it feel like it's an help button
(especially when used as an actual button, e.g. in GEGL filter generated
dialogs with aux inputs, when no viewable has been set as input yet).
Currently we can't serialize GimpDrawable, which is necessary for us
to store filters with Aux Nodes. Therefore, they will automatically be
applied destructively as a workaround until we can.
There was a weird instance of build failure in CI when compiling one of
the libgimpui files. It could not find one of the PDB-generated
function:
> ../libgimp/gimpaspectpreview.c:329:19: error: call to undeclared function 'gimp_image_get_selection'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
My assumption is that as a multi-threaded build, this file was compiled
just at the same time as the PDB was generating it, and therefore it was
empty, hence a very bad timing creating a build failure.
As I recall, I created the bogus stamp file stamp-pdbgen.h specifically
for such race condition issues (because meson has no generic dependency
rule, so we can't just ask one job to wait for another). We were using
this bogus object as source to libgimp, but not libgimpui.
Hopefully this will fix the problem and it won't re-happen randomly.
layers-select-next/layers-select-previous don't work well as up/down
arrow behavior because they only work within each selected layer's
level. But historically (and that's what makes the most sense IMO, and
is the most expected behavior), up/down arrows would walk through the
layer list visually. I.e. that it would select next whatever is the next
layer displayed in the Layers dockable, even if it means selecting
children or going down one layer group level.
The 2 new actions "layers-select-flattened-previous" and
"layers-select-flattened-next" do this. Say you have this tree:
Layer 1
Layer 2
| - Layer 3
| - Layer 4
Layer 5
With the "flattened" actions, after Layer 2, there is Layer 3, and after
Layer 4, there is Layer 5… unless… Layer 2 (layer group) is collapsed.
In which case, after Layer 2 is Layer 5. This selection movement indeed
takes into account the state of the layer group expanders.
This makes the Up/Down arrows work similarly to how they used to work
with default GtkTreeView implementation, except that the logic now also
works well with multiple selected items.
This reverts commit 31df873d4c.
My commit was not wrong per-se (it didn't add any bug), but it was in
fact not useful either, and only adding a useless list copy for no good
reason.
I thought that action_select_object() was actually selecting objects,
but looking at implementation, it in fact doesn't. It only returns a
pointer to the object to select.
This should likely eventually be re-specified in gimp-ux tracker,
especially as anyway we are planning on rewriting the GimpItemTreeView
from scratch.
But for now, this is better than the behavior where the arrow keys are
losing multi-item selections by default, and also the PageUp|Down
assigned actions are eaten away (as noted by Jacob in #11729).
Now we still don't go through to the PageUp|Down actions (in fact we do,
if we consider the default ones, but it's hardcoded, because after
careful consideration, I do indeed think that when such a tree view has
focus, the arrow and PageUp|Down buttons would have special meaning
anyway), even though I had a first version of this patch which did this.
We simply have much nicer hardcoded behavior!
Somehow it works fine on my machine, but this is very likely the
culprit. gimp_image_get_selected_layers() returning directly the pointer
to selected layers, we should always make a copy before doing anything
which would change this selection!
Resolves #11897.
The crop tool currently doesn't constrain
to the top-left of the layer when the
"Allow growing" option is turned off and
"Selected layers only" is turned on.
Instead, it always constrains to 0, 0.
When we converted to multi-layer select,
we added a loop to check the boundaries
of all selected layers. In this loop, we use
separate variables to get the offset and
then get the min of it and the current
min_x and min_y. However, those values
are initialized to 0, so they will always be
smaller if the layer is inside the canvas.
To fix this, before the loop we check if
there are any selected layers. If so, we
get the offset of the first layer and set
min_x and min_y to that value rather than
0, 0.
...bump map settings.
Currently, the Lighting Effect's bump map options uses
the RGB values of transparent pixels as part of its map.
As the Bump map filter does not do this, this patch tries
to make it consistent by using associated alpha for the
bump map Babl format to fix this.
Resolves #11892.
The new_unit_dialog () now initializes the default GimpUnit
to NULL instead of GIMP_UNIT_PIXEL. So we need to update the
check to prevent it from running when the user cancels the dialogue.
First of all: sorry to all translators who started working on these new
strings!
We use CamelCase for our titles, and in particular "Plug-In" is
capitalized with 'I'.
Furthermore, let's use understandable titles like "Plug-In Example in C"
and not just "In C", because while the short title works OK in the menu,
it makes for very broken action names in non-contextual parts of the
software, such as the action search.
Note that we in fact have a concept of short label for actions since
commit 89772351c9. I added support for it to GEGL actions (cf. commit
6dc5f6792e), and to a few core actions (e.g. commit ea1205f094).
Unfortunately I don't think I added an API yet for short label in
plug-ins. Maybe I'll add it soon. But for now, if we have to have a
single label, it should be long, so that it works in every situation.
P.S.: not sure if it's useful to keep documentation strings just
repeating the title, but for now, let's leave them.
Resolves #11890.
The Selection Editor's "vectors" group was not renamed
to "paths" during the GimpPath API update. This caused it
to be registered to a non-existent group, thus crashing.
Since it will be distributed in a release.
Only translate the menu item and help.
Not translate dialog labels, they will only be read by plugin authors.
The old menu label was confusing to users.
Remove translatable strings having joke "goat" so translators not confused.
Move the goat plugins to the menu.
The items under the menu should all be example plugins.
The menu is in a release.
Test plugins should not be in this menu.
Test plugins should not ship in a stable release.
!!! Note that 2.10 does not ship with example plugins.
If we don't want 3.0 to ship stable build with example plugins,
then the meson.build for goat-exercises needs to change
and the menu removed entirely in menus/image-menu.ui.in.in.
Adds a checkbox in the Filter tool so that
users can choose to apply a filter
destructively or non-destructively.
Currently only layers can have NDE effects
so it's not shown for masks and other
drawables.
Additionally, filters are moved to the top
or the bottom of the filter stack depending on
the setting (as destructive filters are applied
directly to the layer while NDE filters are
put on the top by default).
This fixes 2 issues:
1. Since gimp_edit_cut() uses gimp_edit_copy(), it had the same error
message when no selected drawables were within the selection.
2. When there was a previously existing clipboard image, gimp_edit_cut()
could return it as though the cut succeded, even when it did not.
While other parts of the commits were fine, this specific change was
clearly me going too fast. This is the format for a printf() call.
Fixes:
> app/widgets/gimpimagepropview.c:461:50: warning: format ‘%a’ expects argument of type ‘double’, but argument 4 has type ‘const gchar *’ {aka ‘const char *’} [-Wformat=]
I had the case on my machine where `lua` was version 5.4.4 and the
lua-lgi test succeeded fine, but then the demo plug-in would fail to run
with the error message from #11876.
Let's parse the output of `lua -v` to detect the version ourselves and
therefore be able to output proper error messages for packagers not to
assume that the Lua interpreter they are using will work fine.
Ported from: 3772514155
Just to note, ALL the previous "Sync with..." commits were tested in flathub
and gnome-nightly flatpaks, and this actual one (and future ones will be) too.
As discussed in #11876, the interp files work fine on Linux (and other
platforms) too, and this allows to properly redirect to the working
interpreter found at configure time, without touching the scripts'
shebang.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/11876
For 3.0 we will support only Lua 5.1, since we need to figure out how
much of the Lua 5.1 API is compatible with newer versions (Lua minor
versions aren't like Python minor versions, there is API breakage so
plug-ins would be completely unreliable, this commit prevent this).
Also, change some files to not force luajit since it isn't mandatory.
As in f9df9805, adds SVG versions of GFig
custom icons and conditionally uses them if
have_vector_icons is enabled. If not, we
fall back to the original PNG icons.
Also resolves #10012 by adding white
outlines around the thin dark lines to
make them more visible in dark mode.
This is the pendant commit to the one I'm going to commit on the beta
branch for RC1. There in fact was a way to always use the
$XDG_CONFIG_HOME folder, unconditionally (and prevent the weird
inconsistencies of having config folder in .var for some flatpak
installations and in XDG folder for others).
See: https://github.com/flathub/org.gimp.GIMP/pull/287
Apparentely `makeappx` tool deletes empty folders and MSIX runs with
system paths read-only. So calling g_file_make_directory_with_parents()
is just not enough.
Therefore when opening font folders recursively for font parsing, let's
just ignore the specific error of non-existing folders.
This patch adds support for loading Sketchbook
TIFF layers.
Alias/Autodesk Sketchbook used metadata tags
to store information about layers. This is a
separate implementation compared to Adobe,
stored in TIFFTAG_ALIAS_LAYER_METADATA.
The first directory contains the image metadata
and the layers are stored in SubIFDs, using the
same metadata tag for layer-specific properties
such as opacity and visibility.
This is a followup of commit f2d47ee53a.
I realized that the window's size was too big for the case when there is
an image as well because the scale factor of 1.0 was hardcoded. We now
use the scale factor from the display the shell is displayed on.
Unlike the other bindings (Lua, JS, Vala) where we only have a demo
plug-in, we actually have a bunch of interesting and useful Python
plug-ins.
Furthermore, we are running several Python scripts through GIMP during
our build (to generate a few images), so pygobject becomes a build
dependency anyway, even if it may not be a run dependency with
-Dpython=disabled.
This all becomes a bit confusing and in fact handling this case (of not
installing Python plug-ins) seems like an annoyance while we lose good
core plug-ins. So let's just make Python plug-ins mandatory. It's not
like Python is very controversial these days, and AFAWK, it is available
on every platform out there.
I was testing with a 2560×1440 display, yet with ×2 scale factor, which
is kinda equivalent with 1280×720 for scaled dimensions code.
And so anyway the default size request for an empty canvas was far too
big (bigger than the work area in fact).
I'm now using small default. As for the 3:1 ratio comment, not sure
about it, since shell_width is in fact changed to -1, so it feels very
specific to someone's setup. But anyway… I left the comment.
As Lloyd Konneker noted, the calc.sflare_list was not being
accessed at the right location when the Edit Dialog preview of
the gradient was updated. The API page for g_list_free_full ()
recommends using g_steal_pointer () to ensure the head element
is not left dangling. This aligns with other usage in the GIMP codebase
and seems to stop the crash. Additional safety checks were
also added.
The GIMP_VIEW_SIZE_ENORMOUS enum setting was missing from
the Preview Size menu. This patch adds it in so that users have a
preview size option between Extra Large and Enormous.
In earlier development, we accidentally
allowed users to save gegl:nop filters.
Since they are valid operations, they were
not triggering our unsupported operations
delete code. This patch adds a second
check to see if the operation is a nop, and
deletes it as well.
This patch also adds a check to make sure
a filter is in the filter stack before reordering
it. This was revealed by the nop bug, so
it makes sense to patch both at once.
Improve the previous commit with a bit more subtlety:
* Try to get the proper monitor (if the the widget's window is already
realized).
* While we try not to display too small an image (quarter of work area),
we also try not to display it too big (third of the work area).
* After the image has been loaded and displayed, the dialog will likely
reallocate to its finale size. When this happens, we should check if
it's not higher than work area. Only then should we try to make the
first page scrollable. Not only this, but we also queue the window for
resize (otherwise it's too late, the window is already too big).
This later point avoid having ugly scrollbars when unneeded (i.e. when
the dialog is perfectly fitting within the work area).
This patch makes the first page of the
Welcome Dialog scrollable vertically.
This should help reduce the screen height
for users with smaller screen sizes.
Rather than trying to implement full i18n plural support, we just remove
this failed attempt from the past. The fact is that to get proper
support, we'd basically need to reimplement a Gettext-like plural
definition syntax within our API, then ask people to write down this
plural definition for their language, then to write every plural form…
all this for custom units which only them will ever see!
Moreover code investigation shows that the singular form was simply
never used, and the plural form was always used (whatever the actual
unit value displayed).
As for the "identifier", this was a text which was never shown anywhere
(except in the unit editor) and for all built-in units, as well as
default unitrc units, it was equivalent to the English plural value.
So we now just have a unique name which is the "long label" to be used
everywhere in the GUI, and abbreviation will be basically the "short
label". That's it. No useless (or worse, not actually usable because it
was not generic internationalization) values anymore!
This makes the bundling script an "extension" of the building script, similar
to what Cmake-based projects does on Windows. By the way, this is inline with
the recent changes which clarified that bundling is just a finalization of the
building process when a bundle is aimed. See: d09a2a6f, 2dc6f411 and 9d86492b
I encountered this one when closing GIMP. Issue #9591 seems to be the
same crash, though when just closing the Colors dockable. I fail to
reproduce willingly now, though it looks like the problem could happen
in some cases when the stored GimpContext is freed before
GimpColorHistory is freed.
Let's increment the reference to make sure the referenced object stays
alive as long the history is alive.
Commit 81a68ae758 added usage of hb_blob_create_from_file_or_fail().
Since Debian bookworm has harfbuzz 6.0.0, this is not a big deal, but
the minimum requirement should still be bumped in our build scripts.
Normally we should avoid touching the Gettext files, but changing a
message context massively broke many strings in all languages. So I am
just reassigning the correct context (not touching any translations), by
running:
> sed 's/msgctxt "vectors-action"/msgctxt "paths-action"/g' -i po/*
Though these are not as user-facing as other strings, the action names
still are somewhat user-facing. Let's rename them consistently with the
GUI and the API.
This commit also handles user config migration so that custom shortcuts
are not lost.
Inspired by Mark Sweeney's work.
This patch allows the icons in the tree
view in Preferences Dialog to scale based
on user icon scale preferences.
Rather than add a GimpGuiConfig to
GimpPrefsBox, we make a call to style_updated ()
from the Preferences Dialog to signal a
change.
Alias fonts don't have a generated name, their alias name is used
instead. But the serialization code assumed that all fonts had a
generated name of the format "gimpfont%d" and this was causing a crash.
check for font validity (whether it is usable by pango), using
harfbuzz instead of relying on file extentions.
We do this in the first place because pango when given a font it can't
support will look for the closest matching supported font, but we
iterate through all fonts, so that would create redundancy.
Compare the font file gotten from the PangoFont object
related to the PangoFontDescription rather than just comparing
font names. This Helps because when pango is given an unsupported
font (Type1 or Bitmap fonts) it choses the closest matching ttf/otf
font, but reports the name of the unsupported font.
Per Jehan, we should remove gimppickbutton-default.[ch] and
move the functions into gimppickbutton.c. Then we can
make the GimpPickButtonPrivate API actually private without
any additional public functions.
This widget is used primarily in plug-ins like GFig and IFS Compose
which have toolbar buttons. This patch explicitly defines the style to
prevent system theme leaks and too dark colors on Middle Gray theme.
The "selected-layers-changed" signal was emitted while there were still
selected channels (which is an inconsistent state). And since
gimp_image_get_selected_drawables() returns selected channels first when
the image has any, vectors_actions_update() was using the previously
selected channel's lock information for deciding which actions to set
sensitive.
Temporarily reverting as the private struct
is shared between various OS versions of
the object and needs to be accessible.
A different approach will be needed to resolve,
and until then, I'd like the Debian pipeline to
work properly.
Move all public attributes of GimpThumbnail
from the header to a private struct in
GimpThumbnail.c. Also replace direct
access of these attributes in app/core and
app/widget with get/set calls.
Legacy plug-ins like Checkerboard (legacy) under Render Patterns lost
their Help button, although using F1 was still working.
Due to changes in how procedures are called, `gimp_dialog_constructed`
was called before the help-id was set.
The simplest way to fix this, is to call
`G_OBJECT_CLASS (parent_class)->constructed (object);`
at a later time in `gimp_procedure_dialog_constructed` after we have
set the help-id there.
Fixes:
> libgimpbase/gimpchoice.c:366: Warning: Gimp: gimp_choice_set_sensitive: invalid return annotation
Introspection step is now fully without any warning! \o/
I thought that such annotations would work and be useful to tell GIR that
a type is nothing more than a NULL-terminated array of a specific type.
But apparently GIR doesn't like these annotations and complain. So let's
just clean these out.
Fixes:
> ./../../../../../../dev/src/gimp/libgimpbase/gimpparamspecs.h:254: Warning: Gimp: unexpected annotation: array
> ../../../../../../../dev/src/gimp/libgimpbase/gimpparamspecs.h:254: Warning: Gimp: unexpected annotation: element-type
Right now, it only tests a few API, such as creating an image, then a
text layer, then inserting it in the image.
This is a test to avoid regression bug after having fixed #9923 in a
previous commit.
Without this, build-time GIMP cannot find the etc/ files unless GIMP is
installed. This becomes even more annoying now as I want to run tests
(for GimpUnit) depending on etc/unitrc contents.
This will also ensure that tests run properly in environments where the
etc/unitrc may have been modified.
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!
Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.
As an aside, this also fixes #10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.
Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.
Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
Adds SVG versions of ImageMap custom
icons and conditionally uses them if
have_vector_icons is enabled. If not, we
fall back to the original PNG icons.
Since ImageMap mixes custom and
stock icons, this keeps the icon size
consistent across the UI.
Per Denis Rangelov, tooltips for the
coordinates and area displays as well
as the shortcut menu were added.
Also, removes a reference to IMAP_ARROW
which no longer applies since that icon
was removed in favor of using the stock
cursor icon.
Despite the good intentions, 4f965557 makes Debian contributors who
follows gimp-web-devel instructions to download more deps than needed
and makes unclear what are the crossroad deps. Let's fix it.
This makes crossroad and msys2 scripts clone without the "_" prefix, which
will improve quality of life of most contributors that just clone them.
Just for consistency, also remove the "_" prefix from other pices of code.
The original script required a specific WinSDK version. Now, it autodetects.
This is useful if we need to move to another runner and welcome locally too.
Also, downloading the arm64 artifact was mandatory to get a x64 msix, which
is silly. Now, packagers are free to package to either arm64 or x64 alone.
This is useful locally but could be useful on CI too when some arch fail(?).
Resolves #11313.
We reference JPEG and TIFF images when
we send them from their loading plug-ins
to the PSD plug-in for PSD formatted
metadata. We should remove this extra
reference when returning the image back
to its original loading plug-in.
Inspired by Mark Sweeney's work.
This patch allows the active image, brush,
pattern, and gradient areas in the toolbox
to scale based on user icon scale
preferences.
Note that if the pattern itself is smaller
than the icon size, it currently won't scale
larger. This is a separate issue in the
renderer.
web-page.c was left as additional font
sizes besides the GUI choices could be set
via a PDB call. The export plug-ins int
combos will be updated in a separate
merge request.
Additionally, the region choice in screenshot.c
was hidden on Windows since it does not
yet implement that option.
This patch converts the image map
plug-in to use a floating point ratio rather
than an integer zoom factor. This allows
us to zoom out past the 1:1 ratio.
Additionally, it fixes the statusbar display
so that it shows 2:1 for zoomed in rather
than 1:2.
It's perfectly reasonable that someone can misunderstand the scripts info in
gimp-web-devel and try to run them not from git root but from their dirs. So,
let's add that possibility as a fallback (a pretty natural one by the way).
Also, change the error message to direct contributors to gimp-web-devel.
Inspired by Mark Sweeney's work.
This patch allows the four buttons on the
sides of the canvas (Zoom, Quick Mask,
Image Menu, and Navigation Image)
to resize based on the user's icon size
preferences.
layer_mask points to the original mask created by xcf_load_layer_mask. We copy
this pointer into channel, and xcf_load_channel_props can overwrite this
pointer and free the original mask. If this happens, layer_mask points to
the now-freed original mask, and should not be used.
Therefore we need to change later parts of xcf_load_layer_mask to use channel
instead of layer_mask. Additionally, we add a block and move layer_mask into
this block to guarantee that layer_mask cannot be used after it has
potentially been freed.
Adjustments by Jacob Boerema:
Follow GIMP's code style regarding variables, comment style and
position of braces
See also ASAN output below:
==5247==ERROR: AddressSanitizer: heap-use-after-free on address 0x615000010fd0 at pc 0x7f4e2dbbf31b bp 0x7ffca8a95cd0 sp 0x7ffca8a95cc8
READ of size 8 at 0x615000010fd0 thread T0
#0 0x7f4e2dbbf31a in g_type_check_instance_cast /home/ahunt/git/glib/_build/../gobject/gtype.c:4117:26
#1 0xb200fe in xcf_load_layer_mask /home/ahunt/git/gimp/app/xcf/xcf-load.c:2305:52
#2 0xb18eea in xcf_load_layer /home/ahunt/git/gimp/app/xcf/xcf-load.c:2133:20
#3 0xb13d91 in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:499:15
#4 0xb11deb in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#5 0x619dfd in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:50:17
#6 0x51d364 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#7 0x506fe2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#8 0x50d350 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9
#9 0x5373a2 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#10 0x7f4e2c84c349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#11 0x4e0779 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
0x615000010fd0 is located 336 bytes inside of 504-byte region [0x615000010e80,0x615000011078)
freed by thread T0 here:
#0 0x5e8562 in free /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:127:3
#1 0x7f4e2d76ce08 in g_free /home/ahunt/git/glib/_build/../glib/gmem.c:199:3
#2 0x7f4e2d797a6b in g_slice_free1 /home/ahunt/git/glib/_build/../glib/gslice.c:1183:7
#3 0x7f4e2dbb7b04 in g_type_free_instance /home/ahunt/git/glib/_build/../gobject/gtype.c:2008:5
#4 0x7f4e2db8fe3a in g_object_unref /home/ahunt/git/glib/_build/../gobject/gobject.c:3604:11
#5 0xb22fff in xcf_load_channel_props /home/ahunt/git/gimp/app/xcf/xcf-load.c:1738:13
#6 0xb20037 in xcf_load_layer_mask /home/ahunt/git/gimp/app/xcf/xcf-load.c:2292:9
#7 0xb18eea in xcf_load_layer /home/ahunt/git/gimp/app/xcf/xcf-load.c:2133:20
#8 0xb13d91 in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:499:15
#9 0xb11deb in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#10 0x619dfd in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:50:17
#11 0x51d364 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#12 0x506fe2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#13 0x50d350 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9
#14 0x5373a2 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#15 0x7f4e2c84c349 in __libc_start_main (/lib64/libc.so.6+0x24349)
previously allocated by thread T0 here:
#0 0x5e87cd in malloc /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
#1 0x7f4e2d76ccf2 in g_malloc /home/ahunt/git/glib/_build/../glib/gmem.c:106:13
#2 0x7f4e2d7972e0 in g_slice_alloc /home/ahunt/git/glib/_build/../glib/gslice.c:1072:11
#3 0x7f4e2d7978ae in g_slice_alloc0 /home/ahunt/git/glib/_build/../glib/gslice.c:1098:18
#4 0x7f4e2dbb6e0a in g_type_create_instance /home/ahunt/git/glib/_build/../gobject/gtype.c:1911:17
#5 0x7f4e2db9215e in g_object_new_internal /home/ahunt/git/glib/_build/../gobject/gobject.c:1945:24
#6 0x7f4e2db91d1f in g_object_new_valist /home/ahunt/git/glib/_build/../gobject/gobject.c:2288:16
#7 0x7f4e2db90e8b in g_object_new /home/ahunt/git/glib/_build/../gobject/gobject.c:1788:12
#8 0xdb69e0 in gimp_item_new /home/ahunt/git/gimp/app/core/gimpitem.c:723:10
#9 0xce11c8 in gimp_drawable_new /home/ahunt/git/gimp/app/core/gimpdrawable.c:1067:14
#10 0xddf5d8 in gimp_layer_mask_new /home/ahunt/git/gimp/app/core/gimplayermask.c:254:5
#11 0xb1ffc5 in xcf_load_layer_mask /home/ahunt/git/gimp/app/xcf/xcf-load.c:2279:31
#12 0xb18eea in xcf_load_layer /home/ahunt/git/gimp/app/xcf/xcf-load.c:2133:20
#13 0xb13d91 in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:499:15
#14 0xb11deb in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#15 0x619dfd in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:50:17
#16 0x51d364 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#17 0x506fe2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#18 0x50d350 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9
#19 0x5373a2 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#20 0x7f4e2c84c349 in __libc_start_main (/lib64/libc.so.6+0x24349)
SUMMARY: AddressSanitizer: heap-use-after-free /home/ahunt/git/glib/_build/../gobject/gtype.c:4117:26 in g_type_check_instance_cast
Shadow bytes around the buggy address:
0x0c2a7fffa1a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa1b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa1c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2a7fffa1d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa1e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c2a7fffa1f0: fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd
0x0c2a7fffa200: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
0x0c2a7fffa210: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2a7fffa220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2a7fffa230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2a7fffa240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==5247==ABORTING
./crash-0507799c3e4291570e060f53332b58b8a96f95e5
Currently if your image history includes an
image with a long name, the Welcome
Dialog will stretch out to match its width.
If the color profile name is long, then the
color scales will also stretch out due to
the profile label.
This patch adds ellipses to the Welcome
Dialog and a scrollwindow to the
ColorScales to prevent this.
Ported from ca5688bf6d
Just to note, we are already not using Assembly code
in 10bit and 12bit libraries. So, no feature dropped.
---
Also, little fixes to some dev docs regarding Clang.
Unlike GIMP, Photoshop does not support indexed images with
multiple layers. We have been silently merging layers down when
exporting to PSD, but this may be confusing to users.
This patch adds a label that notifies the user if they export an
indexed image with more than one layer.
...based on icon size preferences.
Inspired by Mark Sweeney's work.
Since the icon size is based on a formula,
the CSS value determines the maximum
size rather than being used directly.
Needs backport to 2.10
gimp_dock_windows_constructed creates a GimpDockColumns, a child widget,
and keeps a private reference to it at dock_window->p->dock_columns.
Then it connects the signal dock_columns.doc_removed to two callbacks:
gimp_dock_window_dock_removed() and gimp_dock_window_update_title().
gimp_dock_window_dock_removed() callback is called first and can
destroy the GimpDockWindow widget and its child widget GimpDockColumns.
Then gimp_dock_window_update_title is called
and tries to call dock_window->p->dock_columns.get_docks()
but it is already destroyed.
The fix is to nullify the internal pointer to dock_columns when destroyed,
and encapsulate access to dock_columns.get_docks so that it
returns a valid but empty list when dock_columns has already been destroyed.
Alternatively, you might be able to fix it by rearranging the order
of connections to dock-removed signal, but then the title would be wrong.
Another alternative might be to rethink the whole destruction sequence.
The ARTIFACTS_SUFFIX is being dropped on building scripts because:
1) This will make possible to further simplify Installer scripts in other commit
2) There is no script that uses multi-arch _build/_install at same time on CI
However, there are two use cases: to build Debian and flatpak; and, on Win,
to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche.
I suppose that people who build on Debian (or other dev-oriented distro)
willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime)
+ two gimp prefixes (out of sandbox and sandbox) due to huge storage use.
Why someone would want to build with emulation on Win ARM64 I don't know.
Anyway, people that know how to do this stuff probably can change the .sh.
3) When building locally, the contributor doesn't need to know the arch at all.
Indeed, without this suffix, the scripts are inline with gimp-web-devel and
prevent some first-sight confusion when reading them that I've seen on IRC.
4) These arch suffixes can be understood as '_install-*' being distributable
which is not true. So, without this suffix we could make more clear
what is a package (when GitLab fix the glob bug in 'expose_as' someday).
---
Despite .gitlab-ci.yml not being a script, it needed to be touched too
because cross scripts depends on Debian jobs due to gimp-data MR.
If a given layer's properties contain multiple PROP_ACTIVE_LAYER entries, we
could add multiple entries for the same layer in info->selected_layers.
However, xcf_load_layer_props and xcf_load_layer both contain logic that
overwrites the layer pointer - they do take care of updating
info->selected_layers and and info->floating_sel (both of which could contain
or point to the current layer). Crucially, they both assume that
info->selected_layers can only contain this layer once - hence they only
remove it from the list once. This logic also frees the old layer because it
thinks that it's no longer in use.
But if we've added the original layer to selected_layers multiple times,
and then use the logic that overwrites layer, selected_layers will still
contain an invalid pointer to the now-freed original layer. Any later
code that tries to read info->selected_layers will hit a user-after-free.
Therefore we need to check if the current layer is already in the
selected_layers list, and avoid adding it again if it's already there.
(It also seems illogical to say that a layer is selected twice, but I'm
focusing on the code-correctness aspect in my analysis.)
Adjustment by Jacob Boerema: the correct way to test that a value does
not exist in a list is to check for the value being negative. Also add
a message to warn users.
ASAN output:
==21241==ERROR: AddressSanitizer: heap-use-after-free on address 0x615000012150 at pc 0x000000d54dbf bp 0x7ffcf813bb60 sp 0x7ffcf813bb58
READ of size 8 at 0x615000012150 thread T0
#0 0xd54dbe in gimp_image_set_selected_layers /home/ahunt/git/gimp/app/core/gimpimage.c:4743:7
#1 0xb146c6 in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:690:7
#2 0xb1199b in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#3 0x619cad in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:35:17
#4 0x51d2e4 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#5 0x506f62 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#6 0x50d2d0 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9
#7 0x537322 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#8 0x7f064a594349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#9 0x4e06f9 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
0x615000012150 is located 336 bytes inside of 504-byte region [0x615000012000,0x6150000121f8)
freed by thread T0 here:
#0 0x5e84e2 in free /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:127:3
#1 0x7f064b3f81c8 in g_free (/usr/lib64/libglib-2.0.so.0+0x581c8)
#2 0x7f064b41133f in g_slice_free1 (/usr/lib64/libglib-2.0.so.0+0x7133f)
#3 0x7f064b7015c0 in g_type_free_instance /usr/src/debug/glib2-2.62.6-lp152.2.3.1.x86_64/build/../gobject/gtype.c:1946
#4 0xb187d8 in xcf_load_layer /home/ahunt/git/gimp/app/xcf/xcf-load.c:2146:3
#5 0xb13997 in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:504:15
#6 0xb1199b in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#7 0x619cad in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:35:17
#8 0x51d2e4 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#9 0x506f62 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#10 0x50d2d0 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9
#11 0x537322 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#12 0x7f064a594349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#13 0x4e06f9 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
previously allocated by thread T0 here:
#0 0x5e874d in malloc /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
#1 0x7f064b3f80c8 in g_malloc (/usr/lib64/libglib-2.0.so.0+0x580c8)
#2 0x7f064b410da5 in g_slice_alloc (/usr/lib64/libglib-2.0.so.0+0x70da5)
#3 0x7f064b411258 in g_slice_alloc0 (/usr/lib64/libglib-2.0.so.0+0x71258)
#4 0x7f064b7011d5 in g_type_create_instance /usr/src/debug/glib2-2.62.6-lp152.2.3.1.x86_64/build/../gobject/gtype.c:1849
#5 0x7f064b6e164f in g_object_new_internal /usr/src/debug/glib2-2.62.6-lp152.2.3.1.x86_64/build/../gobject/gobject.c:1827
#6 0x7f064b6e354d in g_object_new_valist /usr/src/debug/glib2-2.62.6-lp152.2.3.1.x86_64/build/../gobject/gobject.c:2152
#7 0x7f064b6e38c8 in g_object_new /usr/src/debug/glib2-2.62.6-lp152.2.3.1.x86_64/build/../gobject/gobject.c:1670
#8 0xdb5b90 in gimp_item_new /home/ahunt/git/gimp/app/core/gimpitem.c:723:10
#9 0xce0358 in gimp_drawable_new /home/ahunt/git/gimp/app/core/gimpdrawable.c:1067:14
#10 0xddd8db in gimp_layer_new /home/ahunt/git/gimp/app/core/gimplayer-new.c:65:11
#11 0xb182a6 in xcf_load_layer /home/ahunt/git/gimp/app/xcf/xcf-load.c:2027:11
#12 0xb13997 in xcf_load_image /home/ahunt/git/gimp/app/xcf/xcf-load.c:504:15
#13 0xb1199b in xcf_load_stream /home/ahunt/git/gimp/app/xcf/xcf.c:305:19
#14 0x619cad in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/app/fuzzers/xcf_fuzzer.c:35:17
#15 0x51d2e4 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#16 0x506f62 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#17 0x50d2d0 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9
#18 0x537322 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#19 0x7f064a594349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#20 0x4e06f9 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
SUMMARY: AddressSanitizer: heap-use-after-free /home/ahunt/git/gimp/app/core/gimpimage.c:4743:7 in gimp_image_set_selected_layers
Shadow bytes around the buggy address:
0x0c2a7fffa3d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa3e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa3f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2a7fffa400: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa410: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c2a7fffa420: fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd
0x0c2a7fffa430: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
0x0c2a7fffa440: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2a7fffa450: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa460: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2a7fffa470: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==21241==ABORTING
( crash-f37f84bd7072e65348ca0e2c920d1e08165356fd )
Inspired by Mark Sweeney's work.
GimpToolPresetEditor has an icon next to its title which does
not react to icon size changes.
GimpToolPresetEditor's parent_instance, GimpEditor, already
has a "button-icon-size" CSS style which can be accessed in
its children. This patch adds signals to listen for icon size
changes and update the icon size accordingly.
Resolves #9105
The XCF compression setting is initially
set to FALSE. It was only updated from the
Save Dialog, so if the user exports then
compression is reset if they save the XCF
again.
This patch adds a condition on export
where we get the image's compression
setting, instead of always defaulting to
FALSE. This allows you to save and export
the same image without having to
re-enable the compression setting each
time.
A follow-up to the previous commits, that address the tga issues from
issue #11822.
On Windows, when using the error console for messages, a huge amount
of error messages, that can be generated with special fuzzed images,
like crash-f65fd5404bff32c1d9d10ee049d9c98d02bbbdc2.tga from
the above mentioned issue, can cause GIMP to crash.
Although this is most likely caused in the error console or its
dependencies, we should not let it cause problems here until that is
fixed. There is also no real need to generate a huge amount of similar
repeated error messages, so let's limit it to 10 per read line of input.
We are trying to copy all bytes in the current row, which is the width times
the number of bytes per pixel (stored in info->bytes), not width times bits
per pixel.
Copying too much data allows certain inputs to induce a heap-buffer-buffer
overflow read, and probably also a write, see ASAN output below:
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61d000008088 at pc 0x00000052be17 bp 0x7ffd8bbe8e20 sp 0x7ffd8bbe85e8
READ of size 16448 at 0x61d000008088 thread T0
#0 0x52be16 in __asan_memcpy /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3
#1 0x5641ca in read_line /home/ahunt/git/gimp/plug-ins/common/file-tga.c:982:7
#2 0x560218 in ReadImage /home/ahunt/git/gimp/plug-ins/common/file-tga.c:1147:15
#3 0x55f526 in load_image /home/ahunt/git/gimp/plug-ins/common/file-tga.c:646:11
#4 0x56519b in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/plug-ins/common/file-tga_fuzzer.c:69:17
#5 0x461624 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#6 0x460b2a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:505:3
#7 0x462ec4 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:814:7
#8 0x4630d9 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:845:3
#9 0x451686 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:906:6
#10 0x47b662 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#11 0x7fdbd277c349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#12 0x424a39 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
0x61d000008088 is located 0 bytes to the right of 2056-byte region [0x61d000007880,0x61d000008088)
allocated by thread T0 here:
#0 0x52ca8d in malloc /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
#1 0x7fdbd37fccf2 in g_malloc /home/ahunt/git/glib/_build/../glib/gmem.c:106:13
#2 0x56009b in ReadImage /home/ahunt/git/gimp/plug-ins/common/file-tga.c:1134:10
#3 0x55f526 in load_image /home/ahunt/git/gimp/plug-ins/common/file-tga.c:646:11
#4 0x56519b in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/plug-ins/common/file-tga_fuzzer.c:69:17
#5 0x461624 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#6 0x460b2a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:505:3
#7 0x462ec4 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:814:7
#8 0x4630d9 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:845:3
#9 0x451686 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:906:6
#10 0x47b662 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#11 0x7fdbd277c349 in __libc_start_main (/lib64/libc.so.6+0x24349)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 in __asan_memcpy
Shadow bytes around the buggy address:
0x0c3a7fff8fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c3a7fff8fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c3a7fff8fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c3a7fff8ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c3a7fff9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c3a7fff9010: 00[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3a7fff9020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3a7fff9030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3a7fff9040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3a7fff9050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3a7fff9060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==26560==ABORTING
crash-4b13aca1db7bb795a815431b86cc20284f3aa6da
A malformed colourmapped tga file could specify color IDs that are not
contained in the colourmap. Therefore we add some bounds checking to
ensure that we only use entries that actually exist.
We could completely give up on such files, but it's just as easy to fall
back to the first colour in the map in this case. However we can only
fall back to the first colour in the map IF the colourmap contains
at least one entry. Therefore we add an up-front check to verify that
colourmapped images actually do contain at least one entry.
Without this bounds-checking, it's possible to induce a heap-buffer-overflow
read in apply-colormap(), see ASAN output below:
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61900002257c at pc 0x000000564f99 bp 0x7ffe65fdb040 sp 0x7ffe65fdb038
READ of size 1 at 0x61900002257c thread T0
#0 0x564f98 in apply_colormap /home/ahunt/git/gimp/plug-ins/common/file-tga.c:901:23
#1 0x56411a in read_line /home/ahunt/git/gimp/plug-ins/common/file-tga.c:975:7
#2 0x560648 in ReadImage /home/ahunt/git/gimp/plug-ins/common/file-tga.c:1202:15
#3 0x55f4ee in load_image /home/ahunt/git/gimp/plug-ins/common/file-tga.c:647:11
#4 0x5653ab in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/plug-ins/common/file-tga_fuzzer.c:69:17
#5 0x461624 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#6 0x460b2a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:505:3
#7 0x462847 in fuzzer::Fuzzer::MutateAndTestOne() /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:745:19
#8 0x4633d5 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:883:5
#9 0x451686 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:906:6
#10 0x47b662 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#11 0x7fe76a5dc349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#12 0x424a39 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
0x61900002257c is located 0 bytes to the right of 1020-byte region [0x619000022180,0x61900002257c)
allocated by thread T0 here:
#0 0x52ca8d in malloc /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
#1 0x7fe76b65ccf2 in g_malloc /home/ahunt/git/glib/_build/../glib/gmem.c:106:13
#2 0x55fdc6 in ReadImage /home/ahunt/git/gimp/plug-ins/common/file-tga.c:1049:26
#3 0x55f4ee in load_image /home/ahunt/git/gimp/plug-ins/common/file-tga.c:647:11
#4 0x5653ab in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/plug-ins/common/file-tga_fuzzer.c:69:17
#5 0x461624 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#6 0x460b2a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:505:3
#7 0x462847 in fuzzer::Fuzzer::MutateAndTestOne() /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:745:19
#8 0x4633d5 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:883:5
#9 0x451686 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:906:6
#10 0x47b662 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#11 0x7fe76a5dc349 in __libc_start_main (/lib64/libc.so.6+0x24349)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ahunt/git/gimp/plug-ins/common/file-tga.c:901:23 in apply_colormap
Shadow bytes around the buggy address:
0x0c327fffc450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fffc460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fffc470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fffc480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fffc490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c327fffc4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[04]
0x0c327fffc4b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fffc4c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fffc4d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fffc4e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fffc4f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==16309==ABORTING
( crash-f70628d4df7a65babc8e57d890425771a1d67e06 )
If the colourmap contains more than 256 items AND has alpha, it should always
be promoted to RGBA. Therefore we move the "if (info->alphaBits)" check into
the first if clause, to avoid accidentally demoting to RGB in this scenario.
Other parts of the tga parser assume that the destination array is RGBA
when alphaBits is not zero. For example, upsample() will always write 4 bytes
per pixel when alpha is set - (even if we only allocated 3 because we thought
we should use RGB). Erronously allocating only 3 bytes makes it easy to induce
a heap-buffer-overflow write, see ASAN output below. (apply_colormap makes the
same assumption and would probably do the same thing, but upsample is the
first location that we'd hit this issue.)
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61700002ae00 at pc 0x000000563d97 bp 0x7ffde8677890 sp 0x7ffde8677888
WRITE of size 1 at 0x61700002ae00 thread T0
#0 0x563d96 in upsample /home/ahunt/git/gimp/plug-ins/common/file-tga.c:830:15
#1 0x560b59 in ReadImage /home/ahunt/git/gimp/plug-ins/common/file-tga.c
#2 0x55f4ee in load_image /home/ahunt/git/gimp/plug-ins/common/file-tga.c:647:11
#3 0x5652ab in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/plug-ins/common/file-tga_fuzzer.c:69:17
#4 0x461624 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#5 0x460b2a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:505:3
#6 0x462847 in fuzzer::Fuzzer::MutateAndTestOne() /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:745:19
#7 0x4633d5 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:883:5
#8 0x451686 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:906:6
#9 0x47b662 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#10 0x7fd894a94349 in __libc_start_main (/lib64/libc.so.6+0x24349)
#11 0x424a39 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
0x61700002ae00 is located 0 bytes to the right of 768-byte region [0x61700002ab00,0x61700002ae00)
allocated by thread T0 here:
#0 0x52ca8d in malloc /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
#1 0x7fd895b14cf2 in g_malloc /home/ahunt/git/glib/_build/../glib/gmem.c:106:13
#2 0x55fce9 in ReadImage /home/ahunt/git/gimp/plug-ins/common/file-tga.c:1039:26
#3 0x55f4ee in load_image /home/ahunt/git/gimp/plug-ins/common/file-tga.c:647:11
#4 0x5652ab in LLVMFuzzerTestOneInput /home/ahunt/git/gimp/plug-ins/common/file-tga_fuzzer.c:69:17
#5 0x461624 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15
#6 0x460b2a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:505:3
#7 0x462847 in fuzzer::Fuzzer::MutateAndTestOne() /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:745:19
#8 0x4633d5 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:883:5
#9 0x451686 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:906:6
#10 0x47b662 in main /home/abuild/rpmbuild/BUILD/llvm-12.0.0.src/build/../projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#11 0x7fd894a94349 in __libc_start_main (/lib64/libc.so.6+0x24349)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ahunt/git/gimp/plug-ins/common/file-tga.c:830:15 in upsample
Shadow bytes around the buggy address:
0x0c2e7fffd570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2e7fffd580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2e7fffd590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2e7fffd5a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2e7fffd5b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c2e7fffd5c0:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2e7fffd5d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2e7fffd5e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2e7fffd5f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2e7fffd600: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2e7fffd610: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==12179==ABORTING
( crash-f65fd5404bff32c1d9d10ee049d9c98d02bbbdc2 )
We allow passing NULL gvalue for an empty GimpObjectArray, for convenience.
For example to plugin sel2path which doesn't use drawables.
But crossing the wire, create an empty GimpObjectArray
having an arbitrary type for elements.
Note that the widgets are still made
with GTK directly. The primary goal of this
initial port is to remove the last usage of
gimp_export_dialog_new (). Future work
will be needed as currently we can not
automatically generate widgets from
array parameters.
The visibility lock icon and help ID was accidentally
left off the PathsTreeView set-up.
The Path Attributes also used the wrong icon to indicate
the paths were locked (compared to the one shown in the
Path Attributes dialogue).
Revise the tests that can't default the args.
Actual args default to the min value formal declared in the PDB.
The declared min value must correspond with declaration in GEGL.
As of fcdddad2, the requirement for layers
to be attached before NDE filters can be
applied has been removed on app/core.
This patch removes the restriction from
the PDB call for filters as well.
* file-sunras, sparkle, and fractal-explorer
were converted to use GimpChoice with
the RadioFrame setting
* Unnecessary store variables were
removed from hot and file-psp
The description promises that we return
NULL if the image is not in indexed mode,
but we didn't actually verify that it was
before continuing with the colormap
code. This patch adds that verification step.
...in non-interactive cases.
gimp_export_image () handles various
tasks like rasterizing NDE filters. It only
runs in interactive cases however, so if the
users calls gimp-file-save the filters are
not exported.
Since Jehan removed the hidden dialogue
in 0dc9ff7c, we can now safely call
gimp_export_image () in all cases to make
image export more consistent. This step is
also preparation for setting up the new
API with GimpExportOptions.
GimpPlugin improperly destroys proxies after each run of a temporary procedure.
A temporary procedure may pass reference to proxy to main procedure.
Proxies should live as long as the main procedure of a plugin,
or for an extension plugin, until only the extension main procedure
is on the procedure stack. More discussion in the issue.
Extract method gimp_plug_in_proc_run.
Call it from two new methods: main_proc_run and temp_proc_run,
which do more e.g. cleanup.
Extract methods for cleanup, main_proc_cleanup and temp_proc_cleanup
Add method is_proc_stack_empty
...from GimpChoice.
0b2d8fed let us display GimpChoice
options as IntRadioFrames. Therefore, we
can convert a number of plug-in parameters
that were being built manually to use
GimpChoice instead. This decreases the
amount of GUI code and makes the
non-interactive inputs more descriptive.
Some languages like Chinese use separate
words for Levels when referring to a color
scale versus a unit of measure. Currently
we group all of them together.
This patch distinguishes between Levels
as Color Scales versus "measurements" for
translation purposes.
vector(s) => path(s)
layer-group => group-layer
Add a few tests.
(script-fu-use-v3) in more tests, code becomes more terse.
Added some aliases in script-fu-compat.c for renamed procedures, for compatibility third party.
Though I am not fond of these macros for our core code (it makes the
code more cumbersome especially for using private data in derivable
types), this definitely makes sense for public API, since it would allow
easier modifications with less chances of messing API/ABI stability.
...to path.
Changes the names of
gimp_vectors_* () API to
gimp_path[s]_* (). Renames related files
to [path] instead of [vectors], along with
relevant enums and functions.
This commit renames the GimpVectors
object to GimpPath in both app/core and
in libgimp. It also renames the files
to gimppath.[ch] and updates the relevant
build and translation files.
There are still outstanding gimp_vectors_* ()
functions on the app side that need to be renamed
in a subsequent commit.
...to paths.
Similar to d0bdbdfd, but covering the
app/core versions of the API instead of
libgimp. Changes the names of
gimp_image_*_vectors () API to
gimp_image_*_path[s] ().
Also renames some related functions such
as gimp_image_pick_path (). The next step
will be to rename the gimp_vectors_* () to
gimp_path_* ().
Inspired by Mark Sweeney's work.
GimpDockbook's dockable tabs update whenever the icon size is
changed. However, the Configure this tab button icon does not,
so it always remains at 12px. This patch adds code to resize it to 75%
of the current tab icon's size, which mirrors the default relationship
of 12px to 16px. This allows the icon to grow when the icon size is
set to Large or Huge.
The numbering is now inline with actual the order of jobs on CI
to make easier to understand what the numbers represent.
To understand why bundling is number 2 see: d09a2a6f and 2dc6f411
The storing of Windows scripts was changed to make easier to
call them, to better convey that they work outside CI and
to be consistent with other build/ subdirectories.
Refactor: extract method gimp_widget_free_native_handle.
This reduces duplication of code and encapsulates Wayland specific code.
Call the new function in more places.
This is expected to fix #11613 but it is hard to be sure
since the exact sequence of events in 11613 was never determined
and only reproduceable in some flatpak builds.
Calling the new function in more places also should eliminate leaks.
But I did not test there was a leak prior to this fix.
In GimpColorSelector setter, don't change the model if perceptually same.
More than just don't emit changed, don't change the model value.
Also, fix leak by freeing old color.
...to paths
Follow-up to d0bdbdfd. Changes all
gimp_vectors_* () PDB to gimp_path_* ()
and renames relevant PDB files from
vectors to path.
The next step will be to rename
GimpVectors in libgimp to GimpPath,
removing the last (public) trace of it.
...to paths
The first step in converting GimpVectors
to GimpPath. The PDB API for any
gimp_image_*_vectors () is now
gimp_image_*_paths ().
This commit only covers libgimp, and
the app/core versions will be renamed in
a following commit.
- Dependencies not present in GNOME runtime are now built in deps stage
This makes easier to follow the progress of the overall pipeline and
to know how much time was spent on each stage
(like crossbuilds, the artifact size is brutal but only lasts 2 hours)
- babl and GEGL build now have output in GitLab runner, unlike others deps
This makes clearer to spot if something goes wrong in these crucial deps
- GIMP is still built in its stage but now alone, like Debian and Windows
This makes possible to retrigger only this job when runner errors occours,
without needing to start monolithically the deps+gimp build from scratch
Also:
- babl, GEGL and GIMP now have meson-log.txt artifact like other builds
- dist job now have all commands self-contained on its script (needs to
be merged to be tested according to my tests)
Functions creating a new GeglBuffer should trigger a warning if the
result if unused, because this is potentially a big memory leak.
Similarly objects created by functions creating new layers should be
handled (usually by adding the layer to the image with
gimp_image_insert_layer()), because they also come with a buffer and
possibly quite some important memory leak.
If the type is not registered, g_type_from_name() is not able to find
the GType from the type name.
Fixes:
> gimp_gp_param_to_value: type name GimpGroupLayer is not registered
Also add a bit more type handling code.
Resolves #11772
While ba79fd00 fixed the number of
arguments in the resource arguments,
setting them to False prevented the GUI
from opening if the gradient wasn't set.
This patch switches the value to True to
fix the problem.
Resolves #10855
Replaces the uchar arguments in
plug_in_exchange () with floats to better
match gegl:color-exchange's arguments.
Since this was the last plug-in that used
uchar, we also remove the datatype from
PDB.
Also:
- renaming gimp_layer_group_new() to gimp_group_layer_new() in order to keep the
same name as in core code (i.e. GimpGroupLayer, not GimpLayerGroup).
- renaming gimp_image_merge_layer_group() to gimp_group_layer_merge()
- new functions: gimp_procedure_add_group_layer_argument(),
gimp_procedure_add_group_layer_aux_argument() and
gimp_procedure_add_group_layer_return_value().
This can be tested, e.g. in Python with these calls:
```py
i = Gimp.get_images()[0]
g = Gimp.GroupLayer.new(i, "hello")
i.insert_layer(g, None, 1)
g2 = Gimp.GroupLayer.new(i, "world")
i.insert_layer(g2, g, 1)
g.merge()
```
This was work started long ago, stored in an old stash which I finally
finish now! :-)
See: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1670#note_2152565
This makes the NIGHTLY flatpak use the local GIMP source. This reduces the
internet usage and makes possible to generate .flatpak from every branch out
there, which turns the flatpak finally really useful to code development.
Of course, this makes impossible to run 'flatpak-builder NIGHTLY_manifest.json'
without cloning or downloading GIMP code, but this is not a regression since:
1) the NIGHTLY manifest is in-source to begin with, so same thing as our other
building methods (except macOS), which runs over the code they are stored
2) the chances of someone downloading partial source code (the NIGHTLY manifest
alone) so being unable to build are low since this file isn't too easy to find
3) even if someone do this and don't like, we are not violating flatpak building
pratices since this option exists to be used (and will be in NIGHTLY only)
In most bindings, they would just result in the same signature as the
_get_ variants (which people have been used to, since the GIMP 2
series). Also I was told that apparently in some bindings where this
would make a different signature, the (skip) annotation could be ignored
anyway.
The original reason to skip these was because the new _list_ API were
introspected basically to a similar function signature, except with a
useless return value, at least in pygobject binding where the list size
was also returned.
Though it seems that in fact, only the docstring was wrong. The real
signature was apparently already the same.
See: https://gitlab.gnome.org/GNOME/pygobject/-/issues/352
Therefore since the _get_ naming is more consistent compared to other
existing function, let's re-integrate the _get_ functions for array of
items or images.
This basically reverts commit 15ec254148.
Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value().
We now have specific public functions for every supported type and it's
in fact much better to use them. The generic functions gave the feeling
that we could use any GParamSpec as procedure argument, whereas we in
fact depend on what the PDB support, and only these subtypes.
Despite we not building gimp nightly on aarch64 we need to sync with beta.
So, this updates to LLVM/Clang 18, which fixes 'gexiv2' and 'poppler'
problems with deps on that arch. 'json-c' and 'luajit' were adjusted too
with the use of proper build options to fix errors.
These were created because of some limitation/bug in pygobject, which is
now much better worked around by having specific functions for every
argument type supported by the PDB.
...when dockable is closed.
Resolves #11748
gimp_color_editor_display_changed () was still connected to
the user context when the Color dockable was closed. This
resulted in either a critical or crash if a new Color dockable
was opened or if the GIMP was closed. This patch should
cause the signal to be disconnected automatically when
the editor is destroyed.
Inspired by Mark Sweeney's work.
GimpColorNotebook has existing code to
update the color selector tab icon sizes
via CSS. However, it was not set up to be
notified of icon size changes from the GUI.
Since GimpColorNotebook is in libgimpwidgets,
we call its style_updated () function from
the style_updated () functions of the two
widgets its created in - GimpColorEditor
and GimpColorDialog.
It seems unnecessary – at least on my system, files with underscores in
their names are shown with two underscores in the recent files list.
This patch fixes that.
The Preference settings for themes and icon themes
are not directly connected to the property due to
the possibility of custom themes. Instead, we create
GtkListBoxes and load all the theme values. As a result,
when the preferences are reset, the row selection is not
updated.
This patch adds signals to the config object that update
the listbox selections when the Reset button is clicked.
The handler IDs are stored in the dialogue so that we
can remove them when the dialogue is closed.
Resolves #11742
gimp_procedure_dialog_get_file_chooser () does not
work with GtkFileChooserAction.SAVE enums yet.
This was incorrectly left in by f5b7f734.
This patch removes the command to fix a crash.
As decided in #10922, 32-bit will be tolerated in 3.0 series because of TWAIN.
So, let's package only the bare minimum files to the 32-bit TWAIN plug-in work.
This reduces the final installation size by approximately 215MB.
It's a common pratice to tell the user what version is being installed
even if this is somewhat obvious (the user opened the installer, he
should know it). Many installers do this and Win MSIX installer too.
However, there is no sign in our Installer about what version is
being installed (the reused splash/intro image doesn't count because
it isn't always different at each micro or revision, and text is small).
---
To accomplish that feature, the Inno langs needed to be patched since
Inno actually forbidden to use that feature when we have a Welcome page.
https://groups.google.com/g/innosetup/c/w0sebw5YAeg
But 'UninstallAppFullTitle' from the following langs couldn't be patched:
- Japanese
- Lativian
I only updated the mask strings to plural in core-enums.c, overlooking
that it is generated from core-enums.h.
So, update the same strings there after "desc".
commands that work on multiple layers:
Raise Layer -> Raise Layers
Layer to Top -> Layers to Top
Lower Layer -> Lower Layers
Layer to Bottom -> Layers to Bottom
Also update the hint strings.
There are two approaches regarding the icon for Windows installers .exe:
1) same icon as the app: this give more identity, but creates confusion if
you saved the installer in the same dir of the installed app shortcut.
This approach is also confusing in the task bar (e.g.: running GIMP
stable while installing GIMP unstable);
2) generic icon (e.g. a box, a cd) provided by the tool: more generic if
you downloaded two installers generated by the same tool (ours is Inno)
I choose a middle ground and created a icon with: the app icon and an
"installer" symbol (a package box), which conveys the best of two words.
This also fixes the Inno inborn bug of the unninstaller with install icon.
Resolves #11018.
Currently, babl formats are saved as strings when
passed as params. However, indexed palettes do not
use a "standard" encoding string but are created from
palettes (with a custom format). This results in an
error when we attempt to recreate the babl format from
the custom string encoding, as it doesn't exist at that
point.
This patch mitigates the problem by converting the indexed
color to RGB/A 8-bit when used in params. In the future when
indexed mode supports different color spaces and higher
precision, we will need to remove the hard coding. For now,
it solves the immediate problem.
After running almost all the py plug-ins, I noticed that few py modules and
pkgs are used to justify the need of a slightly faster build time with .pyc.
In the actual bloated status (with all .pyc), lib/python* is about 260 MB big.
With the bare minimum .pyc after the tests above, python*/ is less than 90.
So, let's purge the .pyc at bundling time (I'm not reinventing the wheel,
Krita do this too), which reduces the .zip bundles (so the Inno and MSIX
installs) in 170MB, the Installer .exe in 45MB and MSIX download in 60MB.
---
Let's also disable any .pyc generation, since GIMP installed with Inno in the
system-wide (aka admin) mode or installed with MSIX both doesn't handle well:
py plug-ins work but have CLI errors, unlike Inno user-mode and .zip bundle.
Actually, the Language dialog is always displayed, which is not too good since:
1) This is inconsistent: the install mode dialog (to choose user or system)
appears before using the system lang automatically. Even if Inno fix this:
2) This is tiring: depending on the context, the user can see up to 5 dialogs:
SmartScreen (1) > Install mode (2) > installer lang (3) > dev warning (4)
> SetupMutex (5): https://groups.google.com/g/innosetup/c/bkRtnHz2ygg
3) This is redundant: even if only 2 and 3 are displayed, why 2? Inno will
auto select the sys lang, which the user understand to search GIMP for PC;
4) This is confusing: even the lang dialog message being clear, some users
genuinely conclude that the selection will carry over to GIMP install like
the old Adobe CS installer (#5515). !1628 makes more clear that not, but
reducing confusion even more is a welcome plus considering points above.
So, let's use 'ShowLanguageDialog=auto'. That option ensures that the dialog
will NOT appear if the sys lang have a translation present in the installer,
which matches what every program does and even installers like Inkscape one.
If the lang isn't included in the installer, the dialog WILL appear so the
user can choose one which he is more fluent, being is a nice middle ground.
In the main menu and layers dialog context menu it is called
`Text to Path`, let's use that same name in the text tool actions
instead of `Path from Text`.
This solves an old bug that makes Inno report GIMP as being almost 1.8GB,
which is not true (it's 1.3GB at most). That was probably caused by the
overuse of components intersections (e.g.: gs + gimp, py + deps), which
Inno does not handle well (sometimes it not even displayed the cmp size).
TWAIN component is still reporting a wrong size since it's a totally
different beast, it will be fixed later.
Not all layer mask menu commands and help texts were updated to reflect
that they work on multiple masks.
Updates
- Apply Layer Mask -> Apply Layer Masks
- Delete Layer Mask -> Delete Layer Masks
- Their text hints and the one for Disable Layer Masks
Updates the undo strings, even though these don't seem to be used
anymore? Looks like undo always picks the menu command now.
It had actually been made unnecessary by 1c81c426.
This will allow for the full removal of GimpCMYK from
the codebase as part of the color space invasion.
Adds code to copy any NDE filters when
importing an .xcf file as layers in an
existing project.
This also requires removing the check
for the layer being attached to an image,
which historically made sense because
filter effects were immediately merged
down. Now that filters can exist separately
the check is no longer required.
GimpSourceTools like Clone and Heal use GimpPaintTool's
code for determining if they can work on a pixel-locked
layer. This means that they can not set a locked layer as a
source even though that would not affect the locked layer's
pixels.
This patch adds an additional condition to GimpPaintTool, to
allow operations if the tool is a GimpSourceTool AND only
Ctrl is held down. This allows the layer to be set as a source
while preventing it from being drawn on.
Note that this isn't enough for F1 to work, but that is a separate
issue.
I think that for now one help-id for all the layer effects is enough,
until we get a more final UI.
lua-lgi now works with Lua 5.3 on Windows:
https://github.com/msys2/MINGW-packages/issues/21171
According to my tests, after installing lua53-lgi MSYS2 package,
lua5.3.exe tries to run the goat exercise (fails since the goat
uses different lua API). Anyway, lua5.1 isn't required per se.
Following c6634d66 and 09d6402a
These files are too small and aren't reused so no point keeping them modular.
Also, with them inside .iss we reduce the clutter in the installer/ folder.
Despite that folder mysteriously not being mandatory on Linux
(the contents are different), on Windows (in PCs without MSYS2)
this is required by a warning. So, partially reverts c808d13b
The gimp.org main page was being used as the updates URL but the
downloads page is more direct, avoiding confusion with news or with
the stable big red button (remember: we also have dev installers).
The OpenEXR plugin was specifically set
to throw an exception if a chroma image
(Y/BY/RY) image was loaded.
This patch removes the exception and loads
the luminance channel only as a grayscale image,
which is how Krita currently handles it.
Future work is needed to properly convert the
chroma channels to import as a RGB(A) image.
Temporarily drops 'cfitsio' which started weeks ago to change its hash.
In my tests, after "fixing" the hash, sometimes it alternates to another,
which breaks the build again. This is too hard to maintain and unsafe(?).
Resolves #11702
In 2.10, the x/y label background on the Curves tool used
GtkStateType enums to get the widget's background color.
These enums were depreciated in GTK3, and during the
port the gdk_cairo_set_source_rgba() command was left
out. This resulted in the current line color being used instead,
making it hard to read the label in some instances.
This patch restores the Cairo color update command, using
the gridline color as an equivalent to the background color
from 2.10.
Resolves #7588
After the port to GTK3, the Filter dialogue's width started
to be affected the length of the image name. If the name
was very long, the filter dialogue would expand to fit it.
This patch encloses the image title label in a GtkScrolledWindow
with polices of EXTERNAL width and NEVER height. This ensures
there will not be a scrollbar, and the label will not influence the
width of the dialogue. A tooltip was added in case the user wants
to hover to see the full name.
Following e93e0f49
This defaults 'Segoe UI' for Installer texts and for license's body. This
font is still used as the default in Windows 11 and even in online docs.
We are also bumping to 9 pt as outlined in the final Win32 guidelines:
https://learn.microsoft.com/en-us/windows/win32/uxguide/vis-fonts
I've done microscopic pixel checks and confirmed that this produces a Win32
compliant design, which renders kerning and spacing equal as 'Win + R' and
UWP Notepad (please note that some "legacier" Win32 apps renders different)
---
Also, change from Lucida Console to 'Consolas' (default console font since
at least Win8). Today it is Cascadia Mono but not included with Win 10.
Resolves #11690
While exporting, the image is duplicated, in turn,
filters are also duplicated. This patch fixes the
duplication by also copying the parent
GimpFilter's properties.
Restores the build log artifact which was lost partly due to my fault.
The log is very useful in the rare cases of breaking the build system.
So, following our experience, let's save it for, at minimum:
- Native Linux
- Native Linux flatpak: will be adressed later in another commit
- Cross Win
- Native Win (aarch64)
If we were in the first days of our CI (so script bugs are common),
the scripts "debug mode" (bash -x) would be crucial, but we are not.
To be fair, running scripts in "debug mode" is pretty harmful today:
1) the produced logs consume our quota more and more (e.x.: adding a
bit more complicated .sh function can double the output size); and
2) the long white logs tends to be specially hard to read by the way.
This makes the output more complete but at the same time less
polluted regarding the bundling scripts (base, deps and sym).
---
Also, packaging scripts (inno and msix) were touched as consequence
of experiments about drop bundling, for saving space (~20MB), of:
- etc/gtk (MSYS2 don't build immodules)
- share/ghostscript (macOS .dmg don't package it)
- share/libthai (macOS .dmg don't package it)
- share/locale (???, decided to kept only gtk and iso-codes to test)
- share/man (installer don't package it, maybe because Windows can't open)
- share/poppler (macOS .dmg don't package it)
- bin/bzip2.exe (???)
- bin/gdk-pixbuf-query-loaders.exe (loaders.cache already bundled)
- bin/gspawn*.exe. (???)
- share/gir-1.0 (installer don't package it)
- share/lua (???)
- share/vala (installer don't package it)
The "???" ones seems to not be used according to my local tests. If
they are, a bug will appear so we will be able to know, comment in
the script (for maximum clarity towards the future) then revert.
With the new API introduced int d1c4457f,
we next need to port all plug-ins using
the argument macros to functions.
This will allow us to remove the macros
as part of the 3.0 API clean-up.
In the process, make the Installer localization process less 'masochist'
(in other words: less manual). The custom '.xml' was the only way since
the iso-codes, Dammed Lies and Inno namings don't match.
Resolves #11687
Previously gimp_drawable_has_filters () was used to check
if a drawable had filters before deleting them. However,
this function actually only checks if there's an active filter -
if filters are attached but set to invisible, this returns false.
This mean that you could not delete filters if they were
invisible.
This patch switches to using gimp_container_have () instead
as it checks if the filter is in the drawable's filter stack.
* colorxhtml.py was converted to use
GimpProcedureDialog. A new aux
argument was added so that a widget
could be created in the GUI. The text
field and the file widgets were made
to be sensitive to the source-file bool to
better indicate to the user which one will
be used.
* palette-sort.py now uses babl instead of
colormath libraries to get CIE LAB and
CIE LCH(ab) values. This means all users
will be able to sort by those options even
if the colormath library isn't installed.
* histogram-export.py's out-format
widget was converted to a radio frame
as it is in 2.10.
Currently when you open the Procedure Browser, part of the
description text is off-screen.
This patch changes the values for the GtkPaned panels so that
the description is completely visible horizontally. It also makes
the vertical scrollbar conditional on the widget height rather
than always showing.
Resolves #11679
The loading code for ASE, ACB, and ACO palettes
set any errors with g_prefix_error (). However, the
error object is NULL at that point for those palettes.
Therefore, a NULL error object is returned to
palette_import_make_palette () which then tries to
access its attributes. This resulted in a crash.
This patch fixes the issue by using g_set_error () for
those three formats instead.
This patch ports the first-party Python plug-ins
to use the new argument API.
This restores the ability to add dropdown menus from
enums and Gimp.Choice parameters, and also allows
defaults to be set for custom datatypes like Gegl.Color.
In order for Python plug-ins to be able
to create custom parameters like
GeglColor and GimpChoice, we need to
create actual functions rather than
using macros. A subsequent commit
will update all plug-ins to use them.
Ports the animation code started in e13cc635
to an independent gimp_widget_animation_enabled()
function. This allows plug-in authors to
also conditionally turn off animations if
the user's system settings say to do so.
The function is applied to the About
Dialogue animation as well as two Easter
Egg animations:
* Wilber's eyes blinking after 23 minutes
on an empty canvas
* Wilber's eyes following the mouse after
a certain sequence of tools is clicked
Resolves #11656
Since e4b1f37e, Filter Tool widgets above the Blend
Mode frame do not expand vertically when the dialogue
is resized.
This especially impacts GeglGraph, as you can no longer
increase the text area to see more graph code.
This patch resolves the issue by adding a GtkExpander
to the GUI so that it allows the inner area to resize
vertically.
While setting a plug-in as transient usually worked, it was failing in
cases the plug-in's progress bar was not initialized (i.e. if
progress_init() was not called before setting the dialog transient).
This commit stores the calling display, core side too (libgimp side, the
plug-in already had the calling display ID information), and we use this
when a GimpProgress has not been created yet.
… native dimensions/ratio display by default.
Also adding gimp_vector_load_procedure_extract_dimensions() public
function allowing plug-ins to query the native size or ratio of a vector
file.
Previous gimp_procedure_run_config() was in fact only good for private usage
inside the various run() methods for the different GimpProcedure subtypes. The
problem with this implementation is that the returned config object is not
complete. For instance, for a GimpLoadProcedure, the "run-mode" and "file"
properties are not part of the config object so you cannot call a
GimpLoadProcedure with any of the gimp_procedure_run*() functions.
Note: we had some working usage, e.g. in file-openraster, but only because it
was running the load procedure as a GimpPDBProcedure whose returned config
object was indeed always complete!
As a consequence, I rename gimp_procedure_run_config() as an internal-only
function _gimp_procedure_create_run_config() and I create a new
gimp_procedure_run_config() which always return a full config with all
arguments.
It was a bad idea to bind width/height with pixel density. These are separate
things. You may want to set specific pixel dimensions while keeping a given
resolution.
Moreover I am now properly storing aspect ratio in the widget, otherwise with
integer computation, we are just losing too much precision and the ratio is in
fact changing constantly as you change dimensions.
The bogus 0×0 default values for width×height properties are only because we
don't know the real native size of the image. Once we have computed it, we can
change the param spec defaults, so that hitting "Reset to Factory Defaults" sets
width, height and resolution to the actual file's default values (if resolution
is not a metadata in the format, which is apparently the case for all vector
formats we currently support, then 300.0 stays the default resolution).
I'm moving the logic of choosing a correct default for width/height by adding an
"extract dimensions" callback in the procedure. The logic is that every vector
format out there should likely have metadata either for pixel dimensions or
physical dimensions, or at the very least for no-unit dimensions (ratio only).
Vector load procedures will have to implement only the extraction of such data
in a callback called by GIMP but not how to act upon them, so that we have a
common logic for all vector images.
I am implementing this callback first in the SVG plug-in, moving all the code
to extract dimensions (and improving it) in this callback.
Also I am deleting "file-svg-load-thumb" procedure. I could simply reimplement
it using the same code, but it looks to me like this is very useless for vector
formats to have a specific thumbnail procedure (unless it were to use very
specific metadata for faster result). This is vector data, just ask it directly
at the proper bounding box size.
This new function allows to set a title with mnemonic.
But also it properly sets the frame label as the mnemonic widget for the
radio buttons, otherwise the mnemonic is mostly bogus and doesn't
actually give focus to the editable widgets (i.e. the radio group).
This includes a new function gimp_prop_choice_radio_frame_new() which
creates GimpIntRadioFrame from GimpChoice properties.
GimpChoice GimpProcedure arguments are still creating a combo box by
default, but it is now possible to override this default behavior to get
a radio frame by calling first:
```C
gimp_procedure_dialog_get_widget (dialog, "arg-name", GIMP_TYPE_INT_RADIO_FRAME);
```
Currently, we can not use Gimp.Choice as a parameter type for
Python plug-ins. This means that we're using a string instead for
the "output-format" parameter, which creates a textbox in the GUI.
This patch manually creates a GimpStringComboBox in the GUI and
syncs it with the "output-format" string parameter. Once Gimp.Choice
can be used in Python, we should be able to swap this out without
impacting plug-in developers (since it would also take in a string)
e13cc635 uses gtk-enable-animation to determine whether
the more dynamic motion animation should be used for the
About Dialog credits. However, gtk-enable-animation does
not take into account the MacOS preferences.
This patch adds a check for this value using NSWorkspace's
accessibilityDisplayShouldReduceMotion boolean. Since the
value is TRUE on MacOS if the user wants animations turned
off, the boolean is inverted.
This reverts commit 085d8a02b5.
For some reason, Windows doesn't allow us to use that feature
(confirmed this after using the version from the Store itself,
not the .msixbundle)
… "Reduce Animation" is checked.
This is an alternate version for commit e13cc63525.
Instead of proposing a simpler animation (fade-in/out instead of wave
animation), let's just completely get rid of the whole thing when
someone enabled an accessibility option saying that long animated
contents are basically disturbing to them, which is how I understand
additional issue #11647.
In fact, reading Mozilla docs about such option:
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion#user_preferences
… they even mention vestibular motion disorders, which seem pretty
serious and would make our About dialog quite uncomfortable.
I tried to experiment with just showing a part of the authors list, then
ending on a link text to the Credits tab after a few second, but it
didn't feel that interesting nor useful. Anyway the whole animated
widget is redundant with said Credits tab, and therefore more on the
"fancy" side of things than on the useful one. Hence let's make simple:
if someone configure their OS saying that animated elements are a
discomfort, let's just get rid of useless ones! Done!
Currently, the additional customization
options are laid out horizontally.
Depending on the translation, this might
cause the dialogue window to become
much wider.
This patch converts those options to
GtkSwitch and puts them in a column.
prefs_switch_add () was modified to also
return the GtkSwitch object, so we could
bind its active property for the icon
override property.
The installer is probably the most complex packaging format so one of the
biggest examples of packaging love over the years into it in our repo.
But the readability of installer scripts... leave a lot to be desired.
Now, the main script is organized following the order of installer pages
with some comments. This will make easier to future contributors work
(but this commit probably isn't perfect since it's a big change to read)
The About Dialog shows authors names using motion effects.
Since this is done with Cairo, it does not respect the
"gtk-enable-animations" setting or OSX's "Reduced Motion"
option.
This patch retrieves the "gtk-enable-animations" value.
If it is set to false, then the simple fade-in effect is used
for author names in place of the motion effects.
We have counter measures to avoid installing while gimp opened at 'prep time',
but until now none for the installer itself. Let's fix it with SetupMutex.
The final UX is just less worse (than today): the user needs first to select a
language, then only after this the dialog about two installer will be prompt.
Seems that Inno devs willn't fix: https://github.com/jrsoftware/issrc/pull/461
As noted by Wormnest, if the effect-image drawable is
smaller than the source image, the Van Gogh plug-in crashes.
This is because the source image's dimensions were being
used to traverse the effect-image drawable in rgb_to_hsl ().
This patch fixes the nested for loop to use the correct
width and height values as limits.
Unlike 2.10, the Van Gogh plug-in does not set the effect image
to the current layer by default. This means that if you don't set
it yourself, the plug-in does nothing.
This patch restores the 2.10 behavior by passing the drawable
to the plug-in dialogue and setting it by default with
gimp_drawable_chooser_set_drawable ().
Following 0199faac
We use arm64 runners for the installer job to avoid queues, but...
llvm-objcopy is well know to lack parity and one sympthom is the
'invalid SymbolTableIndex' warning when handling x86 debug symbols.
This commit just makes the installer display a (unchecked) checkbox, like Win
pkg manager (WinGet) so it's doesn't change the actual behavior. It also don't
break string freeze since the .isl string already exists and have translations.
The benefit to some users is having one less click to launch GIMP: [checkbox] >
[close]; instead of: [close] > [start menu icon] > [gimp in 'recommendations'].
The function expects *data to be 64bit wide which is incidentally true
on some architectures but not others. Make it explicit (and portable).
Signed-off-by: Nils Philippsen <nils@tiptoe.de>
Resolves #10609
Continuing from 1759174d, this patch
removes the on-canvas restrictions for
guides from the New Guide dialogue and
the Measure Tool's guide creation feature.
*In file-pnm, format_name is no longer
used due to changes in exporting
functions. This was creating a warning
about an unused variable.
*In 519f301c, an attempt to add a
short-key for MacOS Settings was left in.
It did not work because "comma" should
be spelled out rather than using ",". This
patch removes the accelerator.
Resolves #11617
When we ported Map Object to GimpProcedure API,
the wrong index was set for the Cylinder's bottom face.
As a result, the top and bottom faces both appeared on the top.
This patch fixes the array index to the right value.
Our gimp-win-x86 job fails with the following error:
../modules/gimpinputdevicestore-dx.c:207:28: error: passing argument 2
of 'GetModuleHandleExW' from incompatible pointer type
[-Wincompatible-pointer-types]
Fairly Recent the call to `GetModuleHandleEx` was changed to
`GetModuleHandleExW`. This new call expects a wide char pointer
instead of a char pointer.
So replace it with the wide variant (LPCWSTR). Since in this call
an address is actually expected, the actual contents don't need to
be a wide string.
Commit 015f4946 allowed guides to be
placed off-canvas in the GUI. However,
the restrictions were not removed from
the Script-fu implementation.
This patch fixes the Script-fu parameters
and conditional checks to match the
GUI implementation.
Some apps that write EXIF metadata, forgot to add the charset to
certain tags that require it. The main case is Exif.Photo.UserComment.
This caused us to show a warning about an invalid charset, in addition
to not showing it in our Metdata Viewer.
We fix this by reading the raw data for that tag when we encounter the
above error. The raw data is then validated as utf-8 and converted
to a string if valid.
We then resave this tag to our metadata to force it to have the
correct charset; that way we don't have to do any checking in other
places in our code.
Note: there are a few other tags that also use a charset. We may have
to check those too, eventually.
Completing d09a2a6f, since the dist job wasn't added to MR pipelines that time
Note: this doesn't change the actual behavior. The job will upload to nightly
repo only when triggered from schedule pipelines. I repeat, nothing changed.
What is new is that the .flatpak bundle now is an artifact from dist job, since:
- Despite the name, it isn't a real bundle, so no need to be only in gimp stage
- In dist, it reduces storage use because only the .flatpak file lasts 8 days,
not the .tar and other files from gimp job which lasts 2 days (5495483c)
Resolves #11211
The code that moves the temporary "editing" filter
when modifying an NDE filter was not being run
on custom GIMP filters like Curves. This meant that
editing Curves would always place the temporary
"editing" filter at the top of the filter stack, giving
an incorrect preview of what the changes would do.
This patch moves the reorder code from being in
gimp_filter_tool_create_filter () to being in
gimp_filter_tool_set_config (), which always runs
when any filter is created.
This change also fixes a separate issue where the
filter mask would not be copied over for Curves.
This style mimics the color scheme used by Win32 applications since Vista (and
still used in Win11). The all grey scheme ended in XP. Let's move on.
But we will keep the actual window size and without being able to resize since
these two Inno features (WizardSizePercent and WizardResizable) are broken.
(The progress bar was changed too to conform with the defaults and uninstaller)
Darktable 4.6 updated the version output format to conform
to standards. This broke the regex check that GIMP uses to
test if Darktable is installed. The developers of Darktable
have added a new --gimp flag for us to use for checking
support. This patch updates our check code to use this
API first, then fallback on the original regex code if a
version of Darktable before 4.6 is installed.
Now, the installer files match the meson config.h naming:
'gimp_version', 'gimp_app_version' and 'gimp_api_version'.
"devel" was replaced by meson 'gimp_unstable' too.
util_version was dropped since it lost its utility.
1) Right now, MS Partner Center doesn't tell us if the .pdb bunbled as .appxsym
are fine and we only have "Unknow" dumps in the Health page from MS Par. Cen.
My theory, according to my tests with 'SymChk', 'PDBCopy' and 'llvm-pdbutil',
is that this is happening because .pdb from clang or gcc are not "perfect", but
I really have no proof to afirm this, since Partner Center tell us nothing
about them, and we don't even know if the .appxsym were uploaded to begin with.
---
2) The compiler can't generate DWARF (.debug*) symbols when generating .pdb,
which breaks debugging in DrMingw and even lldb according to my tests.
(This is not a fault of the .pdb format but a circumstance: our debuggers
only support DWARF, which is the format already used by MSYS2 packages)
---
So, the .pdb will return probably only in the potential vcpkg transition.
Currently, messing with filters that are
being managed by tools (like Warp or
Gradient) causes crashes. For now, we'll
prevent removing NDE filters which are
tool-based, and revist after 3.0 is released.
Previous changes broken local building courtesy and probably DirectInput too.
Noticed that the universal variables can not work in some contexts, fixed.
Also, done some little cleanups.
In the Image Dockable, clicking on an image will update the layers and
navigation views. However, the actual canvas image will not update
unless you double-click the item.
This adds a select_item function so the canvas is updated on a single
click as well.
Resolves #11568
Currently, the Stroke/Fill Paths options on
the Path tool disregard the Pixel Locked
flag for layers. This patch resolves this as
follows:
* On the Paths tool, the Stroke/Fill button
does not pull up a dialogue if a single
layer is selected and it's pixel locked.
* If multiple layers are selected, only those
that are not pixel-locked have the Fill/Stroke
applied to them.
In both cases, a warning is also displayed.
There's no seemingly good reason for it not to be introspected, so let's
add it to the files. This also fixes an issue where the documentation
for it is not properly generated.
By defining `GIMP_DISABLE_DEPRECATED` when creating the GObject
Introspection file, we're actually not (or only partially) generating
some of the documentation of some files that are marked as deprecated.
One example that should now properly generate documentation is
`GimpFileEntry`.
Some minor code style issues remained
that I missed in 8adcc0cd.
After further reflection, I also converted
the code to be a private/internal function.
gimp_prop_check_button_new () should
cover the majority of GtkCheckButtons,
and the function is currently only used
to fix the size of those widgets. We could
revisit it as a public function in the
future if more use cases are found.
Resolves #10026
Selecting a checkbutton makes the label bold. This increases the
width of its label, and if it's the longest item in a box, this
causes minor "twitching" and resizing of the dialogue.
This patch calculates the size of the label when bold and then
requests the label width be set accordingly to resolve the issue.
Resolves #11550
The import code for X Logical Font Description fontnames
was not updated to use GimpFont instead of strings.
This caused crashes when we tried to set GimpFont properties
with gchars. This patch updates the code to create a new
GimpFont object from the font name string.
Additionally, it increases the read length by one, as we were losing
the last character of each field as it was split on the "-" character.
Resolves Issue #9955.
GimpToolDialog CSD buttons were being singled out to only
have padding of 2px. This was inconsistent with other dialogues
without this constraint. Since the larger padding style seems to
be preferred, we'll remove the constraint for GimpToolDialog
CSD buttons.
This make them easier to understand and to run local, as we do with native ones
(They can't be run local yet, further changes will try to acomplish this a bit)
Reintroduce pkg caching for crossroad. The possibility of using it is one
in thousands since we don't have distributed cache, but it's better than
rely totally on MSYS2 mirrors, which can be be extremely sick sometimes.
Resolves #11531
GtkListBox's CSS was previously defined, but GtkListBoxRow
did not inherit those values. This patch explicitly defines this
so we do not have system theme leaks.
For now, we can't keep certain GEGL ops
like Gradient as NDE filters, since they are
connected to tools. If the layer is copied
or saved as an .XCF while the tool is still
active, it attempts to save it and causes a
crash.
This patch adds a check to make sure the
copied filter has been commited and that
it's not a tool-based NDE filter before
being copied. It also adds some NULL
checks where gimp_drawable_filter_duplicate
is used to prevent NULL from being
added to the filter stack.
As noted by Anders Jonsson, the wrong parameter description
was removed when the API was updated. Other aspects of the
descriptions were also updated to account for the change.
* Since the appimage is for testing purposes, let's use system 'libc'
* Hardcode python path since the wildcard wasn't expanding misteriously
* Improve system theme recognition making way simpler
This may help to reduce the number of duplicate reports we get about some (temporarily) frequently reported issues, like the current crash
happening since GLib 2.79/2.80, or the crash happening with older GIMP versions on macOS Sonoma.
This won't be perfect because not everyone will use or read the template, or notice the url in it, or use the url to find and check the
reports, but I count on it getting more known than right now.
file plug-in testing.
The name and location of the xml results will be the same as for the
log file, but with the extension replaced by .xml.
Just some basic support is added which adds failed testcases when
a plug-in has a failure result, which should be the most common
case of failures.
Not all cases where we make errors in our test setup will generate
failed testcases yet, although they should show up in the number of
failures.
Disabled tests won't show up as skipped tests.
We also don't track time.
Port all plug-ins to retrieve the layers
directly from the image rather than
having them passed in. This resolves some
issues with introspection and sets the
foundation for future API work.
The move to Clang in 85ed2847 didn't take into account caching,
Now, this is fixed or, better saying, reintroduced(?): e545116b
Also, flatpak-builder output was confined to the .log file to make
possible checking the end of the CI output, which was being cut.
Formerly, closing a port cleared all the attribute bits.
Then the port was not disposed of properly (leaked memory)
when the port was garbage collected.
Now, closing a port only clears the direction bits.
The kind of port is still known for a closed port.
Add test script for file port methods of Scheme.
Resolves #10765
This allows us to retain any filters that a
layer group's children might have when
copied or exported. They were previously
lost when the group layer was duplicated.
Note that an OR condition was added to
GimpDrawableFilter creation, to allow
one to be created if the layer was
attached to a parent layer rather than the
image.
The wrapper, like in native artifact, exists just for avoid searching the exe.
But, if the user wanted, wasn't possible to execute gimp-*.exe directly since
the wrapper was needed to generate loaders.cache. Now, loaders.cache are built.
This improves the gimp.cmd wrapper wording a bit to not need the README
anymore. Our dev site was improved some time ago to clarify this:
the Windows builds aren't not incomplete if run correctly (under MSYS2)
Also, add cleanup commands to make the .typelib wizardy less invasive.
Resolves #11404
Since the GimpContainer selected function automatically updates which filter is the
"active" selected filter, we can remove the code that sets it to NULL after a filter
is deleted. This fixes a bug where the top effect was always deleted in subsequent
attempts rather than the highlighted one.
A now unnecessary gimp_drawable_remove_last_filter () function was also removed.
Without this, Partner Center refuses the .MSIX by not matching the
entry Identity and DisplayName (which isn't the same as the stable).
Also, rework the naming of the .msix's to be more Microsoft-ish
for gimp-tests.log
On Linux we may not have permission to create a log at our default
location, so we need to check for that.
First we should not init the log when our plug-in is asked for info.
Only create it when we actually run the import or export tests.
Second, try to catch the permission error and write a message either
in GIMP or in the terminal for non-interactive.
This commit is mostly a little cleanup:
- Reduce redundancy in Local compatibility layer regarding build commands,
which partily reverts !1171 regarding buggy "ninja && ninja install"
- Reduce redundancy of some variables (MSYS_PREFIX and GIMP_DISTRIB)
- Remove manual QOI install since MSYS2 granted a exception in the win32 drop
This commit also reverts 7cca69cd, a fix from the autotools era that isn't
actually needed according to my tests in CI.
Copied over from the original separate work in:
https://gitlab.gnome.org/Wormnest/gimp-file-plugin-tests
After that further improved and changed and added more file format
tests.
Added meson.build files to integrate it in our build, but we do not
install it for releases.
Should resolve #11392
In dfb26f37, the NDE filters in the copied image are
retrieved with gimp_image_get_layer_iter (). This works
fine for single layer images or when all the layers are copied
at once. However, if a subset is copied then the filters are always
copied starting from the top level of the image. This can result
in an incorrect filter being copied to the wrong layer.
To fix this, we get the filters from the provided drawables list
instead. This matches the number of layers in the copied
image exactly, since it was used to create the copied image.
This regression was added by c064148a and it's similar to fb7a9954. Now, that
we are using 'interruptible: false' in custom rules, this is probably fixed.
Also, organize a bit better some pipelines with official GitLab .yml wizardy.
I was hesitating to use "<<: *" since this creates a new layer of complexity,
but this was the better way and the trick have a distinct marking by the way.
This benefits script authors and testers of ScriptFu.
Now a call to (display "foo") in a plugin goes to the terminal where GIMP started.
Whether interactive or in batch mode.
Make TS errors go to an error port instead of the output port.
Tool plugins: Console, Eval, Server get error messages from the error port.
TextConsole not changed. Tools behave per new doc "ScriptFu Tools" at dev web site.
Driveby fix of SF Server: send whole message instead of byte by byte.
Driveby comments and more semantic checking of set-output-port in TS.
Add test plugin test-display.scm
In addition, this restores the palette options for HGT import
that were accidentally removed from 2.10. Mnemonics
were also added to parameters which were missing them
earlier.
This should hopefully fix:
> realpath: /Users/circleci/macports-gimp3-arm64/var/macports/build/_Users_circleci_project_ports_graphics_gimp3/gimp3/work/build/.GIMP3-build-config-: No such file or directory
Though it's harder to verify because of the "Intel macOS resource brownouts"
going on on CircleCI infra, and only x86_64 runners allowed me to SSH to them.
But I think that's the right fix seeing the error.
The preview widget is a bit stretched, though at least I fix the contents to be
distorted (instead, the preview is fine but we've got black-filled parts
around). I'm not focusing on it because anyway, I'm not sure either if the
preview is that important, or (if it is) whether we should not just integrate it
as part of GimpVectorLoadProcedureDialog, i.e. for every vector images.
For our two "development" sub-stages, the expiration is as follows:
The 'dependencies' stage artifacts continues to expire in 2 hours.
Now, all 'gimp' ones expires in 2 days (to avoid time zone limbo).
For "stage"/tests and "production"/dist, the expire time depends
on the source of the CI pipeline. If the artifact is oriented to a
'short-span' source (e.g. MRs and commits), it expires in 2 days.
If is oriented to a 'LONG-span' one (e.g. web, schedule), 8 days
(we choose 8 to have a +1 day artifact just in case if something
goes wrong in the weekly schedule day, which isn't rare actually).
This happens in particular for in-build runs (or when using
GIMP3_DIRECTORY environment variable on an empty directory). In any
case, I don't see why we wouldn't try and create a directory which was
configured for data storage.
We compile GObject-Introspection anyway (except for cross-builds, where
anyway we don't rely on local Python scripts), so even if not installing
the Python plug-ins, still use them locally.
Resolves #11176
After the initial color space invasion, changing colors in the IFS color
transformation section no longer affected the image. It seems that
ifsD->*_cmap->color held the actual color selected by the user, but
this value was not making it into elements[ifsD->current_element]->v.*_color.
This patch connects the *_cmap->color values to the functions used
to draw the image on the screen.
Move test plugins from /scripts to /scripts/test.
POTFILES.skip that directory.
Add a readme to scripts dir.
Revise readme in scripts/test
Rename test9.scm which tests the new byte type support in Scheme.
Install it in unstable build, it is an important test,
long and sophisticated.
Install contactsheet.scm as a test plugin in unstable build.
See test/meson.build for comments about its issue.
Formerly, both Clothify and "Clothify v3" are installed
in menu Filters>Artistic.
They are duplicates.
Clothify is the original using the old-style, homegrown interface.
"Clothify v3" is new-style, GimpProcedureDialog interface.
Both are marked for translation.
Only Clothify (v2) is translated (in potfiles.in)
"Clothify v3" is not translated (in potfiles.skip)
This commit does not break string freeze.
Moves "Clothify v3" to Demos menu.
It only installs in an unstable build.
The new is installed in unstable only for comparison with the old.
FUTURE: when no string freeze:
Swap the new and the old.
Move "Clothify v3" clothify-v3.scm to potfiles.in
and move "Clothify" clothify.scm to potfiles.skip.
Swap the menu items, so the user doesn't see "v3."
- Fix a few broken references and an inconsistent argument name.
- Add the new headers in the introspectable header list.
- Add a few missing class descriptions for GimpProcedure and subclasses.
Instead of filling default GUI for a specific type of plug-in procedure in
fill_list(), we add 2 methods:
* fill_start() is ensured to run once (and only once) before any fill_list()
code runs.
* fill_end() is ensured to run once (and only once) after all fill_list() ran.
This takes care of 2 kind of GUI bugs which we could have:
1. First if no explicit fill were run (i.e. neither gimp_procedure_dialog_fill()
nor gimp_procedure_dialog_fill_list() were ever run), then the default
interface would not be added to the dialog. Yet this case could happen when
we don't want anything else but the default GUI (this will be the case in the
upcoming file-wmf-load GUI).
2. Second if at the opposite, you fill several times fill functions (I hadn't
thought of this, but noticed some already started to do this in our ported
plug-ins), we obviously don't want the default GUI to be added several times
either.
As expected, it is made to reuse shared code for every GimpVectorLoadProcedure.
In particular, they all need to choose dimensions to load at, so we are sharing
a same GimpResolutionEntry widget logic everywhere now.
I am in fact still very unsure about the code logic for this widget by the way
for these reasons:
* It still puts too much emphasis on the "resolution" (pixel density) part,
which makes people believe it's important, while they should in fact choose
the pixel dimensions most of the time and not care about the pixel density.
* Right now we can't break ratio (which in fact was already impossible in most
vector format plug-ins we had). Do we want to add a chain and allow this?
* If we consider the pixel density as the one we want to set the document with
(which may not be the same thing as the one from when we load the document),
we also want to break link between width/height dimensions and pixel density.
Right now we can't (updating one field updates the others too).
* There is always this issue of precision with pixel density vs. pixel
dimensions because we don't necessarily find the same values when computing
from one side to another because of lack of precision and this confuses
people.
* Finally there is the question of multi-page documents (e.g. PDF) where the
chosen dimensions are the document dimensions whereas each page may have a
different size which has to be recomputed independently and this got me
off-by-one errors. I think I'll need to review a bit the logic, but I'll do
once I've ported all the vector format load plug-ins first to see the most
common usages.
The code comes from plug-ins/common/file-pdf-load.c and apparently it used to be
in libgimpwidgets (very long ago). I'm copying it to its own file and massively
improve the code (depending on property binding which makes the behavior much
more robust).
Still I left it as private because I don't want to say the API is finale without
having tested it a bit more. But eventually we should make it public for
plug-ins to use it directly too. When this happens, it should get back to
libgimpwidgets.
It's still basic but will help to share code for support of various vector-able
formats, such as the logic for dimensioning them, but also the generated GUI.
Not only this, but we are paving the way for the link layers (though it'll be
after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way
for a plug-in procedure to advertize a vector format support. This way, the core
will know when a source file is vector and can be directly reloaded at any
target size (right now, in my MR for link layers, the list of "vector" formats
is hardcoded, which is not reliable).
Only affects unstable build.
Move remaining items to Demos.
They have names like "Test foo."
They only install on an unstable build.
The ScriptFu>Test menu is only in an unstable release.
It is untranslated.
The ScriptFu menus don't need to be so deep.
The Demos menu is an appropriate place for test plugins.
If the Demos menu is not in the stable release and translated,
Gimp creates the Demos menu and it is untranslated.
The "Sphere" plugin demonstrate all the widgets for arguments of a plugin.
Only its menu label is translated.
The "Hello World" plugin demonstrates an independently interpreted SF plugin.
It has no translations, even of its menu label.
Formerly in ..ScriptFu>Test menu.
They still are installed even in a stable release.
If we don't want 3.0 stable to ship with demos,
need more changes to meson.build.
They are akin to the goat exercise plugins.
These plugins are expected to ship with the goat plugins in a stable build.
!!! But 2.10 did not ship with any demo plugins in stable build.
There are duplicate "Sphere" (v2) and "Sphere v3" plugins.
Does not break string freeze.
The new-style "Sphere v3" plugin moves to Demos.
It will be installed with stable build.
No translations will change.
"Sphere" (v2) will only be installed in an unstable build.
FUTURE: we should translate Hello World and Sphere v3.
If they are to ship as demos, their GUI should be translated.
FUTURE: low priority we could rename "Sphere v3" to just Sphere,
and Sphere to "Sphere v2" so there is no conflict.
Partially reverts af79bbe0 (regarding .debug "extraction" in cross builds)
Now, we call the split debug script from the main bundling script, which makes
similar to our macOS .app bundling script. This cleans a bit of code in .yml
and make things clearer to the mere mortals in the scripts.
Its contents is a test plugin, "Test dialog".
I am responsible for it, and it is ugly, even in unstable.
Is only installed in an unstable build.
We need a convention that menu items for plugins named like "Test foo"
should only be installed in unstable build,
and should require no translations.
Note that if the Demos menu does not exist,
Gimp creates it, and it is not translated,
but only present in an unstable build.
Native arm64 and x64 TWAIN binaries are not built anymore. No need to
discard at dist time what doesn't exist. (32-bit TWAIN not affected)
Also, start to using our own ARM64 runners to do the dist. This is more
reliable since the shared x64 runners can (and indeed) cause long queue.
When there is a very long comment shown in the export dialog, the
dialog expands horizontally. Possibly making it wider than your screen
instead of wrapping the text.
Let's set word wrapping for the text view. That way the text will
wrap at a reasonable length and use the multiline text view instead
of just the first line.
They were generating a distracting output in CLANG* shells, as noted by
@lillolollo in a comment from MR: Infrastructure/gimp-web-devel!65
In the process, make AppImage and Windows (native) scripts use these
variables, without hardcoding the same variables from .yml anymore.
Fix ScriptFu, CRITICAL handling filename args user-entered in old-style interface.
Fix plugin, changes to API re Resource i.e. Palette and Colormap
Add message giving mangled name of output file.
Driveby minor refactoring of plugin.
Driveby cleanup, remove old email addresses.
Driveby use script-fu-use-v3 binding to PDB.
Resolves #10914
Some dockables such as "gimp-pattern-editor" and
"gimp-mybrush-editor" are listed as Editors even though
we don't yet have dedicated GimpDataEditors for them.
This causes problems when using certain features like
duplicating. To resolve for now, we check if
gimp_window_strategy_show_dockable_dialog () returns a
valid GimpDataEditor before trying to use it.
Per Jehan, we also verify that an edit button exists
and is visible before we try to call the edit command.
Creating a temporary config directory for the in-build GIMP (run as a tool or
for unit-testing) is not done as a build target anymore, but in the
in-build-gimp.sh script as a unique temp directory, then cleaned out on exit.
This has a few advantages:
- It is properly cleaned out once the build ends (instead of leaving a full
config dir as trash inside the build dir).
- It is not reused from one build to another (with risk of carrying bugs and
issues over).
- Every use of the in-build GIMP will have its own config directory, and in
particular when they are called in parallel.
As a side update, make sure that all `gimp_exe` runs depend on
`gimp_exe_depends`.
This is recommended by Microsoft for "*nix apps" and adding it to the
.exe manifest will avoid disparity between MSIX and other versions
(e.g. CI crossbuilds and CI native builds/installer/local builds).
Bruno note: This commit was repurposed after ad132ad0.
---
For some reason, on the Windows/Aarch64 runners only, submodule updates fails
with:
> + git submodule update --init
> From https://gitlab.gnome.org/GNOME/gimp-data
> * branch d1041a4d97871c85538938872d0ace69d2fc44c2 -> FETCH_HEAD
> error: Your local changes to the following files would be overwritten by checkout:
> images/README.md
> images/logo/meson.build
> images/meson.build
The big question was: why are there edits to begin with? This is supposed to be
a brand new clone!
After a bit of investigation, it turns out that the whole files have incorrect
EOL endings (a `git diff` returns every possible lines in the whole
repositories, but `git diff --ignore-cr-at-eol` returns nothing). It looks like
this breaks the submodule update.
Attribute uap4:ShellNewFileName is meant as a template file to be copied when
someone initiate the Shell "New" command (via the Explorer context menu).
Most of the work in this commit is by @Jehan.
These icons are used only by the .msix (MS Store) distribution of GIMP.
Some legacy icons are used only by Windows 10 and need to have smaller logo
than full image dimensions, so let's not use colorsvg2png. We just pass the
dimensions to use by configuring variants of the same base script.
The new dist job can produce two artifacts: a *.msixupload file
ready for submission and/or a *.msixbundle only for testing.
See the commit about the script for more details.
This makes possible to debug with DIA SDK, if wanted by the developer.
Also, this is needed to create .appxsym files for MS Store debugging.
Ideally meson should be able to install for us, but apparently it doesn't.
See https://github.com/mesonbuild/meson/issues/12977
Adds PowerShell script and proper manifest for making .msixupload
(only for releases) and/or .msixbundle (always, for testing).
As authorized by Jehan, 32-bit willn't be supported. The reasons are:
1. 32-bit is going to die when WIA plug-in is done. This can hurt reviews
2. 32-bit is being restricted in ARM64 version. This causes disparity
3. 32-bit is generating a big footprint. "This is bad for the environment"
To be clear: we are discarding most of 32-bit artifact (see point 1)
and what could not (TWAIN for x64 only, point 2) almost doubles .msix.
There is one small circumstantial reason too:
4. 32-bit wouldn't have .pdb even after GCC 14 because bins have same name
as x64, and MS don't allow multiarch debug symbols in the same .appxsym
Though it's not visible and could happily wait for after GIMP 3 release, this
was annoying when grepping. Just did a quick cleanup.
I also removed gimprc.common which is a forgotten remnant from the autotools
build.
Per Pippin, the only color model that can
have double precision is RGB/A.
Therefore, we need to switch all others to
use float instead. This patch converts the
HSV and HSVA double babl formats.
As hinted in d09a2a6f
We now use the word 'bundle' to signify "program files in the same prefix"
(e.g. .appimage, .zip, .app). This is in line with our source and dev-docs
(just take a search in the repo). So, appimage and windows scripts changed.
The word 'package' normally means "program files distributed for install in
the same prefix or not" (e.g. .deb, .msi, .dmg). This is in line with CMake
naming of some commands, but meson prefers to call 'dist', which we use more.
So, this partly reverts some things of GNOME/gimp!1171 and reinforce others
for even more "rationality" in the overall build structure of GIMP.
… since forever anyway!
GIMP used to have a second export dialog, a generically generated one, appearing
either before or after (depending on when gimp_export_image() was called) the
custom export dialog implemented by the plug-in code. This has been hidden deep
in code since forever (since version 2.8.0 in fact, I believe) and only kept
hidden behind an environment variable "GIMP_INTERACTIVE_EXPORT". I don't think
we'll ever revive this, so let's clean up.
In fact, not one, but in worst case even 2 more dialogs were hidden behind this
variable! The first dialog (confirm_save_dialog()) was a confirmation when the
selected drawable was a layer mask or a channel (and not a layer). Most export
code don't even seem to care about the selected drawables anymore anyway (cf.
issue #7370), except with gimp_file_save() non-interactively (issue #8855),
which is a real mess of inconsistency anyway.
The second dialog (export_dialog()) was listing the various actions to do on a
copy of the image to help the plug-in (e.g. merge layers/flatten image, etc.)
and possibly give choices to some of these actions. Though there is definitely
no reason to request this kind of thing anymore, especially for a short-lasting
image copy, the list of action could still be interesting in the future, not as
information of what is going to be done, but as information of the kind of data
loss of the exported format. I could imagine we want to be able to reuse such
information for generating types of data loss per format in the export dialog,
in particular in the context of my long-term export workflow refactoring (from
which resizing before export such as #2531 are part of, but the whole
refactoring project is much wider).
In the whole discussion of #5858, there will be the question on whether we don't
want plug-ins to be directly given a "ready-to-use" image depending on
capabilities they advertized in create_procedure().
Should resolve #11370
Per Pippin, HSV double is not a valid
color model for babl. We need to change
to HSV float to resolve the warning when
selecting colors on the Color Wheel.
This is a well know problem documented in GitLab docs that happens when
the CI isn't properly configured that was causing double pipelines in MRs.
Let's fix it, and reduce some redundancy.
This line should have never been pushed (in commit a78c41d2a3), my bad! It was
an early (extremely ugly and bad!) attempt to try and have the bindings see the
libraries another way than using DYLD_LIBRARY_PATH (which was instead resolved
with commit 3e980d5ad4).
This omission went unnoticed until I add `set -e` very likely as this failed
command would stop the script in failure.
- gimp_rgb_list_names() ported as gimp_color_list_names() using NUL-terminated
GimpColorArray.
- GimpColorHexEntry uses the new function (and is therefore now GimpRGB free!).
- gimp_rgb_parse_name() deleted as it's unused since my previous commit.
With all this, gimprgb-parse.c is now deleted from the repository! \o/
I suppose the intention of having this stage at the end was to make clear: no
job depends on it. However, this place is not common or ideal but one of two:
1) before building, which is more linear; or 2) after building (the choosen)
even if this isn't dynamic analysis (tests), since they are both related and
some compilers and build systems do static analysis. Anyway, not after dist.
The new place is a bit more clear to devs used at "build, test, deploy" praxis
and maybe will be now better noticed by the existing devs before distributing.
It's not perfect, since I explained above that there are two places/approaches.
Obviously, the stage continues to be OPTIONAL to pass, nothing was changed.
---
Also, dropped the deprecated "only:" (in clang-format job) in favor of "rules:"
and made the artifacts paths of clang-format and cppcheck more consistent.
Fix tests broken by changes to gimp_data, wilber.png=>gimp-logo.png
Uncomment failing tests whose issue was fixed.
Remove calls to deprecated functions.
Make more test files use v3 binding script-fu-use-v3
Compare floats relatively by epsilon.
Add some missing tests.
… test-color-parser.c file.
The file libgimpcolor/test-color-parser.c was compiled but never actually called
by the build. Now that we have a nice infrastructure to test libgimp API, I am
moving it there with the new format. Doing this also allowed me to discover some
bugs in CSS parsing, as well as discover Python binding was failing here (cf.
the few previous commits).
Only one test is disabled so far, the one where 4 digits are used per channel in
hexadecimal notation: "#64649595eded". This format simply doesn't appear
anywhere in the spec, and also the result values in the samples listing don't
even fit. So far, I'm just unsure what to do with it, if we want to keep this
support (of some kind of higher precision hex notation, but not specified, so is
it even used by anyone?) or not.
All the other tests just work in both C and Python!
New functions with the same name as these functions are created, except without
the length argument (i.e. it's equivalent to calling these with -1).
The reason for this is that using strings with a length variant which may be
negative to switch to NUL-terminated strings are not bindable. At least in our
case, when testing in Python, the input string ended up as corrupted garbage and
GObject Introspection docs warns about such interfaces:
> In particular, avoid functions taking a const char * with a signed length that
> can be set to a negative value to let the function compute the string length
> in bytes. These functions are hard to bind, and require manual overrides.
(see: https://gi.readthedocs.io/en/latest/writingbindableapis.html#strings)
So instead, I create a simple version which runs on NUL-terminated strings only
and which is bound, whereas unbinding the generic length-version (making it
C-only, or maybe usable in some other bindings which ignore the (skip)
annotation; apparently some do this).
- "transparent" is now recognized. It was forgotten (probably because on the
GimpRGB interface, we separated the API in a _rgb_ and a _rgba_ variant).
- rgba() and hsla() formats are now fixed (implementation was there but the
function names were not recognized.
- Adding some comment about limitations of the hexadecimal notation (we don't
support the alpha channel which is now in the CSS specs, while we also support
some non-specified variant with every channel on 3 or 4 digits) for future
work.
This fixes:
> plug-ins/script-fu/script-fu-refresh.c:70:1: warning: no previous declaration for ‘script_fu_register_refresh_procedure’ [-Wmissing-declarations]
This is meant to obsolete GeglParamColor with at least an additional argument
has_alpha which we need in GIMP. It allows to advertize when a parameter wants
an opaque color, which in particular means we know when displaying a GUI to pick
colors with alpha or not.
Our pluginrc code is already able to output NULL for a default NULL color, but
reading was failing with the following error:
> GIMP-Error: Error while parsing '/home/jehan/.config/GIMP/2.99/pluginrc' in line 289: unexpected identifier 'NULL', expected number (integer) - fatal parse error
Let's support reading such a value now, especially as for Python plug-ins, we
are not even able to add a default value to GeglColor arguments (cf. previous
commit).
In some binding (e.g. Python), we have not found how to create GeglParamColor
specs for PDB procedures, so we use GParamObject specs with `GeglColor`
object_type. Have our code handle both variants.
Fixes:
> GIMP-WARNING: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor'
Of course such generic spec won't have any future option which we may add to a
dedicated param spec (and despite adding code to handle a default value, adding
a default color still doesn't work according to tests).
There are no plug-ins which uses GimpRGB for procedure argument, nor is there
any base PDB procedure. We don't pass this type anymore through from/to
core/plug-ins. So let's clean the whole code out as a next step to get rid of
GimpRGB from our codebase!
Resolves #11347
In multi-window mode, it is possible to change images without
causing the layer effects popover to close. This results in the prior
image's layer effects being shown over the new image, which is
confusing. This patch causes the popover to automatically close
when the image is changed to prevent this problem.
AppImage is pretty fast to make, like the win crossbuild; and portable,
being very appropriate to do quick tests on Linux when pushing to git.
The overall organization of Debian jobs was changed to take advantage
of this and make things less complicated (but less clear at first sight).
I reinforce that this was the most efficent way to make the AppImage.
This fix doesn't feel right. The whole point of having a generated manifest from
the build was to use it for our flatpak job (through job dependency). Right now,
it has been rendered useless. We must either re-implement the proper job
dependency or find another way to fill the proper "command" with the right
version (maybe just a standalone script to be used in Gitlab CI and which we
could tell about to people who wish to build the nightly flatpak themselves).
Anyway for now, it should do as I don't want to spend too long on this. It
should fix this error in the log generated as artefact of the "gimp-flatpak-x64"
job:
> ../build/flatpak/meson.build:6:2: ERROR: File org.gimp.GIMP-nightly.json.in does not exist.
Resolves #11354
Due to improvements in the text API, we have to pass a GimpFont
object as the last parameter of gimp-text-get-extents-font rather
than just a String.
These files has been generated by the installer scripts for historical reasons.
Now that we have full-blown local builds and the upcoming MS Store version,
this pervasive pratice can't continue since it creates disparity between builds.
When closing the Page Setup dialog we had warnings and criticals in
the terminal.
The cause for this was that we were looking for the temp procedure
to notify the print plug-in. However, this temp procedure is only
installed if the print plug-in is running, not when running the
Page Setup directly, in which case it is not needed.
We now check if the procedure is valid (meaning the print plug-in is
running) before calling the temp notify procedure.
Resolves #11324
Similar to 403af188, we needed to update function calls
that assumed they were receiving a GimpRGB struct rather
than a GeglColor object. Future plans including adding Gegl
functions to retrieve HSV and HSL automatically, rather than
using gegl_color_get_bytes().
Removes an index that was needed to GimpRGB, but no longer
valid now that gimp_palette_entry_get_color () returns a GeglColor
object. Also, fixed an issue in Interactive Mode where the first
valid palette would be used for every other attempt, no matter which
palette you clicked on.
Switch to using gimp_item_convert ()
instead of gimp_item_duplicate () so that
the filter mask can be properly associated
with a new image when copy/pasted.
Previously, filters were lost when copying
individual layers. This patch copies them
to the clipboard image on cut or copy,
then copies them back to the pasted
image.
It also fixes an issue where filters would
be merged down if a selection was
copied instead of the entire layer.
The comment I had written back then was wrong. Meson in fact can create an env
object from another with a simple assignment (which copies the object, rather
than pointing to a same object), per the answer which has been given to me in:
https://github.com/mesonbuild/meson/issues/13045
This allows to have a properly separate environment (when using GIMP as a build
tool, we don't want to load the test files).
We are using `gimp_image_set_file` to set the filename, which
requires an extension, not doing so caused an error.
So let's add .xcf to all compose filenames.
When decomposing, the plug-in sets the filename without changing the
extension. However, gimp_image_set_file requires the filename to be
an .xcf file.
To fix this we simplified `generate_filename` to always add an
.xcf extension.
While doing this we also fixed a critical that happened when no
filename was set (new image), by testing `gimp_image_get_file` for
being NULL first.
When no filename was set it also didn't use the type when
config_as_layers was set, this is also fixed.
Resolves #11334
GBR, GIH, and PAT have internal save functions which are not meant
to be run directly. However, they were showing up in the Search dialogue
as valid options. This patch adds an additional check for "-internal" to
prevent users from accidentally running them, as they only give a warning.
The whole action name prefixing will definitely need to be straightened up in
our codebase at some point (differenciating the global actions and the local
ones).
Resolves #11337
"gtk-icon-shadow" is applied to all buttons with images,
which creates a bold effect on symbolic icons.
This patch zeroes this effect out and makes them highlight
the background in the same way as the toolbox buttons.
For certain min/max values of the LabelSpin widget, in combination with
zero digits, it proves impossible to change the initial value.
The reason for this is that the step size may become less than 1.0.
In which case, stepping doesn't work because the number of digits is
set to zero.
Let's check for this situation and when digits is zero set the step
to 1.0 and make sure that page is at least the same value.
While testing this I also noticed another issue: when initializing
the upper value was set to 0.0 and the lower to 1.0 which leads to
a critical because lower > upper.
We fix this by switching the initial upper and lower values.
There was no user feedback when our twain plug-in couldn't find the
(32-bit) TWAIN driver, making for a poor user experience.
Especially since nowadays the availability of the twain driver is
less likely, let's add an error message for the user, so they will
know what's going on.
The previous commit worked for all the compiled executables, but for Python
plug-ins (and likely all other GObject-Introspected bindings), we need to
generate a temporary typelib linking to the in-build-directory libgimp*
libraries.
This is similar to what the script `package/macports_build_app.sh` does for
packaging in gimp-macos-build repository.
Resolves #10932
Since GIMP distinguishes between saving
XCF and exporting image like PNG,
we should change the PDB to show
export rather than save in the function
calls.
This stage was introduced in 076e4d68 and it fulfilled well its purpose. But
the side effects were: more (sometimes slow) uploading and downloading of
packages and artifacts. Even if we have caching, this is far from ideal.
Now, the so-called "packaging" jobs were moved inside in the "build" jobs.
The advantages are: just one pacman install (ideally cached from deps job);
direct packaging without waiting for upload/download; and less confusion,
since "packaging" naming was implying that the .zips are somewhat official,
which isn't totally true, and sometimes overlaps the dist/deploy concept.
---
Also, the flatpak job now uses config.h instead of triggering a GIMP build.
In other words, I'm reverting part of my work in some old commits.
Unlike the previous 2 commits, this was not making an error but was the reason
why our code was keeping the last closed GimpImage alive a bit longer than it
should. In particular, the status bar code was keeping a hard reference to the
image until the focus changed, hence preventing the object to get finalized
longer than necessary.
Now it will also be a weak reference, so the image is immediately freed when the
view is closed.
Now, the CI will auto cancel jobs after a new commit is pushed and retry when
the runners fails. The first case is frequent, the last is rare but happened.
Since the GeglColor port, gimp_drawable_get_pixel () returns
a GeglColor rather than a GimpRGB structure. We needed to
update the supporting code in ColorXHTML to handle the change.
As a follow up to the previous commit, I noticed that the pdb functions
gimp-edit-cut and gimp-edit-named-cut also incorrectly used
gimp_pdb_item_is_group.
This can be seen by calling Filters/Blur/Tileable blur when a group
layer is selected. The error message was incorrect.
We replace the call here also to `! gimp_pdb_item_is_not_group`.
Calling gimp_selection_float from a Python plug-in could make it crash
with an error like Calling error for procedure 'gimp-selection-float':
Item x cannot be used because it is not a group item.
This is caused by an incorrect check for group layers.
gimp_pdb_item_is_group returns an error when the condition is False,
while we only want an error when a group layer is selected (True).
Thus we need to use gimp_pdb_item_is_not_group, which returns an error
when the item is a group, which is what we want.
These function names are a little confusing, we might need to think
about better naming sometime.
I added C/Python tests for this function, so that we can test whether
this works correctly.
This is now back in sync with how it used to be up to GIMP 2.10. Basically our
API version should always be <major>.0 in the shared libraries naming, as well
as in pkg-config and docs. Otherwise we would break library compatibility with
every minor version bump.
Code that checked if an image was NULL was run
*after* the variable was used in a function,
gimp_image_resize_to_layers (). This patch moves
the NULL check before the function call is made.
Additionally, we now verify there are at least two axis
before trying to access indexes in the naxis array.
Since !1171 the 'before_script' was being used by me for organization, but
this is at least unexpected to "mainstream" .yml pratice and can be wrong.
For example, the universal variables can't be properly used this way.
So, let's use 'before_script' only for the (official) purpose: save code.
Resolves #11292
Since the GimpProcedureDialog port, the "settings-data"
parameter has been used to save and load the selected
color map. However, the parameter was not being updated
when the user switched colormaps in the GUI - therefore, it
always used the "Custom Gradient" option.
This patch updates the "settings-data" parameter after the
change to resolve the issue.
This isn't directly related with #10922 and does NOT affect 32-bit support.
After talk with @Jehan, author of 'crossroad' and main dev of crossbuilds,
we decided that the x86 crossroad builds can be dropped by these reasons:
1) 32-bit crossbuilds weren't being built. They are used since c8ec0ae7 but
after the native 32-bit builds they ended in a state that they are the only
pipeline that isn't automatically triggered in any way, a complete limbo.
2) 32-bit crossbuilds weren't being autonomous. They are not working fine
with wine32 so the win-x64-cross artifact is a 'need' and now debian-x64,
so we were spending way more time fixing than using the 32-bit cross jobs
(sometimes the 32-bit cross jobs are just broken and we even noticed).
We have other jobs not autonomous but they don't have additional bugs
like not being able to build with .mng and .wmf (32-bit cross only bugs).
---
The x64 crossbuilds will continue to be supported. They are very useful to
develop on Linux, and test MRs on Windows. I'm an assiduous user of them :)
Resolves #11283
In the GUI, set_flame_preview () is connected to GimpProcedureConfig's
"notify" signal. However it is not disconnected afterwards, so it runs again
after the plug-in is finished and the "setting-data" parameter is updated.
Since the preview area no longer exists, this causes a crash.
This patch resolves the issue by storing the callback ID and then disconnecting
after the GUI is closed.
This was added in a22393a6 and e96b751e, following old 2_build-gimp-msys2.sh.
But, according to my tests (local and in the CI, in both Debian and Windows),
meson creates this in setup time so the manual folder creation is redundant.
Resolves #11250
In 2.10, we explicitly hid "dockable-preview-size-menu", the submenu
for Preview Size, if there were no previews to set sizes for in the
dockable dialogue. In 2.99, this code was removed as part of the
GAction port and code clean-up.
As a result, the Preview Size submenu is always visible even if the
options have no effect on the display. To restore the 2.10 behavior,
we set each Preview Size option's visibility. If all options are hidden,
the submenu does not appear.
* Move common things to the new .default section extensible for all jobs
* Reorganize order of job elements to be way more consistent and rational:
from general (pipeline/rules) to specific (job artifacts) in a liner way
* The order of rules was changed to be a bit more easier to understand
- Drops 'dependencies' which is redudant, and 'needs' have more options
- Drop apt-cache which lost use and it is sometimes troublesome to cache
+ First try to boost the use of ccache in all build jobs, when possible
+ Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
Build for macOS on CI breaks with:
> ../gimp3-2.99.19/libgimpwidgets/gimppickbutton-quartz.c:210:45: error: use of undeclared identifier 'monitor_profile'
> space = gimp_color_profile_get_space (monitor_profile,
In case there are no fonts loaded (which may happen in particular when starting
with --no-fonts), we need to make sure that font is initialized to NULL so that
we can return the standard GimpFont object and not a broken pointer.
Thanks to Idriss for the additional diagnosis, which would hopefully complete
commit 5dc86277e6 and take care of #11219.
This commit uses definitions and references to reduce repetition of CI code.
Some people (like the GitLab devs?) prefer (almost imposes) this to be done in
multiple .yml's using 'worfklow:' but this makes the CI way more complicated
and very slow to read. So, let's just keep simple in one human readable file.
---
Other changes are:
- The custom native arch pipelines now they always generate a .zip package.
This helps to ensure that everything is in place and facilitate testing;
- The pacman update (-Syyuu) was removed since it is auto done by runners;
- The ccache config was moved to .yml. This does NOT affect local builds
since meson saves ccache by default for user in '%LocalAppData%/ccache'.
Previous code would only set the class member when we were actually
loading fonts, so we ended with code paths where the member was NULL.
Fixes:
> GIMP-CRITICAL: gimp_container_get_n_children: assertion 'GIMP_IS_CONTAINER (container)' failed
It should hopefully also fix #11219 (though I couldn't reproduce this
failure).
Resolves #11256
A GError variable was created but not passed to
file_open_with_display () when opening recent files.
As a result, if an error did occur the variable would be
used while it was still NULL. This patch fixes this
by passing a reference to error as the last parameter
of file_open_with_display ().
We compute the size of the mipmapped layers wrong. We assume that
width, height are always exactly a power of 2, which is the normal case
for dds images. See issue #11256.
Since other sizes are possible, we adjust this by computing the width
times height times bytes per pixel of the current mimmap level.
Resolves #11075
In the DrawableChooser pop-up, choosing an image without
also picking a layer or channel causes the pop-up not to
reappear on subsequent attempts to click it. This is because
the callback is only recreated when the drawable is updated,
and choosing just an image does not update the drawable.
For 3.0, we'll set the Okay button to insensitive unless a layer
or channel is picked.
I added a few improvements to how we load the Photoshop layers:
- When included from TIFF, we forgot to decrease the data_length for
the parts we already read.
- Also when included from TIFF, we need to skip the global layer mask
info.
- The block length for the layer data needs to be a multiple of 4.
- Catch an invalid data condition where block_len is greater than
total_len. This could cause a change total_len to a very large
value, so protect against that.
When loading Photoshop metadata from TIFF images, the size of the data
in the temp file was often incorrect.
This happens because run_mode is usually GIMP_RUN_INTERACTIVE when
run from within GIMP. In interactive mode, the last saved config values
take precedence over the ones set in the function call, which is not
what we want in this case.
We would prefer to use interactive here, because then we can show a
dialog with a list of unsupported Photoshop features that were found
inside the image.
For now, we will use GIMP_RUN_NONINTERACTIVE and accept that we can't
do that at this time. This way we will at least have the correct values
when processing the Photoshop data.
The clipping path values are all 2 bytes, but we were only reading in
1 byte for each value. In addition to that, the path_flatness_fixed
value was not converted to the correct Endian representation.
Since these values are usually 0 and get clamped to valid values, this
went unnoticed until now.
Fixes 2 such warnings:
> warning: format ‘%i’ expects argument of type ‘int’, but argument 5 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
As well as:
> warning: conversion lacks type at end of format [-Wformat=]
And:
> warning: no previous declaration for ‘reset_output_port_struct’ [-Wmissing-declarations]
Fix unreported issue that new-style dialog using GimpProcedureDialog
does not display progress.
Change progress reporting to use app's status bar, for all scripts,
old and new style.
As before, report progress whenever a script calls a PDB procedure,
by putting the procedure name in the status bar.
Eliminate progress bar widget from old-style script dialog.
Since it was failing on Wayland, and since it is inconsitent
with new style dialog using GimpProcedureDialog.
Resolves #11246
On Windows, a CRITICAL was being repeatedly thrown if you
didn't have a monitor profile set. This is because we were trying to
pass a NULL value to g_utf16_to_utf8 () whenever we needed to
convert a GeglColor.
This patch fixes it by checking if the monitor profile filename is NULL
before trying to convert it.
Resolves #11244
GtkRadioButtons can also have the .text-button CSS class set. This class was overwriting
the radiobutton background color, making it appear dark and box-like.
This adds a specific radiobutton.text-button definition to ensure the background color
is consistent (as we had to do with checkbutton.text-button)
It is broken and throws critical, see #10596.
Expedient to hide it instead of fixing it, to not block 3.0rc1.
As discussed in #10652, a user can simply restart GIMP instead.
"Refresh Scripts" is a poor design, a bandaid.
There are plans for better alternatives to install/remove scripts.
The MR for #10652 shows the reason it throws critical,
and could fix it,
but completing the MR requires time we don't have.
Note the MR is not on these files, but on core plugin machinery.
The change is to extract functions to a separate file,
and still build them, but not call them or link them.
They also are not translated while not being called.
Eventually, the extracted files can be deleted (or restored when they work.)
There is other related cruft that needs deletion in scheme-wrapper.c.
Add canonical/idiomatic functions call-with-output-string,
call-with-input-string, any->string to the library init.scm.
Since they are useful, especially in test scripts and frameworks.
Remove their definitions from test scripts and test frameworks.
Also comment out failing test in test script string-escape.scm.
Redefine call-with-output-string etc. in the test script: test9.scm
Other fixes to the test script.
Improve logging of no memory condition for string-ports
Fix bug freeing ports that have been closed.
When ports are closed, string-port code was treating them as string-ports.
Fix #11040 and #9495 bugs with unicode in string-ports
Fix other unreported bugs with allocations and garbage collection of string-ports.
Obsolete open-input-output-string, a string port of kind input-ouput is no longer supported
and the function actually opens a string-port of kind input which cannot be written.
Comments and Gimp style in the original TinyScheme code, now in string-port.c
Revise tests of string-port.
Update TinyScheme README: Discuss more thoroughly the ancestry, and changes from upstream.
Extract pseudo class string-port methods to separate file.
No functional changes intended.
Style changes not complete: anticipate further bug fixes and styling.
This is not seen on all distributions (mostly on Debian-based ones in my
experience), but some distributions install libraries in a second-level
directory under prefix (e.g. lib/x86_64-linux-gnu/ instead of lib/ or lib64/)
whereas our prefix-guessing code for relocatable builds harcoded moving up from
1 level.
This new heuristic will assume that if the leaf directory is neither bin/ nor
starting with `lib`, then it's likely a multiarch folder and we must move up
once more to find the prefix folder.
This should also fix the problem encountered by Bruno for the current work on a
potential official AppImage.
We dereference "file" twice in gimp_prop_file_chooser_button_callback(),
once in the GIMP_IS_PARAM_SPEC_CONFIG_PATH () condition and then
at the end of the function. This is likely due to a similar structure in 2.10,
which did not have a second condition.
As a result, any Gegl filter which had a file property would crash if set from
a GUI. The first g_object_unref() is removed so we only dereference "file"
once.
Resolves #9795
(Solution provided by Andreas G, @uriesk)
Some system themes provide errant values for tooltip
box-shadows which cause flickering effects.
This patch defines the tooltip box-shadow to 0px to
prevent the issue.
Resolves #11054
NDE Filters clip to the size of the layer when
applied. Group layers get their dimensions from
the largest layers under them, so an empty
layer has dimensions of 0 by 0. This means a
filter applied when the layer group is empty will
be clipped to 0 by 0 as well.
This patch adds code to refresh the filter's crop
whenever the group layer is resized by a
layer being added or removed.
These commits introduced sensible drawbacks in our CI file organization.
Some of them I already commented in the MR but was "ignored" back then
probably due to the complexity of the MR. So, the let's revert:
- Unecessary repetition of libomp installation (4 times, now 1)
- Unecessary repetition of submodule initialization (6 times, now 4)
- Creation of new variables in the hope of more clarity. But,
they aren't consistent with the gimp-web-devel instructions
nor with other systems variables. This is terrible to undestand.
Please, let's not reinvent the wheel since this is a bad example to
packagers, since they tends to isolation and overly-engineering.
Also, made some little adjustments that I should have done in previous MR.
---
This MR was splitted. Even more simplification will be done in the future.
...to accept GeglColor paramaters instead
of GimpRGB. This function is used to draw
the layer/channel color tags.
Note that a temporary GimpRGB was left
to use with gimp_rgb_composite ().
It will be replaced once that function is
also converted to use GeglColor.
752f0fb4 did not fix saving/loading filters
in .xcf files. To do this, a new function to
retrieve the clip setting was added to
gimpdrawablefilters.c, and then used to
save the value in xcf-save.c. The existing
set_clip function was used in xcf-load.c,
just like in 752f0fb4.
Resolves #10997
When filters are duplicated for export, the clip property was
not being copied over. This caused filters that go outside the
layer boundaries (like Drop Shadow and Long Shadow) to be
clipped incorrectly.
The simple fix was to copy over the clip value when the new
filter was duplicated.
Resolves #11147
Applying the same reordering code
in cbb1e816 to adding a floating selection.
When anchored, floating selections were also
merging down all layer effects onto the original
image. This patch places the float selection
under the layer effect when added, both to prevent
this and because it seems to be the expected
behavior based on user feedback.
Resolves #11146
As Idriss Fekir and I noted, 5ce128a9 added support for
receiving GeglColor data to GimpColorAreas, but
retrieving it still resulted in RGBA application/x-color
values being stored when dragged.
This patch updates gimp_color_area_drag_data_get () to
give the format and profile information along with the
pixel values.
When loading a PSD with multiple extra layer channels, the PSD loader
crashes. We increase the number of layer_channels with 2 for every
extra channel found, which we only should do for the first extra to
skip the alpha channel.
We fix this by adding a check to see if this is the first extra channel
and in that case skip the alpha channel slot. Any other extra channel
will be added in the next available slot.
We also add an extra check in case we have extra channels when we do
not have an alpha channel in the layer. Not sure howe likely this is.
In that case we move the last extra channel to the slot reserved for
the alpha channel. That way we won't try to free non-existent alpha
channel data.
Note that eventually we should probably try to add these extra layer
channels are extra image channels in GIMP, since GIMP doesn't have the
concept of extra channels per layer.
The border-drawing code for Layer icons
has been ported to GeglColor. Note that
GimpViewRenderer still uses GimpRGB for
gimp_cairo_checkerboard_create (), which
will be fixed in a larger commit.
In 9bee3bed, Border Average's return
value was set to NULL rather than a valid
GeglColor when the procedure was
created, which caused a warning on
launch. This has been fixed.
Perspective shadow could call plug-in-gauss-rle with higher blur
radius than allowed in the wrapper. Raise the max value to
allow for this.
Fixes #11140
Since dist-installer-weekly doesn't depend on gimp-debian-x64 anymore, we need
to grab the config.h from one of the other dependencies. Let's use the one from
gimp-win-a64 (though it could have been any other Windows build job).
Fixes:
> Get-Content : Cannot bind argument to parameter 'Path' because it is an empty string.
> At C:\_r\_builds\vJWzEqDv\0\GNOME\gimp\build\windows\gitlab-ci\4_dist-gimp-inno.ps1:13 char:39
> + $GIMP_VERSION = Get-Content -Path "$CONFIG_PATH" | Select ...
> + ~~~~~~~~~~~~~~
> + CategoryInfo : InvalidData: (:) [Get-Content], ParameterBindingValidationException
> + FullyQualifiedErrorId : ParameterArgumentValidationErrorEmptyStringNotAllowed,Microsoft.PowerShell.Commands.GetC
> ontentCommand
The dependency to libomp apparently came with the move to CLang.
Fixes:
> /builds/GNOME/gimp/_install-debian-x64/bin/gimp-console-2.99: error while loading shared libraries: libomp.so.5: cannot open shared object file: No such file or directory
When running GIMP in the build environment (even before it's installed), we
don't want to "fix" paths. We had the case in particular on the macOS CI where
the install PREFIX was a parent directory of the build directory and therefore
we were "fixing" some perfectly good constructed directories (set by meson) into
non-existing folder paths.
Additionally this codepath should only run when ENABLE_RELOCATABLE_RESOURCES is
set (even though this alone would not have fixed our CI issue because the macOS
build is relocatable).
Finally I am updating the gimp-data repository so that libraries are properly
found from the (now correct thanks to this commit) paths set by meson when
running gimp-console from within the build directory.
When the config directory is set by an environment variable, the version is
likely not part of the directory path, and therefore strstr() would return NULL.
Fixes:
> (gimp-console-2.99:41446): GLib-CRITICAL **: 13:19:34.933: g_vsnprintf: assertion 'n == 0 || string != NULL' failed
Now the development and stable logos will be generated from gimp-data.
In other changes, the gi-docgen logo is installed as a symlink using
install_symlink() which exists since meson 0.61.0 so I bumped our meson
dependency (in practice we were already using this function anyway and Debian
bookworm has meson 1.0.1 so it's all good).
Finally I don't install a wilber.png anymore, which was only used by script-fu
testing, and which was the same as gimp-logo.png (except 256x256 instead of
128x128). Unless mistaken, all script-fu tests loading this image still work
with the change. The only one where I needed further change was buffer.scm
(which was checking the dimensions).
See gimp-data@9aa6e35.
- With last commit, the Windows installer pipeline doesn't depend on
"gimp-debian-x64" job anymore since a native Windows build is now able to run
GIMP (or gimp-console) as a build-time tool as well. It makes the Windows
installer pipeline (and full custom native builds) self-sufficient.
- On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require
"gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in
order to generate some image data (such as the splash image, and probably soon
logo or icons, etc.). See gimp-data@5a03c71.
- Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of
"image-debian-x64" for all Debian as well as the cross-compilation jobs. They
are all based on the same Debian image (it was debian:bookworm for native
Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork
for all) and it's just a few more packages (cross-compilation C and C++
toolchains) for the cross-builds. Moreover now the cross-builds also need the
native GIMP binary around, therefore native dependencies are needed as well.
It makes sense to factorize all 3 images into 1.
- Make sure we don't build bindings when cross-compiling since these won't work
in this case.
This commit is in conjunction of gimp-data@d273a18 and finally makes Windows
build able to run GIMP main binary itself (or gimp-console) in order to create
various images, before the installation step.
- Use the new GIMP_TESTING_INTERPRETER_DIRS environment variable for uninstalled
binary to find the .interp files (in particular because our build scripts are
usually Python scripts these days).
- Use the new GIMP_TESTING_ENVIRON_DIRS environment variable to find .env files
(actually running uninstalled GIMP binaries did run without this one, but it's
not a bad idea to add support anyway.
The python.env file sets a ':' separator for GI_TYPELIB_PATH environment
variable, which breaks finding the correct typelib files in the CI, when also
manually setting a previous value for this environment variable.
I'm not entirely sure the rule of swapping ':' for ';' is universally true on
Windows, whichever the variable. Let's hope that it is.
- Splash images will now be stored from gimp-data.
- The installer BMP image scripts also move in the same time.
- We don't need devel and non-devel variants of the BMP images in InnoSetup
scripts since the images are generated from the actual splash.
Meson subprojects just have too many problems and limitations and I can foresee
the maintenance headache and the future incoming false-positive bug reports if
we start using meson subprojects.
Comparing to the simplicity of git submodule which also has much better
notifications to help people understand when the submodule is not in sync and
how to remedy to it.
See commit gimp-data@c364adb explaining the main reasons in detail.
Note that the executables are not built yet at this point, but we just need to
pass the name for configuration. The gimp.ico generation step is run manually
anyway and requires a fully functional and installed GIMP.
See commit gimp-data@40d4822.
This commit is separate from the previous to make it immediately clear (by
comparing files) that the previous commit is a simple move with no modification
whatsoever of the icons/ directory, i.e. the symmetrical removal of add commit
gimp-data@8b54490.
We now clone gimp-data as a meson subproject. I am currently testing the
subproject feature though I am doubting a bit because of its limitations: the
git clone is not updated automatically, nor are errors clear. Therefore it would
be easy to end up with outdated data for developers not manually and regularly
running:
> meson subprojects update
Worse, it looks like even when updating the suproject, it fails to be properly
reconfigured. See: https://github.com/mesonbuild/meson/issues/12898
In our efforts to use Clang, now the nightly (in fact weekly) flatpak
is built with Clang too, not only GIMP but also the dependencies.
* However, not aalib. We welcome fixes regarding this cursed lib.
Additionally, updated some build options from some deps.
Resolves #7672
The Plasma wrapper gets the boundaries
of its filter area using gimp_item_mask_intersect().
If used on a selection, this gives the x and y
coordinates relative to the total canvas.
However, the GEGL operation will be drawn
relative to the selection - so this offsets
the effect within the selection rather than
filling the full space.
This patch fixes the problem by setting
the x and y position to 0 when there is an
active selection.
Layer effects that have not yet been committed are not
attached to the drawable. Trying to reorder them causes a
crash since they're required to be attached for undo/redo
purposes. This patch checks if they're committed beforehand,
and informs the user with a warning if it's not possible.
In GIMP 2.10 the number of segments was restricted to MAX_FANS.
That was later changed to 1024 without increasing MAX_FANS
which can crash the plug-in.
Also change the max displacement angle back to 90 degrees. The interval
0 to 90 degrees is enough to return all possible values.
Fixes #11108
...to fully use and return GeglColor.
Also, fix gimptext-parasite sending a
GimpRGB to create a GimpText instead of
the now required GeglColor, and update
documentation in gimp_checks_get_colors
to reference GeglColor instead of GimpRGB.
Resolves #11092
Same fix as in 2b3b2af2, since Blinds and Jigsaw
were the two plug-ins which used GimpAspectPreview
before the port to GimpProcedureDialog.
After the port to gimp_procedure_dialog_get_drawable_preview (),
the preview widget was being sized to the original drawable's dimensions
while the drawable was being redrawn with only its thumbnail dimensions.
This created a scrollbar that showed unallocated/overwritten buffers.
To fix, we update the preview size and boundaries whenever the preview
is changed. This removes the scrollbar and returns to 2.10 behavior.
In addition to the port, mnemonics were added to both file-pdf-save-multi
and file-pdf-save's GUI parameters.
Some runtime warnings were also fixed, such as trying to use a NULL string
parameters to make a file and trying to access properties from file-pdf-save
that don't exist in file-pdf-save-multi.
As shown in a video for issue 11087, some system themes
may add a white box-shadow on the side of unselected
tabs. This patch forces box-shadow to "none" to prevent
this.
Resolves #11057
Per Idriss Fekir's research, data from GBytes
should be written before the GByte is freed.
Perhaps due to luck, the data persisted on
Windows but was freed too early on Linux.
This patch should resolve the issue.
Resolves #11083
Per bootchk, changes in function calls to
palette_entry_get_color () and
gradient_segment_get_left_color () were
broken in Python scripts due to GelColor
being used post Color Space Invasion.
This patch fixes the calls and returns.
More descriptive name for script-fu-interface-dialog
Delete SF flag for gimp_ui_init already called: gimp_ui_init can be called often.
FUTURE: might be faster to call just gegl_init when mode is non-interactive.
After the color space invasion, the
Clip Warning filter no longer had color
areas for its shadow, highlights, and
bogus color properties. This patch ports
them to GeglColor so the widget can be
created correctly.
GimpRGB structs are also converted to
GeglColor in GimpPanedBox and two
plug-ins.
Otherwise we are not in a valid position anymore and further loading the XCF
fails. This may happen when updating a GEGL operation (in particular removing
effect properties, or renaming them).
The two threshold color pick buttons needed to have
a GeglColor parameter for their GimpPickerCallback
rather than a const GimpRGB.
This also fixes a crash caused by trying to free the GeglColor
rather than unreferencing it.
Without this, there is no easy way to quietly check for existence of a resource by name.
Needed when plugin authors can name defaults for resource args by name.
Add tests to script-fu/test/tests
Mainly fixing GimpRGB comments and
parameters that are unused (or in unused
functions).
GimpCircle and GimpGradientChooser
have color conversions ported to use
GeglColor exclusively.
Since commit 10b96b1025, we had buffer leaks as soon as we ran filters.
gimp_drawable_get_buffer_with_effects() was either creating a new buffer (when a
drawable had filters) or not. And calling code couldn't know which is which.
Code needs to be consistent. Either we return a new reference to take ownership
to, or not. So let's change to add a new reference to the drawable' buffers so
that it always returns a new reference to free.
So far, we did not consider that group layers could also be part of
a set of layers that have clipping set. This means that clipping groups
can be nested.
To support this we have completely rewritten the layer parser to detect
all clipping groups and mark them in a first pass. We now go through
the layers from the last (top) layer to the first (bottom) in this
first pass, because that makes it easier to detect the start/end
pairs of a clipping group.
In the second pass we handle the clipping groups first before adding
layers, except when a regular group is also the start of a clipping
group. In that case we need to handle the clipping after creating the
regular group, or we get an incorrect order.
Unsupported psd layers were dropped when loading psd images. This
causes problems when handling psd clipping groups, see issue #8453.
PSP also does not drop unsupported layers, so let's keep the layers
and accept that they will usually show up empty. This will help in
fixing clipping groups in a next step.
While we are at it, also remove the warnings that are only shown when
define CONVERSION_WARNINGS is TRUE (defaults to FALSE). We already
have a better way to show unsupported features, so at least for the
unsupported layers it is not needed anymore.
There are still some CONVERSION_WARNINGS warnings left over in the
blend modes conversion, which do not have a similar warning in our
unsupported features dialog.
* Makes the wording more concise and "first contributor-friendly"
+ Adds info about submitting patches
* Makes the explanation of use cases implicitly mandatory
+ Adds discuss info to facilitate the redation of use cases
This commit unites two scripts (.sh + .bat) in one .ps1. PS was choosed, since:
1) We don't need MSYS2 to distribute with Inno at first. Now, who wants to
just distribute GIMP can do it easier natively without a separate environ.
2) PS is actually pretty solid and have a good number of cmdlets, unlike the
ancient CMD, which barely supported more than 9 parameters in .bat files.
Consequently, some redundant variable checks have been removed from the .ISS.
Also, changes the name of the job and script for better consistency with the
upcoming MS Store job.
Though commit a14caafa8c was not wrong per-se, it's a bit too much. ;-)
Functions like g_ascii_dtostr() already exists for this very purpose of
converting a double/float to string in a locale-independent format.
CSS breaks when given a number with a comma as the radix
instead of a decimal. Depending on the system localization,
printf () may return numbers in this format when resizing
the font. This causes the theme to break unless font size is
set to 100.
To prevent this issue, we create the font size string manually
using integer division and mod operations.
- Replaces GimpRGB in Channel Dialog
with gdouble array, as was done in
channel_options_color_changed ()
- Replace %ld with G_GSIZE_FORMAT
in libgimp checkboard color message to
fix warning in Windows build
- Set file-gih documentation text as
translatable.
I think I may even have been the one who suggested to make this checkbox always
visible, but after more thought and usage, I just realize that this option is
not about showing the Welcome dialog, but about showing the Create tab of the
Welcome dialog. So I move it to the Create tab.
A very obvious case where the previous option location could have been
considered wrong is that we will always show the dialog (on the "Welcome" tab)
for updates, even if this checkbox had been unchecked. So if we left it as a
global option of the dialog, this could be considered a bug (the option is
disabled, but the dialog still opens on updates), whereas the new position and
shortened label make it clearer that this settings only apply to whether or not
we show specifically the Create dialog on start.
The splash image had a lot of empty space around it. From what I understood,
this is because we want to avoid it to be too big because it makes the dialog
overgrow the display size on small screens. But I don't think that was a very
good idea. We should find better ways to save space.
In d055564d, a pointer to the color profile
for NDE filter color properties was being
saved rather than the actual ICC profile.
This patch fixes the issue.
It also allows colors to load even if the
color profile is corrupted, with a warning.
Per bbb30eac, the GimpHSV object is replaced with
gegl_color_get_pixel () in "HSV double" color format.
GimpCellRendererColor still needs to be updated to
accept GeglColor rather than GimpRGB.
This commit fixes several issues with the plugin.
* Move plug-in to GimpProcedureDialog framework (see #9250)
* Use GimpPalette instead of (soon to be deprecated) Colormap (see #9477)
* Make plugin UI height, make it resizeable, update font sizes,
paddings, etc (see #10533)
Further improvements most likely are needed because plugin still uses
GimpRGB and GimpHSV (former is used by GimpCellRendererColor, latter for
H, S, and V values)
Resolves: https://gitlab.gnome.org/GNOME/gimp/-/issues/10533
Resolves: https://gitlab.gnome.org/GNOME/gimp/-/issues/10749
During the GimpProcedureConfigDialog port,
the "gimp-brush-pipe-parameters" parasite loading
code was unintentionally removed. This parasite
was used to restore the GIH parameters if it was
loaded as an image.
This patch restores that code on initial export as
GIH, then removes the parasite since the parameters
will be saved as part of the GimpProcedureConfig
going forward.
Allow (script-fu-use-v3) in script, or in SF Console.
Definitive description is in script-fu/docs/using-v3-binding.md
Makes SF interpret v3 of SF dialect.
- marshals single return value from PDB without wrapping in list
- marshals boolean return value from PDB as #t #f instead of integers
- marshals boolean to PDB from #t and #f or TRUE and FALSE
- marshals void return from PDB as () instead of (#t), but that is moot.
The version of SF dialect is distinct from the version of the PDB API.
Dialect v3 is opt-in: the initial dialect of all SF tools remains v2.
Commit also allows #t,#f for defaults of SF-TOGGLE instead of TRUE, FALSE
but that is an independent enhancement (but closely related.)
Affects interpreter state of the current process.
Not an attribute per se of a plugin.
While in this state, a plugin should not call PDB procedures
which are themselves v2 script plugins,
or a few utility scripts in script-fu-util.scm,
but that is rarely needed.
Does not remove symbols TRUE and FALSE from dialect.
A script can also call (script-fu-use-v2) to revert.
That is also discouraged but useful e.g. for testing.
Fixes #9883
There were menus that put their entries
directly in the tab menu rather than in a submenu.
This moves them to submenus to bring back GIMP 2.10 behavior.
Stray entries added by scripts are also moved to the right
submenu.
For improved readability, int or boolean types are used in place of
guchar for PDB parameters where the parameter description better fits
one or the other type.
This change affects `plug-in-alienmap2` and `plug-in-maze`.
Also, the problem with `guchar` parameters is that they currently cannot
be modified via `GimpProcedureConfig` due to the type not being
supported.
Call gimp_ui_init during query phase as well as run phase.
Maybe gimp_main() should do this.
Since space invasion from GimpRGB to GeglColor,
plugins that declare defaults for formal args of type GeglColor
need babl and gegl at plugin registration time.
The 'Docker' draft of GIMP was introduced in 09/04/2017 and then died ONE day
after, mostly because of "bad" timing (few years later we moved to GitLab CI).
Similar (in fact, even worse) than 'jhbuild' folder, update it to keep the
current development status is so hard that it is equal to do it from scratch.
So it is reasonable to delete it anyway.
Due to changes in our metadata handling API for plug-ins, the exif and
xmp metadata read from exr images was being overwritten by empty
metadata.
Fix this by following the new API and also add messages when loading
metadata fails. That way it will be easier to catch in the future if
metadata loading gets broken again.
When defining jpeg_exr a closing \0 is automatically added by the
compiler. So when we compare it using sizeof, we do not compare
6 bytes but 7. Since there won't be three 0's, this will fail.
Fix this by reducing the size by 1 and also update the comment to
make this clear and further to add that this was changed after
darktable 4.0.0.
gimp_metadata_set_from_exif has special code for handling old-style
GIMP exif parasite data, but didn't check for the more common case
of loading exif data from image formats that can't be handled by exiv2.
The exif data in these formats usually start with the TIFF endian
markers instead of "Exif", which caused a failure to read this
metadata for e.g. EXR images, see issue #10903.
We change this function to check for "Exif" at the start of the data,
in which case we assume it to be the old-style exif parasite and in
that case add extra metadata as was previously always done.
In all other cases, we do not add extra metadata.
These files are not deleted when the Unstable (GIMP 2.99) or Stable (GIMP 3)
version are installed because the root is different. So, they can be removed.
Resolves #11004
During the port to GimpProcedureDialog, the code
that assigned the current monitor object for
Windows and MacOS was accidentally removed.
This patch restores this code in the proper place.
At script create time, create a GimpRGB i.e. pixel from the declared name of default color.
At plugin procedure registration time, convert that pixel to GeglColor,
and use that color to declare the color arg using GeglParamSpecColor(default=color)
Fixes a faulty fix a few commits back where we lost the declared color name.
The proper dataflow is name->color->paramspec-with-default-color.
Extract methods related to color into new file.
So method names document what is being done.
So related code is together.
Ditto for resource.
No functional change.
Preparing for changes to reset/default and changes to representation of pixels
in lists of differing lengths rgb vs rgba.
Resolves #11003
GeglColor defaults to NULL rather than black like
GimpRGB. When selecting text with two or more colors
in the total selection, this causes NULL to be passed
to gimp_color_button_set_color () which throws an error.
This patch resolves the issue by setting GeglColor to
black if it's NULL before the call.
After the color space invasion, the
Semi-Flatten GUI was broken since it still
used GimpRGB as its color property.
This patch fixes this by porting to
GeglColor. The GimpRGB conversion was
also removed from the PDB interface
since the GeglColor comes directly from
GimpContext.
Resolves #10992.
GimpTextLayer's color attribute was
updated from GimpRGB to GeglColor,
but gimp-text-layer-set-color still passed
in GimpRGB. This patch updates the PDB
call to match the property type.
Fixes errors introduced by my prior commit c0ca0b74
1. SF is storing colors in GimpRGB, not GeglColor.
Storing using wrong pointer type seemed to work, but would not build on newer compilers.
2. spurious error message "CRITICAL....Two different plugins tried to register..."
Due to calling gimp_ui_init too early, in the class instance init.
When testing on Debian with acertain invalid PCX imagea that return
"Invalid number of bytes per line in PCX header", we get an error:
free(): double free detected in tcache 2
On Windows this doesn't cause an error, most likely due to a different
implementation of fclose.
The problem is that in case of errors fclose was called twice. Since
the file is opened outside the load_image functions, let's handle
closing also only outside that function.
In addition to that, change all g_message error notices to use
g_set_error instead, that way we always return a GError in case of an
error.
Further we also fix a possible error case of overwriting an existing
error by using g_prefix_error when the error is already set.
Resolves #10990.
Since the "mask-color" property is now a GeglColor,
we need to use gimp_prop_gegl_color_button_new ()
rather than gimp_prop_color_button_new () to
display it in the options panel.
Per @brunolopesdsilv, the About and Quit
dialogues had custom buttons which did
not receive the text-button CSS style.
This patch adds those back so the buttons
match the styling of the others in the
dialogue.
Previous pcx commit da217088d0 fixed
loading pcx images that had an off by one value for bytesperline.
However, it did not take into account that a value of 0 would be
invalid, causing a crash.
We fix this by adding a check for 0 and also failing in that case.
Since PDB now traffics in GeglColor instead of GimpRGB.
Change GimpParamSpecRGB to GeglParamSpecColor when declaring args to procedure.
Declared default is temporarily "black".
Change conversion of gvalue to scheme representation, now from GeglColor.
Incidental change to interpreter to init gegl early,
since now needed during registration phase.
Most of the C boiler-plate code is generated so that all you have to do is
implement the run() function with test code in it.
Also adding a README to make it all very clear and easy to add new tests.
With Python binding, it gets very easy to test new functions. I've been
wondering if we need C counterparts, but really since it's a GObject
Introspection binding, if a function succeeds there, it should also succeed in C
code.
For now, I'm testing a few of GimpPalette API. Not all of it yet. Also I test
both the direct C binding and PDB procedure since in some cases, one or the
other may not properly working. See #10885.
… accessed from Python.
Creating a new function gimp_value_array_get_color_array(). This should normally
not be needed (it isn't in C), but because of GObject Introspection limitation
and the fact that pygobject will automatically try to convert GValue to the
embedded value, we get this weird situation where the result is unusable in
Python for certain types. One of these types is GimpColorArray.
I suggest an annotation request to GObject Introspection:
https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/492
I think that with such annotation, followed as a second step by pygobject
support, correctly handling NULL terminated C arrays generically should be
feasible by bindings.
Resolves #10762.
Updates gimpdrawable-preview.c to use
gimp_drawable_get_buffer_with_effects (),
which includes any NDE Filters applied to
the layer in the preview.
The preview is also set to update when a
filter is applied non-destructively.
We were missing GimpColorArray support in one function. Note that the specific
example in Python in #10885 still doesn't work, but for a second reason:
gimp_value_array_index() returns a GValue which pygobject automatically tries to
transform to the contained data. And unfortunately it doesn't know about our
GimpColorArray type so we end with unusable boxed type generic data.
Since the Image Recovery dialog is blocking the main process (and requires an
answer to be done first), let's simply move down the Welcome dialog to after
this answer was given. This way, we simply won't have both dialogs in the same
time.
It was only used for the gimp-win-a64 job and was coming from MSYS2 repository
which already dropped it:
a98352b2ba
The first patch is still needed as the upstream fix is meant to appear in clang
18 according to bug report, yet our CI still uses clang 17.0.6. See:
https://github.com/llvm/llvm-project/issues/51286
Since the color space invasion, GimpRGB
properties do not create widgets anymore.
For Python plug-ins, we need to add
GeglColor properties as GObjects with
GeglColor value types as a workaround.
This patch does this and updates the
Foggify plug-in with the new datatype.
It is quite obvious that these were all kept around for the fun historical
background. And even though we can always get these back anytime through git
archeology, if these images disappear from our sight, we will just eventually
forget they even existed.
We now have a `gimp-data` repository for all data used and installed by GIMP. I
am not going to add these over there since it would go against the whole purpose
of splitting the source repository (we have too much data so we will want to
clone `gimp-data` as shallow so that it will only contain the necessary data to
install GIMP).
Yet I have created a page to reference and display all these original images
(and more! I spent quite some time researching old splashes and logos in our dev
log) for the pleasure of keeping the history of GIMP alive. It also reference
commit links for easy retrieval and further researches.
The only left images now are:
- gimp-logo.png and gimp-devel-logo.png: these are used in the About dialog or
API reference. Ideally they should be generated from the SVG source.
- gimp-splash.png: used as splash image, in the Welcome dialog and in the
Windows installer.
- wilber.png: only used in some Script-fu test scripts as far as I can see. This
should also be generated from the same source SVG as gimp-logo.png, or maybe
simply gimp-logo.png should be used instead.
Logos: https://gitlab.gnome.org/GNOME/gimp-data/-/blob/main/images/logo-log.md
Splashes: https://gitlab.gnome.org/GNOME/gimp-data/-/blob/main/images/splash-log.md
...with the Enter key. Combines the single image
and multi-image opening methods so that no matter
how you open recent images (single click, button, or
multi-select and pressing Enter), it opens all selected
images in the Welcome Dialog.
AFAIU the issue which it tried to fix only happens on custom builds and it looks
to me that it's just about multi-prefixes developer builds which were not
configured with -Drelocatable-bundle=no as they should.
When you compile GIMP yourself and intend to run it in a multi-prefix
environment, without ever relocating the build, like on Unix-like systems, then
disable this feature.
In any case, we should never do this kind of system file moving hacks in our
build system. The MSYS2 project even had to patch this out:
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1171#note_2022406
The indexed conversion code was originally written for very low-memory systems,
this makes the mapping it does quantized and noisy, for examples see issue
#5159 this commit removes quality/memory use trade-offs, modern machines can
take a 2-300mb temporary table allocation.
This is similar code to what I added for the Windows builds, except that here
it's because deps-debian-x64 will also end up feeding dev-docs job too.
Right now our tagged build of GIMP produces docs for unstable versions of babl
and GEGL.
Since !1171 we can use the CI scripts locally, but the initial implementation,
after some commits, revealed to be troublesome. So, now reworked to be simple.
As noted by Jehan, the way of defining the (many) GIMP versions can change.
So, let's take the GIMP version directly from the generated config.h file.
Also, changes the declaration of some variables to conform with "best pratices".
This list is referenced in the gimp-web-devel site, and my initial
implementation, in terms of ease to use, was a throwback.
Also, make the CI code more simple without changing the list file.
As noted in a comment on issue 10873,
choosing Selection for Fixed Gear throws
a TypeError. This is because with the change
from GimpRGB to GeglColor, we can no longer
directly access the red component with an index.
Instead, we need to call Gegl.Color.get_rgba() to get
that value, which is what this patch does.
Resolves #10882.
Before the color space invasion, INPUT_COLOR () returned
either a GimpRGB or NULL (if alpha == 0) that was used
directly in functions.
Now it's used to set a GeglColor in gegl_color_set_pixel (),
and calling that with a NULL color resulted in a Gegl-Critical.
This patch checks if INPUT_COLOR () returned NULL before
trying gegl_color_set_pixel () to prevent the issue.
The alternative solution would be to call:
> image_new_dialog_set (dialog, NULL, NULL);
This would have reset to default template. But it's still not exactly like the
"new image" action which defaults to the active image's size if there is an
opened image.
In order to avoid complicating the code further, as well as code duplication,
hence code divergence, let's call the "image-new" action, making sure that this
button will always behave exactly like the "File > New" menu item.
Then since we need to process the return value of this dialog (either re-showing
the welcome dialog in case of new image creation cancelation, or destroying the
hidden welcome dialog otherwise), I check for the singleton pointer and connect
the handlers to it.
Moreover I made the "response" signal of ImageNewDialog be handled as
G_CONNECT_AFTER otherwise we nearly never had the possibility to handle its
responses properly (because the base handler was doing it first, then often
destroying the dialog).
The rest of the time, we want to use HEAD of their main branches.
The last ctx update seem to have broken the CI build on Windows. While we'll
have to fix this, let's do this after we release GIMP.
Anyway we obviously don't want to use unstable code for actual point releases,
so it's a good thing that this made me think of adding such rules.
Use the same amount of dithering on R,G and B if they initially were all equal.
This allows us to keep achromatic gradients achromatic, while providing the
same amount of dither as before for colored gradients. Discrepancy uncovered in
issue #10756.
While the buffer used by Cairo may have a rowstride bigger than 3 * width, our
internally stored buffer has the exact size required for drawing the scale.
We were not properly duplicating the left and right colors when duplicating the
existing segments in gradient_editor_save_selection(). Therefore we ended up
freeing original GeglColor on exiting the GimpColorDialog.
Additionally to the reported crash, I add a few GeglColor freeing which were
leaked and some safeguard in gimp_gradient_get_flat_color() to ensure it always
returns a color (or raise a CRITICAL to be investigated easily).
Finally a few signals in GimpColorDialog had to be ensured disconnected when the
dialog is destroyed.
Our code expects that these GeglColor properties are always non-NULL in various
places, which may lead to crashes.
The property defaults should take care of this, and I am actually unsure why we
need to set it in the init(). Maybe the set_default() method for the GParamSpec
kicks in a bit late, while we have code syncing objects already running. I'm not
sure. It might need to be investigated later. But for now, let's simply make
sure we initialize the objects manually so that it's never NULL.
Issue #10756, without this grayscale pixels are affected by
the red part of the manipulation configuration, after this
change pixels with original saturation == 0.0 are only
changed by the master adjustment.
While doing this, I could find a lot of problems in the algorithm:
1. It looks like the original intent (from GUI and code) is that you set hue and
saturation but not really the intended lightness, rather its increase or
decrease, relatively to every pixel current lightness. I.e. that every pixel
will be set to the selected hue and saturation, and only the lightness will
change. The "lightness" field is therefore a relative value (pixel per
pixel). The first problem is that instead of lightness, we compute the
luminance, which is related but different and set this in the lightness
field.
2. The second issue is that we were using gimp_hsl_to_rgb() which after testing
(because its documentation doesn't give any TRC/space info at all) looks like
it computes a color from HSL to non-linear RGB of the same space. Yet we were
outputting to a linear RGB space. So we compute the wrong values. On the
other hand, because of the first problem, I realize (after testing) that it
makes our render closer to the intended render by chance (at least when the
TRC is sRGB's). It's still wrong, but if we were to change the output to
"R'G'B'A float" instead, the render would be much darker. In both cases, it's
wrong anyway.
I would not say that the 2 problems are canceling each others, but they are
making the final result somewhat OK.
3. Ideally we should be using babl to convert colors, and this is the best way
to actually implement the original filter intent. Unfortunately so far, doing
this is much slower (though I save a lot of time by moving out of the samples
loop and processing data in chunks, it's still slower than the current,
nearly instant, implementation).
4. Because of all previous implementation irregularities, the render is
different depending on the actual image space. I.e. that the exact same image
filtered through Colorize with the exact same operation parameters will
render differently. I would need to test further, and maybe it's normal since
HSL is also space-dependant (and that's where we work on in this operation),
but I'm wondering if the result should not be independant of the working
space.
5. I implemented our own prepare() method because the one in
GimpOperationPointFilter parent seems to allow other input or output models.
Even though in all my tests, it was always linear RGB (which is what we want
here), let's make sure by having a custom prepare() method explicitly setting
these. It's also the opportunity to create some babl fishes.
In any case, I'm leaving the code as-is for now, because it's how this operation
has been since forever (at least for as long as I was around) and I don't think
it's the right idea to change it on a whim.
This raises even more the concern of versionning GEGL operation, which we have
been discussing with pippin on IRC lately, because if ever we want to change
this one, now that operations are not just applied, but possibly
non-destructively recreated at load, we need to make sure that we recreate the
render expected at the time of creation of a XCF while allowing us to have the
filters improving when needed.
Resolves the main part of 10835. As nothing else can
be done in the GUI once all the filters are merged down
(and the GUI itself will be unavailable once closed until
a new filter is added), it makes sense to auto-close it.
gtk_widget_set_visible () was used rather than
gtk_popover_popdown () due to notes in the code about
buggy animations.
There is the possibility that users may want the GUI left
open to quickly undo the merge, so this should be
re-examined after feedback from the 2.99.18 release.
To reflect increased generality, its not just "coffee" but any gradient.
Delete "realistic looking": subjective and adds no content.
Better tooltips for the arguments.
Fix it by also enhancing, making the gradient an argument with a default
instead of a fixed choice of the gradient named "Coffee".
Instead of fixing by looking up the gradient ID in the body of the script.
Right now, I just transform any GeglColor return value into a RGB u8 triplet,
because that's also how we were supporting GimpRGB anyway, though it's seriously
limited.
Ideally we'd add some real concept of generic color abstraction in Script-fu
too, which could support any color model, space and precision.
Resolves #10848.
In cc62f2b0, we moved the filter property loading code
earlier in the process. However, the opacity, mode, and
region options for GimpFilterTool were not included in
this move, so they reset back to defaults each time.
This fixes that problem so settings are retained when
editing.
Resolves #10830
The supersample-max-depth parameter
of gimp-drawable-edit-gradient-fill
required a value between 1 and 9.
Previously this wasn't enforced, so several
scripts called it with a value of 0.
Now that it's enforced, those scripts were
broken. This fixes the calls in weave,
gradient-example, test-sphere, burn-in,
and coffee (although it has other issues)
It was a bit sad that we'd release GIMP 2.99.18 with no plug-in using
GeglColor argument yet, so at least with this, we'll have one as a demo
of what needs to be done.
- Make sure the led color is set at init().
- Unlike old GimpRGB code, values' colors must be set explicitly first.
- Make the Gimp object into a property (this one is not a problem right now, but
it's better this way).
- Don't assume the Gimp object is non-NULL. In current code, it is set to NULL.
The only consequence is that we don't use color management settings to draw
with Cairo. For this widget anyway, it feels unnecessary.
Altering the Warp tool's GEGL filter while it's being actively edited
causing a crash. More work will be needed to make these effects
work non-destructively - for now, we'll prevent users from raising or
lowering them from the NDE UI.
To simplify the logic, I created an `is_update` variable. This makes the code
much more understandable (and also simplify the redundant or over-complicated
imbricated `if` blocks).
The fix part is that the update check would have never happened for anyone
leaving the "Show Welcome Dialog" option checked, whereas we only want to bypass
the update check for new installations or updates.
Allows users to quickly configure themes and other
"controversial" options when first installed.
Also allows the welcome dialogue to appear on start,
depending on user preference.
… (u8), or CMYK is selected.
We always need a final NUL indicator in a GStrv. In these 2 cases, we might fill
all 6 first indexes, so we must have an array of size 7.
Since resources must now either belong to an image, or be tied to a file, or be
marked as internal, we must immediately save imported palettes, so that they are
tied to their file.
For the time being, only the same format as GimpRGB params is supported, which
means creating a color either as CSS strings or as RGBA list values, which means
that we can only input sRGB values right now in ScriptFu (even when calling
GeglColor-using API).
This is the second part to fix issue #10811.
Though I had already implemented passing GeglColor through the PDB, it was not
complete. In particular, the protocol was not able to pass GeglParamColor specs.
Fixes:
> LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor'
This is part of the fix to issue #10811, though it's not complete yet.
Clicking on the Save button threw an exception as the wrong class was
used to invoke the `set_alternative_button_order_from_array()` method.
Since `Gtk.Dialog.set_alternative_button_order_from_array()` is
deprecated and the GIMP functions with the same name suppress
deprecation warnings in the C code, we suppress the warning here as
well. The `warnings.catch_warnings()` function is not thread-safe
according to the Python documentation, which should not pose a problem
here.
Also, the file chooser dialog now allows specifying a new file instead
of overwriting an existing file.
The current values_cmp() method will segfault if an object contains a NULL
GeglColor value. I fixed it in commit c0477bcb0 in GEGL, but since the GEGL
release is already done, I add this special-casing on GIMP side.
To be removed when we release and depend on GEGL 0.4.50.
The crash was happening when activating the text tool and raised in a comment of
another report: https://gitlab.gnome.org/GNOME/gimp/-/issues/10813#note_2009702
When changing the selected color, we have no reason to redraw the Z preview.
This preview should only be redrawn if the allocation size changed, or if we
change the previewed model or the Z component.
As for the XY preview, it should only be redrawn if the Z value is changed (and
of course, similarly, if the allocation changed or if model or Z component
changed).
With "HSVA" and a few others, the function was not returning the right value (it
could not see it was encoding alpha channel.
I had fixed it on babl directly with commit a28309c yet I had forgotten to push
it! Let's just add some #ifdef and a comment.
No custom conversion code anymore. This also fixes some bugs in HSV when
I was wrongfully multiplying the hue by 360 when mixing babl and custom
code paths.
It's actually not enough to get proper colors for inner text tags. The
main color is correct, but color for subtext is currently not managed.
This must be fixed.
In particular, the Curves, Levels and Operation tools method implemented
are updated. Also GeglColor arguments in GEGL operations are not
transformed into GimpRGB arguments anymore in GIMP. GeglColor GParamSpec
stay GeglColor now.
We don't try anymore to convert early from a pickable color to another
format/space. Now we are able to get a GeglColor and move it around,
doing only last-second (when needed) conversions.
I'm a bit unsure about the GimpMyBrushCore which doesn't have much
indication on which color space we are working in, but the new code
should not be worse than the old one (if wrong, color-wise, it should be
the same wrong as before).
Until now we only had the case of the CMYK color selector using the
soft-proofing profile. Yet this is also interesting for other color
selectors, in particular to show out-of-gamut colors. Indeed if we
enable soft-proofing on the active image, it is interesting to show the
intersection of the current RGB/Grayscale space gamut with the
soft-proofing gamut.
Right now, this is only used in GimpColorSelect when showing colors in
LCh color space.
This is used for the gimp_color_is_perceptually_identical() function,
because the Euclidean distance in LCH is extremely limited, if not wrong
in many cases. Indeed LCH is not perfectly perceptually uniform, and for
this exact reason, the CIE defined the specific Delta E algorithms.
Later versions are also based on LCH values, so my intuition to use it
for distance was on a good start, yet these algorithms were refined a
few times to allow for corrections in perceptual uniformity
imperfections.
This was in particular needed to verify if a color is out of a CMYK
space gamut. The idea is to compare the distance of the RGB (or other)
and the CMYK version, since we cannot just check if the CMYK color is
out of the [0; 1] range (it never is). Instead if both colors are
perceptually identical, then we consider that the RGB color was inside
the CMYK space gamut.
The naive algorithm was giving any (or nearly) color as out-of-gamut.
Now using CIEDE2000, I get a much nicer results.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
Only the color dialog was getting simulation updates when the active
image changed, or when the simulation profile changed (while the active
image stayed the same). Now the Colors dockable also get updates.
Somehow, in some cases, the event box is not getting button events. I
had the case when creating new images (though it was working fine when
loading images!). I could not yet understand the issue looking at both
GIMP and GTK code and could not even reproduce by creating simple code
sample reproducing a similar pattern (an inactive button inside an event
box placed above the button and meant to catch click events).
This works as a workaround for the time being.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
I also changed a bit the new color serialization by adding a (color …)
symbol framing the contents, for cases where we don't have a specific
property name, e.g. for the color history list stored in colorrc, unlike
for GimpConfig GeglColor properties.
While doing this, I moved GeglColor property deserialization code into
gimp_scanner_parse_color() which is now able to recognize both older
(color-rgb|rgba|hsv|hsva with no color space) and newer serialization
formats ("color", color model agnostic and space aware).
Serializing palette colors is not possible right now as far too much
additional data are required, and anyway we likely wouldn't be able to
associate back the color to the right palette on deserialization,
removing any interest of keeping the index data anyway.
With that context in mind, let's just serialize palette data as basic
RGB within the palette's space.
- New libgimpcolor functions: gimp_color_parse_hex() and gimp_color_parse_name().
- GimpColorHexEntry is now space-invaded. Though recognized color names
and hexadecimal syntax are sRGB only (because CSS and SVG
specifications explicitly say that this syntax is for sRGB values), it
is possible to enter non-sRGB values with
gimp_color_hex_entry_set_color().
- GimpColorSelection is now space-invaded.
We historically have both the colormap and palette concept in core GIMP,
though they are actually kinda the same concept, except that with
"colormap" we work with an array of raw data and it's a lot less
color-aware. It is still much more efficient in some specific cases,
such as when converting the image (we can then convert the whole palette
as a single buffer, because the image palette is space-restricted
anyway), when storing undo data or when storing/loading in XCF.
But for all the rest, let's use gimp_image_get_colormap_palette() and
work with the GimpPalette API.
By default a palette can contain any mix of color models and space. These new
internal API add a concept of format/space restriction. For now this will only
be used for indexed images whose palette should only contain colors for the
specific palette format and space (at least as currently implemented in GIMP).
I still see some limitations in GimpGradient, and in particular, they are still
always stored as RGB in GGR files. It would be nice if we could store the actual
color format. This way, if someone chooses a gradient stop as Lab or CMYK color,
that's what the gradient file would keep track of. But also even storing the
space of a color (instead of storing/loading always in sRGB, even though this
may still work fine as we store unbounded double values). This might warrant for
a v2 of GGR file format.
This commit also fixes loading of SVG gradient which was apparently broken
regarding hexadecimal color parsing.
Finally I improve gegl_color_set_alpha() by adding an alpha channel when the
initial format had none.
The invasion extended to some core widgets too, in particular GimpColorPanel (a
subclass of GimpColorButton). There was quite a lot of code depending on these
widgets.
This includes improvements on the out-of-gamut colored corner being shown for
unbounded component types out of the [0; 1] range (with some small margin of
error to avoid e.g. a -0.0000001 value to show as out-of-gamut).
There are still improvements to be made on the color rendering. In particular,
it still draws as CAIRO_FORMAT_RGB24 cairo surface. We should probably move to
draw as CAIRO_FORMAT_RGBA128F eventually (more precision and even allowing to
draw unbounded colors with a possible option, instead of always clipping).
Also adding the libgimpwidgets API gimp_widget_get_render_space().
This one is kind of a huge deal, because the info returned by the color frame
was kind of messy (even though it improved lately, but space associated to color
data had to be kept in-sync by hand, which was bug-prone).
Now the color frame stores the data as a GeglColor, always aware of its space
and therefore able to do much nicer conversion. Also RGB and Grayscale options
now display the profile name of the color space (until now, we had only this for
the CMYK option using the proofing profile).
I still wish to get more options. Typically some people may want to get
RGB/Grayscale/CMYK values to other spaces (maybe sRGB, one of their favorite
profile as set in Preferences or just any random profile which they could load
from disk). Giving such ability to basically live-convert their pixel data to
various other color space would be very nice. We'll see if this will be
implemented for GIMP 3 or for after.
- New function gimp_cairo_set_source_color() which is meant to replace
gimp_cairo_set_source_rgb(a?)() eventually. This new function sets the Cairo
source color, using the target monitor's profile of the widget where the Cairo
surface is meant to be drawn on. It also uses the color management settings
(such as whether a custom profile was set, instead of using system profile, or
also simply whether color management was disabled at all). It doesn't
soft-proof the color yet.
- Padding and out-of-gamut colors drawing now use the new
gimp_cairo_set_source_color(). These don't need any soft-proofing anyway.
- Out-of-gamut color property in GimpColorConfig is now a GeglColor property.
We pass 2 GeglColor through the wire now. Since it is passed very early
(when sharing the configuration), I had some issues with initialization
order of GEGL, and in particular when calling gegl_init() before
gegl_config() inside _gimp_config(), I had a bunch of such criticals:
> Plugin script-fu: GLib-GObject: CRITICAL: Two different plugins tried to register 'GeglOpPlugIn-transform-core'
Anyway in the end, I store the passed colors as raw bytes and strings in
the GPConfig object, and re-construct the GeglColor last minute in
_gimp_config().
This fixes weird behavior when changing only the alpha value of a color, e.g. in
the channel color GUI. The before and after colors were considered the same. Now
they won't.
In particular, let's accept small margin of errors to determine that a value is
out of the [0; 1] range of its color space.
The specific use case is about a component at -0.000001 (or at 1.000001) which
will even just show as 0 (respectively 1) in the GUI and will be marked as
out-of-gamut. We want to avoid such thing to happen.
I also took the opportunity to get rid of a bit more GimpRGB code.
One of the big improvement in this commit is that text layers are now much
better at space accuracy. They were already space-aware, yet rendered as sRGB u8
only before being converted to the image's space. It means that text layers had
the following limitations:
* Any color out of sRGB gamut were trimmed.
* Precision was always 8-bit (even if the image was high-bit depth).
Now GimpTextLayout keeps track of its source space (for RGB and CMYK only, this
won't be as easy when we will support more backend, since Cairo has only RGB
support for image data) and the image TRC (in case it bypasses the color space's
TRB) and it draws within this gamut and space.
It means first that we are not limited to sRGB colors; we will draw text main
color in the full image gamut, with still 2 remaining limitations:
* Unbounded colors are impossible because Pango format (to color text) uses
hexadecimal (so even with half/float images, you can't draw out-of-gamut text
unfortunately).
* Main color precision is still 8-bit, yet a tiny bit better than before as we
at least follow TRC (so we avoid some of the precision loss when converting,
even though the bit-depth is still the biggest loss).
The outline color on the other hand is drawn through Cairo API entirely, in
float. This means that the outline color will now be without any precision loss.
Note that this depends on CAIRO_FORMAT_RGBA128F which is only available since
Cairo 1.17.2 which is not in Debian bookworm (our current baseline for GIMP
3.0). It means that the old precision will still happen with older Cairo
version, as determined by #if code at compilation.
I moved the function to select a valid contextual RGBA format as a core API
gimp_context_get_rgba_format(). This same API is now used in context actions, as
well as in the GimpDeviceStatus widget.
The latter now shows per-device fg/bg colors relatively to the active image's
format. The tooltip will also display contextual information (i.e. either the
image's name whose space is used, or sRGB).
Of course, this all updates when switching images by connecting to the
image-changed signal.
In space invasion world, we want color-related code to be contextual. When we
say "Increase/Decrease the red/green/blue channel by X%", it would actually mean
something different if you are working on a sRGB space or a wider gamut space.
Furthermore, it means also something different if you work on linear/perceptual,
overriding the space's actual TRC.
This is why this new code takes the active image into account and uses this as a
base for the space and TRC you are working on. In case you have no active image,
it defaults to the current GeglColor space (though really this case should not
matter too much). In case your image is not RGB to begin with, it uses sRGB
space.
Some old config files will contain (color-rgb) contents. Also some data, such as
historical tool presets (.gtp files) will have such values in their
(tool-options).
- app: gimp_context_get_(foreground|background)() are now returning a GeglColor.
- libgimp: PDB functions named similarly in libgimp are returning a newly
allocated GeglColor too.
- A few other PDB functions (the ones using these functions) were updated and
their signature changed to use GeglColor too, when relevant. Plug-ins which
use any of the changed libgimp functions were fixed.
- GimpContext: signals "(foreground|background)-changed" are now passing a
GeglColor.
- libgimpconfig: new macro GIMP_CONFIG_PROP_COLOR using gegl_param_spec_color().
- GimpContext: properties "foreground" and "background" are now GeglParamColor
properties.
- app: All code interacting with GimpContext objects were updated to receive a
GeglColor (that they may still convert, or no, to GimpRGB for now).
- app: gimp_prop_gegl_color_button_new() was added as an alternative to
gimp_prop_color_button_new() when the property is a GeglParamColor. Eventually
the former should replace completely the latter.
- libgimpwidgets: gimp_prop_color_area_new() now works on GeglParamColor
properties only.
- libgimp: gimp_procedure_dialog_get_widget() will generate a GimpColorArea for
GeglTypeParamColor arguments.
Also the color is internally stored as GeglColor, though there are still get
APIs and signals using GimpRGB.
The equivalent PDB functions are also changed to use GeglColor, same as app/
functions.
… gimp_color_is_perceptually_identical().
gimp_color_is_perceptually_identical() is meant to replace gimp_rgb_distance()
which is anyway always used to decide whether 2 colors can be considered equal.
So rather than having a distance algorithm which we won't be able to change
later on (if people start relying on specific values), let's just give the
answer directly on what's a same color (perceptually) or not.
Also now the distance is computed through the intermediate color space LCh which
seems to be one of the most perceptually uniform space, therefore a good choice
for such an algorithm (comparing distances on a non-perceptual uniform space
doesn't make very much sense, since a same distance may be perceived differently
in different subspaces).
This is a first commit to really getting rid of GimpRGB within core and
PDB/plug-in code. This will make color conversion reliability a lot better as
GeglColor will handle conversions for us. The goal is that we should keep origin
color space (for instance when picking colors in a GimpPickable, or when storing
in the FG/BG colors or in paletters) until the last second and convert at use
only.
It's still very much work-in-progress.
These 2 functions were removed in commit 89c359ce. They were in fact used and
clearly this historical API seems interesting (though we can likely do the same
thing using the drawable GeglBuffer, but this way is much easier).
This is now reimplemented using GeglColor instead of raw data.
Eventually this is meant to fully replace GimpRGB (as well as GimpHSV, GimpHSL
and GimpCMYK), both in libgimp and in core code, as part of both the space
invasion and the API rework. For this first commit, I keep this new object side
by side to GimpRGB.
gimp_drawable_filter_apply () is affected
by the active selection. This causes display
glitches when merging all filters or
undoing a merge while an active selection
is on the image.
This patch saves the current selection,
clears it, merges/unmerges the filters,
then reapplies the selection to avoid the
problem. In the future, this should be
re-examined (when filter masks can be
edited).
Resolves #10802.
Since the GimpProcedureDialog port, the Windows version
of the Screenshot plug-in has been missing the
"Screenshot Delay" option. This is because Windows did not
have the SCREENSHOT_CAN_DELAY_WINDOW_SHOT enum
set. Adding that back in restores the option.
Here, the instructions was hard to find in the middle of maintainer stuff.
Also, be able to build GIMP without dev-oriented distros is something very
desirable, and the gimp-web-devel is the suited place fot it.
Resolves #10736.
By default, any filter added with a drawable with
gimp_drawable_filter_new () will be added on top
of the filter stack. Now that we have NDE effects,
there can be multiple live filters when drawing.
The Warp tool applies a GEGL operation as well,
and now it draws on top of any existing effect.
This patch adds code to move the Warp's filter
below any other NDE effects so it operates on
the raw pixels only.
Note that a longer term solution might be to have
a separate stack for tool-based GEGL operations,
but that would be a post 3.0 discussion.
- The icon itself was changed to a "search" icon. Though it kinda made sense to
keep the "link" reference when I first implemented this, as a reference to how
we used to link items (whereas now we select them together), in the grand
scheme of things, it's not such a good idea and many won't likely understand.
But everyone will understand a "search" button. :-)
- It's now next to the label displaying the number of selected items, in the
item tree view header. This makes much more sense there. Also it makes the
long list of bottom buttons slighly shorter.
- Finally I make this feature accessible to the channels and paths, by actually
moving it out of GimpLayerTreeView and into GimpItemTreeView.
Certain filters like Supernova have a
random seed property. According to the
specifications it's an unsigned int, so we
can save and load it with existing
functions.
Aaaargh! I think this was the main issue which would explain why the problem was
mostly happening on the packaging job. In this job, we were still consistently
calling `pacman --noconfirm -Suy` (i.e.g "Synchronizing package databases")
which we had stopped to do for the CI builds as that was highly increasing
chances of locking pacman's process.
This is the command suggest by MSYS2 developers here:
https://github.com/msys2/MSYS2-packages/issues/4340#issuecomment-1887695290
They also say to run it outside the MSYS2 environment, which is why it's in the
CI rules, not in the shell script.
Honestly at this point, it feels like we are just stacking weird workaround to
get it to fail not too often. ;-(
Fixing a case where the script continued after a failed `ninja`. After further
testing on how `set -e` works, it looks like a toplevel `false && true` command
will fail the script (which is what we want), but it won't when inside an `if`
block!
Breaking it down into 2 separate calls fail the script correctly though. So
let's do this.
MSYS2 pacman gets randomly stuck on Windows/Aarch64. The actual issue is still
being investigated by upstream projects, though anyway it's bad for us right
now, to the point that there are discussions to remove Aarch64 support from the
Windows installer (whereas it just got added recently!) in #10729.
This is an attempt to a workaround. Instead of getting stuck forever and waiting
until the whole job times out (per Gitlab CI settings), I time-out (after 3
minutes) the pacman command within our script and try again, up to 2 more times.
Hopefully one of the calls would succeed.
I also send a SIGKILL through the timeout (though I have no idea how signals
translate to Windows processes) and run again taskkill after this, which may
seem overkill. Interestingly I get output for both, which seems to indicate that
the kill succeeds in both cases (because of several processes?).
Anyway clearly it's a bit of random code not completely understood, but the
inability to test this all locally clearly doesn't help so it's good enough for
the time being.
See: https://github.com/msys2/MSYS2-packages/issues/4340
Resolves #10769.
Flattening an image or merging down layers caused
us to lose NDE filters on undo, as we flattened with
gimp_gegl_create_flatten_node () which didn't create
an Undo/Redo object.
To fix this, we merge the filters down beforehand with
our API so that they will be restored when undoing.
Resolves #10768.
During NDE development, the Show/Hide All
function name was changed. This was not fixed
in one location where we blocked it during popup
creation, so the signal was running on dead objects.
This patch fixes this. It also fixes a few formatting
errors made during NDE development.
Two shell commands got merged as one line. This seems to work fine on
hmartinez82's runner, unlike on our new runners. Anyway it is likely good
practice to clearly separate the commands.
Fixing:
$ if ($stuck -eq "True") { Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck" Write-Output "Cleaned previous stuck pacman" }
Remove-Item : A positional parameter cannot be found that accepts argument 'Write-Output'.
At line:279 char:26
+ ... q "True") { Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Remove-Item], ParameterBindingException
+ FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand
Resolves #10766.
Currently, GIMP does not support applying or editing
filters when the layer is pixel locked. This patch
prevents users from attempting to edit filters via the
NDE popover UI, and notifies them of why.
If any NDE filter is hidden when merged, the entire layer
is hidden. This patch changes the behavior so that the
invisible filter is removed instead of committed when
merged down.
Without this, when creating the new config folder for the first time
(update from 2.10 to 2.99/3.0), if say "Legacy" icon theme was set, it
would not show on the first run, though it would show on the second run.
Now it shows directly on the first run.
After ab626e79, Script-Fu v3 now has the
SF-OPTION parameter again. This patch
ports a few scripts that use it or were
not otherwise covered by other merge
requests.
Note that further improvements are
necessary to allow these to work on
multiple layers simultaneously.
For version 3 scripts, using script-fu-register-filter
Widgets for SF-OPTION and SF-DIRNAME
Fixes #9992
Test case is Sphere v3.
Note that SF-VECTORS is still not supported,
until there is a VectorsChooser widget in libgimp.
A step towards deprecating old-style scripts using script-fu-register,
and deleting script-fu-interface, the duplicate dialog for SF.
But we still need to change or replace script-fu-register (for non-filter plugins)
to use GimpProcedureDialog.
Some GIMP-custom GEGL operations do not use GimpConfig to
store their properties (for instance, Threshold).
Previously, we weren't copying over their values when editing an
NDE filter.
This patch adds code to copy over the Gegl properties if there is
not a GimpConfig object attached to the filter.
In particular in a cross-compilation environment where you don't have an exe
wrapper or cross-host run ability, you still want to be able to configure GIMP.
It is also possible to install lua scripts anyway with -Dlua=enabled, bypassing
ability to test lua-lgi presence (a warning will be outputted at configuration
time, but no error).
While this is the job of `set -e`, putting parts of the script in shell
functions hid error returns in the build-deps-msys2 script.
Cf. #10729.
For the build-gimp-crossroad script, let's just add `set -e`.
Cf. #10725.
I believe there is a real use case for darker or lighter themes, but this
particular theme is not particularly maintained and has no light variant (or to
be accurate: the light variant is just a link to the "Default" one). If someone
is interested in such themes, we'll welcome contributions to revive a new theme
which should have at the very least both a light and dark version, and we could
name it "Contrast" (rather than "Darker" which focuses on a dark variant only).
I think it's better to do it this way rather than releasing with a half-done
job.
The Compact theme code is nearly the same as the Default one, apart from setting
palette icon size to small (which is already something done by the "Override
icon sizes" setting in Preferences), setting font-size to small (which can be
independently set by our "Font Scaling" setting) and setting 3 paddings.
Rather than having this separate theme, it feels like just moving the padding
changes as part of the icon size makes sense. In particular since, when setting
icons to "Small" right now, the default padding really feels a bit huge and out
of place. So all-in-one seems a better choice.
At first, I wanted to set a padding proportional to the icon size, but it didn't
work well. For now, I'll just choose padding sizes manually.
If you run the GEGL Operation tool without choosing
a filter, it leaves a "gegl:nop" layer effect behind.
This is not useful, so we check and set such filters as
destructive to get rid of when applying an effect.
This was provoking a CRITICAL in #9712, in the GimpFgBgEditor which was tracking
the active image, but even before this, I experienced a crash in
GimpLayerTreeView code with the same steps.
The problem is that in some cases, the image switch happens once the currently
active image is already disposed. In particular we had the case in multi-window
mode where closing a window would free a GimpImage yet without necessarily
setting another image as active, since it depends on window focus in MWM (and
the other image windows may not gain focus immediately; this depends on the
window management logic).
Therefore we had various handlers in Gimp*TreeView (or GimpFgBgEditor and
possibly other places) code which tried to disconnect or work on now freed
pointers. To handle such case, let's connect to image finalization and set the
context to NULL image.
When working on #9712, I encountered this crash first before the main issue
(with the same reproduction steps as listed by Wormnest): reason may not be set
by the method. It's better to always explicitly set this variable to NULL first.
The current GTK algorithm for finding an icon seems to be:
main icon theme in choosen style > fallback icon theme in choosen style >
main icon theme in another style > fallback icon theme in another style
Where "style" is either color or symbolic variant of a given icon. The problem
is therefore if say your prefered style is "Symbolic" and you choose a
Color-only icon theme. In such a configuration, all icons which are also
available in the system theme with a symbolic variant will be used from the
system theme (even when they are actually available in the chosen icon theme
too, yet in a color variant) and you get a weird mix of part of the icons as
symbolic from system theme and another part as color from the chosen theme.
In order to avoid this weird situation, we only set -gtk-icon-style CSS value to
the prefer-symbolic-icons property if the chosen icon theme has both style
variants. Otherwise we force the only variant of the chosen icon theme.
The icon "gimp-wilber" is used to determine whether an icon theme has both
variants, which should be documented in the developer website for icon theme
makers.
The -Dlua option has 3 cases:
1. disabled: lua plug-ins aren't installed at all.
2. auto: lua plug-ins are only installed if we find a lua installation
with access to the 'lgi' module. We now do the actual test at configuration
(not only lua existence test, but also lua-lgi).
3. enabled: lua plug-ins are always installed but if no lua installation with
'lgi' module is found, a warning is displayed at end of configuration step.
Add tests of context stack ops.
Add test of paint methods.
Test convert to all precisions.
Test paint dynamics.
Test PDB as database.
Test PDBProcedure methods.
Test display methods.
Test drawable operations.
While the script is made aware of multiple selected layers,
it still only works on the top selected layer.
Mnemonics were also added to the GUI fields,
and an unused "type" parameter was removed.
The list contains, in addition to the GIMP deps, all babl and GEGL deps.
So, let's use it.
Also, nothing new under the sun. We already use a unique list on the
Windows build instruction page (for stable branch) and do the same to
Debian image job.
The merged icon theme is simply named "Default" and contains a color and
symbolic variant for all icons. While in 2.10, it made sense to have both icon
themes because a theme had no concept of a "symbolic" variant back then, icon
themes in 3.0 have this concept and we support this in GIMP through the "Use
symbolic icons if available" option in Preferences.
Until now, it was confusing to have both themes + this option, even more as you
could use the Color icons with the "Use symbolic icons" option, which meant that
if some icons were missing, you could end up with a mix of color and symbolic
icons (and oppositely using the Symbolic theme with the option unchecked).
The new state is much simpler and less confusing. Just 1 icon theme with both
color and symbolic variants (the latter being used by default).
Note that the identical meson.build in each size subfolder is still mandatory
because of the inability of meson (still!) to generate files with
custom_target() in a subfolder as output.
We were skipping tests when there is no display, which is always the
case on Windows. However, these tests always showed as succeeded.
Unless you looked at the test log, you wouldn't noticed that most of
the tests weren't actually performed.
Exit these tests with the value GIMP_EXIT_TEST_SKIPPED instead of
EXIT_SUCCESS.
You are not supposed to use g_assert in tests because g_assert can be
disabled using -DG_DISABLE_ASSERT, which makes tests fail.
Instead let's use the recommended replacement g_assert_true. At this
time we are not bothering using more specific g_assert_* functions,
since there are plans to change our test suite.
gimp_config_writer_printf () is used to print out a gsize variable, data_length.
gsize's actual size varies depending on platform, so using the format "%lu" throws
a warning on some platforms and switching to "%llu" throws a warning on others.
@Wormnest suggested ("%" G_GSIZE_FORMAT) as a universal format to resolve
this warning.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
Chooser return GDK_EVENT_STOP so parent manager does not also popup second menu.
Specifically, return the result of the call to gimp_editor_popup_menu_at_pointer.
When a menu does pop up (for a dockable), that result is GDK_EVENT_STOP
and the event does not propagate to the parent widget.
Added a comment about why we ignore the result of a call
to gimp_editor_popup_menu_at_pointer in another place,
since it is not obvious why that call is different.
All other current behavior retained.
Other current behavior might be separate issue:
LMB or RMB outside any item, or in the current selected item,
in the chooser that popups from the toolbox,
should probably close the popup chooser, or give an audible alert,
because it does nothing.
Note that a chooser is also used in a remote dialog for a plugin,
and it closes a different way, choosing an OK button.
MINGW64
- uses 0x601 as value for _WIN32_WINNT. No need for us to define
it to that value or even lower values in some places.
This also gets rid of: warning: "_WIN32_WINNT" redefined
- has 0x0502 for WINVER, so get rid of us setting it to 0x0500 in
gimp-app-test-utils.h. It also seems that the need to use G_OS_WIN32
has disappeared here.
- DIRECTINPUT_VERSION is 0x0800, no need for us to set it to that value.
- AI_ADDRCONFIG was apparently missing from the MINGW headers in the
past, but not anymore.
The list of objects where the config object is a dedicated custom class (instead
of a runtime-registered class) is well known. These are the operations
registered inside gimp_operations_init().
The list inside gimp_gegl_procedure_execute_async() which the previous commit
was updating was not right: it was still missing "gimp:hue-saturation" and
"gimp:threshold" should not have been on the list (this was generating a
CRITICAL when trying to get the "config" property on this object).
Instead let's add some init/exit() functions in gimp-operation-config API to
distinguish the operations with custom config (registered during init) with all
the others. Then we add gimp_operation_config_is_custom() which can be used
everywhere where we want to verify if an operation is using a custom-made config
object or a generated class just mirroring the operation properties.
This way, we should not get out-of-sync anymore.
Adds gimp:color-balance to the list of
GIMP-specific GEGL operations we
retrieve the GimpConfig settings from.
Also prevents trying to set a GEGL
property when editing if it couldn't be
converted properly (e.g. GimpConfig)
Now that we save GEGL operation arguments ourselves (instead of relying on
GEGL-generated XML), we can serialize and deserialize GimpConfig arguments which
are used in various operations implemented within GIMP core code.
Additionally:
- Also support saving and loading all enum types.
- PROP_EFFECT_ARGUMENT renamed to PROP_FILTER_ARGUMENT for consistent naming.
- A bit more accurate handling on save and load errors with dedicated messages
to various issues.
- Use PROP_FLOAT_OPACITY instead of the obsolete 8-bit PROP_OPACITY (actually
32-bit but stored as 0-255 int).
- Fix a leaking string.
*It's possible to have one layer selected but edit the filter of another layer.
The FilterTool code was updated to use the filter's drawable if editing.
*Prevents editing if multiple layers are selected.
This is a current limitation of the filter tool itself, but it was causing issues with NDE.
*If an XCF with a filter from a third-party plug-in is loaded, the filter won't be
created if the user doesn't have it installed.
Note that GEGL still throws a lot of warnings about missing properties - not sure how to resolve that.
*Refresh drawable when finished editing a filter to fix issue with lingering preview splits
*Fix issue with loading more than one filter after XCF format changes
- Do not leak allocated return value of gegl_node_to_xml_full().
- When merging layer effects, use gimp_drawable_filter_commit(), making
sure we use the exact same code path as when applying layer effects
destructively from the start. This also ensures that filters are
properly removed from the filter stack (unlike
gimp_drawable_merge_filter()), which was the reason why the rendering
was wrong (hence getting the buffer without effects first, then
reapplying it after was only a workaround to an actual bug).
- When removing a filter, verify the object still exists before doing
anything with it. If this was the last reference, we don't want to
call functions on this object. In gimp_drawable_filter_commit(), we
set up a weak pointer. In gimp_drawable_filter_remove_filter() itself,
we save the pointer to the filter's drawable before actual removal (as
we don't want to dereference a freed object later on).
- export_merge_layer_effects() should merge filters recursively through
layer groups.
- clean up the XCF code:
* No need to wrap the effect pointers list into 2 zero offset. Only
have one zero offset to indicate the list end.
* Add the layer effect mask in the effect structure (not in the layer
structure), similar as for layer masks.
* Effect name and icon made as main data in the structure, not as
properties.
This patch implements an initial form of
non-destructive editing. Filters now stay active
instead of being immediately merged down.
A new column is added to the layer tree view, which
can be clicked to show a pop-over menu.
Filters can currently be hidden/shown, edited, reordered,
deleted, and merged down from this pop-over menu.
Currently, this works on layers and layer selections only.
Plenty of room for improvement!
Use g_signal_connect_object to ensure object passed to handler
is not destroyed in the middle of the handler by knock-on signal handling.
Note there are comments about this in gimpcontainertreeview.c line 1592.
And similar code i.e. calls to gimp_container_view_get_container
that seem to be intended to solve but might actually also be susceptible.
Those calls in icon view throw CRITICALs during this issue.
But testing of the tree view (a list instead of a grid)
doesn't seem to crash, so leave well enough alone.
As suggested by Jehan, the manifest will be configured by meson.
Of course, for CI compliance, this pushes the job to a further stage:
'packaging', which is what Flatpak is about, after all.
The distribution job name has also been changed, because when Store job
is merged, this will be the new nomenclature of the distribution jobs,
which was not changed since !1171 by lack of time.
Per @lukaso, the "rightwards triangle arrowhead" character
doesn't render on MacOS. This patch uses a different character
for MacOS only until a standard character can be decided on.
There is no point in keeping .patches in our source since we aren't applying
them and there are "backup" MRs in GTK: GNOME/gtk!3275 and GNOME/gtk!4432.
Resolves #10657.
d120e592 fixed a crash when pasting into an empty image.
However, it created a new issue when pasting into a layer mask.
It caused a later call to gimp_drawable_convert_type () to fail, as
the pasted image would not need to be converted if the image's
settings were used rather than the drawable.
This patch fixes both issues by checking if the selection/image is empty,
and assigned the base type and precision values from either the selection
or the image accordingly.
Resolves #10651
The "Remove All Guides" script calls
gimp-image-find-next-guide, which per
its description can take in 0. However,
the parameter sets 1 as the minimum
value.
This patch fixes the range so that it can
accept 0, which enables the Remove All
Guides script to work again.
It also updates the script to the new
multi-layer aware API.
- Drops HACKING file (it is outdated and we have the "same thing",
updated, in the devel site), but moved PDB content to the README
* Update various links now to the devel site
+ Added 'TODOs' to avoid confusion from titles with empty content
and removed some that are already implemented
Now, the script reads the major.minor version automatically from the main
meson.build file, reducing maintenance work, which is already especially
high regarding flatpak because of the natural hashes updates etc.
Also, a small organization made to make the code more humanly readable.
As consensus on Windows contributors, it is more useful for most users
the generation of the desktop shortcut by default.
Now, users who don't want it should uncheck the option in custom install
or manually delete the shortcut after a full install.
It was not possible anymore for a plug-in to add a menu item to the
local Layers, Classes and Paths dialogs using <Layers>, <Classes> and
<Vectors> at the start of the menu path.
For the first two this was due to an extra length parameter and the
drawables now being inside a GimpObjectArray. To fix that we check
inside the object array for the correct type names.
I'm not sure if Vectors ever worked, but testing shows it only adds
runmode and image parameters. To fix that we do the same as for
ColorMap.
The 'jhbuild' build of GIMP (Windows only) was added in 2013 and then maintained
by only one contributor (it even offered unnoficial nightly builds) until 2017,
when it never received a new jhbuild-specific commit again.
After so long, update it to keep up with current development status is quite hard,
so it is reasonable to remove this already dead version of GIMP.
Resolves #10643.
Prevent gimp_modifiers_editor_show_settings () from being called
when the user clicks the Modifier Reset button in Preferences if
there is no device connected to GIMP.
For certain small selections, the pattern preview can't be loaded.
Since e1e30c6f assumes the pattern loads, this could cause a
crash if a dialogue with the preview is visible.
This patch checks if the scaled pattern was loaded before using
it, and otherwise uses the default pattern.
* Fixes an ARM .patch that stop to working after !1171, causing job fail
* Changes the logic of system upgrade (pacman -Syyuu) to be less redundant
This also improves consistency with the Debian jobs
Fixes #10605.
Export to xmc when image width or height is 256 pixels
causes a crash. Add equality check to an assert to stop
the plug-in from crashing.
Resolves #10530.
In GTK2, setting a window's scrollbar policy to GTK_POLICY_NEVER
hid the scrollbars. In GTK3, this also makes the window automatically
resize to fit the contents. Since ImageMap displays the full drawable
with no scaling, this caused the plug-in window to be very large for large
layers.
GTK_POLICY_EXTERNAL in GTK3 works the same as the GTK2 version of
GTK_POLICY_NEVER, so using it instead fixes the problem.
The default width and height magic numbers were also replaced with
constants.
- file-psd, sig[4] and block_len variables are initialized to stop uninitialized warnings
- file-xpm, g_file_peek_path () is cast to (char *) to stop "discarded const" warnings
- gimpconfig-serialized.c, %llu is used instead of %lu to stop overflow warning
If a system theme sets the background-image property for stacks,
it recolors the main canvas when empty. It also adds a border to
the toolbox Wilber area.
Additionally, the Credits page of the GtkAboutDialog has odd colors
due to general viewport grid styles overriding the GTK default.
This patch fixes these problems, and adds a custom CSS class to
the GimpAboutDialog for current and future work.
The previous commit did not fully convert the title/status bar
format string to be UTF8-clean, due to a misunderstanding
of the logic behind the symbol used to indicate an image
was dirty.
Rather than always grabbing the 2nd character in the format
string, this patch now grabs the next character in the format
string after the %D, %N, %C, and %E commands.
During the API port, the Map Object
plugin had some parameters added and
others changed to GimpChoice strings.
This broke the Spinning Globe filter which
called on the map-object plugin.
This patch updates the procedure call and
fixes ranges in the map-object plugin so
spinning-globe works again,
but larger scope warnings persist.
No functional change.
I did this while chasing #10590 and #10591
The refactoring moves replicated code into functions.
So readers can understand better without having to compare sections
of replicated code.
The comments also highlight issue #10590.
Use g_connect_signal_swapped for "resource-set" signal from Resource Choosers,
to match the signal handler expecting "callback data" in the first arg.
Otherwise the first arg is the object emitting the signal.
Resolves #10611.
In GTK3, GtkRadioButtons are set using the "active" property
rather than selected, so the callback needed to check the
GTK_STATE_FLAG_ACTIVE flag instead of GTK_STATE_FLAG_SELECTED
when changing grid types.
The code was also reformatted to match current coding style.
- To set color values in the 0-255 range we now have to use set_uchar.
- Because setting a default color is not working, the color in config
could be None, which if the color wasn't changed caused a CRITICAL.
Let's check for None and if that is the case then manually set our
default color.
When cancelling foggify we get the following error:
AttributeError: 'GimpProcedureConfig-python-fu-foggify' object has no
attribute 'end_run'
The end_run function was removed a while ago, so just remove this line.
The grid state was not correctly updated when changed from within the
grid settings dialog.
Instead of using g_simple_action_set_enabled we need to use
g_simple_action_set_state, since we don't want to change whether the
action is enabled or disabled, but the checked/unchecked state.
The current code assumes that one letter is one byte long.
This caused issues when using non-ASCII UTF8 characters in
the title and statusbar format strings.
This patch replaces the loop logic with g_utf8_next_char () and g_utf8_get_char ()
to get the next letter no matter how many bytes it takes up.
As reported in issue 10604, if the Align Tool is set to align relative
to a reference object and 'use extents of layer contents' is enabled,
clicking on a path causes a CRITICAL.
This is due to gimp_pickable_auto_shrink () being called, when GimpVectors
are not GimpPickables. A datatype check is added before calling the function
to prevent the issue.
When opening images like DDS or EPS that have an options dialog,
we either get a crash, or criticals.
The critical made clear that there is a problem dereferencing:
(gimp-2.99.exe:9900): GLib-CRITICAL **: 14:52:58.831:
g_atomic_ref_count_dec: assertion 'old_value > 0' failed
Looking at gimp_file_dialog_progress_get_window_id we see that the
handle doesn't get an extra reference, while in other similar places
the handle is duplicated.
Using g_bytes_ref on the handle fixes the criticals for me.
Due to GObject Introspection we can't have the last part of an
identifier start with a digit, since that part will be used in Python
as the identifier, and Python doesn't allow that to start with a digit.
e.g. GIMP_ROTATE_90 would be used in Python as
image.rotate(Gimp.RotationType.90)
To fix this we add DEGREES in front of the number, without a '_',
even though that looks ugly.
With the sample image that contains the XMP namespace Item with the
correct url included, it is not returning the url when we ask for it.
This seems to be an exiv2 issue, but needs more research.
What GIMP doesn't do, is report that the namespace url we were looking
for wasn't found, and make sure that this doesn't block us from
handling all XMP tags.
To improve this on our end, we check if there was an error getting the
url, and if yes:
- We generate a warning message
- We create a dummy namespace url, with a special check for the missing
Item namespace to give it the correct known namespace url.
Previously, the console's font color was hardcoded to #006000.
This did not stand out well on darker theme.
This patch pulls the widget's foreground color from GtkStyleContext
to ensure it contrasts sufficiently with the console background color.
- Fix "no icons" errors generating loaders.cache with .cmd (CI-Cross).
! This is a sub-optimal fix, but it's better than a useless build.
- Fix "no interpreter" errors generating .interp with Meson (CI-Native)
and generating .interp and copying .typelib with .cmd (Local-Native).
! This is a sub-optimal fix to Local-Native, but plug-ins will work.
- Fix "no iso" error copying iso_639.xml with Meson (Local-Native).
The Inno installer scripts contents (only 3 files: files, gimp3264 and
32on64) and filenames have been organized, making them much easier to
read, and slightly less hardcoded so less prone to being misunderstood
and pervasively receiving packaging stuff.
Just to be clear, one more time: the Inno installer (or future MSIX)
scripts never should be the center of attention. This "installcentrism"
caused a domino effect of partially "abandoning" the packaging, build.sh
and the meson scripts, which explains the existence of this MR...
(Some things still hardcoded since wildcards in Inno are very limited.
Also, the rational ordering principles of this MR were not applied since
these scripts are heavily based on the x86 .zip package and changing the
order of things here, according to my tests, breaks things quite easily)
The CI crossbuild job now use the same main script (and the same
sub-scripts of linking and debug generation) of the native CI for
packaging. These unified scripts greatly facilitates maintenance.
The crossbuild deps script is now more consistent in relation to the
native one. As this is polished, the cross one is now polished too.
A crossroad gimp build script was created with a more clear code.
Also, finally make the script for packaging only, removing build step
stuff that shoudn't be here (glib-schemas generation) since this causes
disparity with the Local native build; and adding some packaging
decisions that shoudn't be in the installer scripts (eg. specific
folders of ghostscript, glib; no share/themes), which also facillitates
INNO (and future MSIX) maintenance.
The local builds now can use the same script of CI for sake of time.
The compatibility layer is very simple and makes the script more
used/tested, therefore more reliable.
The local builds now can use the same script of CI for sake of time.
The compatibility layer is very simple and makes the script more
used/tested, therefore more reliable.
Also, remove some redundacy on the code for better maintenance.
Now, we have only ONE list applicable for build-deps-crossroad.sh,
build-gimp-msys2.sh and package-gimp-msys2.sh, instead of hardcoding
3 times. This unified list greatly facilitates maintenance.
Debian changes:
- Since autotools has gone, we don't need to specify 'meson' in the
debian job and others.
- The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and
the meson sintax of Debian jobs was also updated.
Windows changes:
- Then, clarify that the win64-nightly and win32-nightly jobs are, in
fact, in the 'packaging' step, since we don't really "distribute" GIMP
in .zip and the commands are almost the same of the packaging .SH
script, without scripted optimizations for Inno Installer (or future
.MSIX), crucial for distribution.
- We don't need to specify "native" sufix in any build since they are
the rule and cross builds are the exception.
General changes:
- The job names was changed to be more consistent and in accordance
with the folders present in the artifacts.
- The 'nightly' sufix was removed from the Inno Windows Installer job
and others, since this doesn't reflect the real build frequency.
- The scripts filenames are altered to stay "in order". This is not
essential but ultra convenient since it is easy to view and search.
(The -uni suffix is explained in a further commit)
- All artifacts names now have the commit to avoid apparently duplicate
files when downloading same step artifacts from different projects.
- Finally, rearrange the order of jobs rationally: first the OSes and
archs (from the most free and modern to the most closed and legacy),
then the stages (from 'prepare' to 'analysis'), ending with the
frequency of jobs (from the most frequent, called at each push, to
the least/weekly).
Overall, this changes, although difficult to review at the first
sight, will avoid in the future quite "dumb" issues like:
GNOME/gimp#10195
When cutting and pasting a single layer,
drawables->data might be empty. This results in a
crash on Windows and a failure to paste on Linux.
Since this function is inside an IF statement that already
confirms it has a valid image, the base type and
precision are retrieved from there instead.
Resolves #10537.
During the port, the "green_invert" variable
was repeated twice rather than using the
"blue_invert" variable. This prevented the
fractal from updating when blue was changed.
This is intended to prevent system theme background-images
and borders from overriding those set by GIMP.
The minimum size of tabs is also explicitly defined.
Our handling of Photoshop's Blend Clipped Layers as Group is flawed
causing the order of layers to be messed up which may cause certain
parts of the image to become invisible or having the wrong colors.
This only fixes the incorrect layer ordering. Correct handling of
group layers with clipping needs a more extensive rewrite.
This is a manual revert of eac1df4b61
since other changes were made to the same lines.
Although using legacy layer modes for several blend modes improves
compatibility with Photoshop, we found out during testing of the
image from issue #10498, that it negatively impacts loading of PSD's
that use Blend Clipped Layers as Group.
We convert this specific PSD setting by adding a layer group and
setting Composite Mode to Blend to Background.
However, our legacy layer modes do not support Composite Mode, meaning
that PSD's using this can show up using smeared colors.
Since this hasn't been in a release yet, let's revert this and rethink
how we want to handle the combination of these PSD settings.
Resolves #9933.
We used png_get_valid (pp, info, PNG_INFO_tRNS) to check if
an indexed PNG had transparency when exporting.
However, this function does not return TRUE/FALSE but instead
the contents of that PNG chunk. Since we use index 0 for transparency,
this function always returns 0. The non-transparent indexed export code
ran regardless, creating incorrect PNGs.
We set pngg.has_trns earlier if the image has transparency, so it's safer
to use this variable instead.
Magic number 1 changed to 2 in one place. Missed in earlier fix for #10127.
Changed magic number to a defined macro constant so it might not happen again,
should GimpConfig change again.
Substantive change is call gimp_item_get_by_id instead of gimp_drawable...
And a few type changes from GimpDrawable* to GObject*.
Lots of renaming of functions, substituting "item" for "drawable."
Update comments.
Made one function static that was already private.
Fix the test case gimp_vectors_set_selected
Add more tests
Enhance testing framework, add function assert-PDB-true
Enhance some tests: make test files order independent
Fix tests broken by recent changes to GIMP
There was the question on whether it needed an hyphen or not. The hyphen
naming was often used to describe the "Hard-edge painting" style, though
even for this, it was not an absolute case. Depending on English writing
style, we could also find "hard edge painting". Also Liam was noting
that when the term appears by itself, as a noun (rather than a
qualificative), it was likely best without hyphen. So we went for the
no-hyphen wording.
Then there was the capitalization question: should capitalization rules
of data labels apply to parts between parentheses? I went with the
answer that *yes*, since it's part of the title anyway. And without the
part between parentheses, we'd have several data named the same. So it's
just as important.
As a consequence, I also re-capitalized "FG to BG (HSV
Counter-Clockwise)" and "FG to BG (HSV Clockwise Hue)" gradients,
following this updated rule.
Resolves #10477.
The dark theme box-shadow for buttons does not blend well
when hovering over it, compared to the light & gray themes.
This patch adds an additional CSS rule to make the box-shadow
no longer clash in dark theme.
Some 2.10 modes, even in perceptual space, don't produce the same
result as PS. Now, the mapping table takes this into account, which
avoids surprises for the user.
The mapping table was generically indicating 2.10 modes as first choice,
which was resulting in terrible PSD compatibility in some cases. This
commit fixes this using legacy modes verified with latest PS version
(see attached files in MR).
Comprehensive rewrite of the DDS import routine, in the interest of
easier maintainability and readability. Adds formats.c/h, containing
tables and functions related to reading and parsing uncompressed files.
Importer now supports nearly all non-video uncompressed formats.
Includes a variety of minor-to-moderate fixes made along the way
which could not be pulled out into separate commits due to dependence
on other aspects of the rewrite.
Resolves #10454.
When porting to GimpProcedureConfig, all
light types were set to "Point" when 2 - 6
should have been "None" by default.
This patch fixes the defaults.
1. Recent changes to arg validation reveal bug in call to gimp-drawable-edit-gradient-fill,
supersampling arg must be >0
2. Make easier for testers to invoke by reducing the declared drawable capability
to SF-ONE-OR-MORE-DRAWABLE
Now use gimp-resource-delete
Drive-by fix of bad call to gimp-context-set-pattern.
Fixes other calls to gimp-font-delete, etc. in a test script.
Partly fixes 9867.
Due to a bug in commit de5c805cbb, which
changed the choice widget between line and paint tool to a
GtkStackSwitcher, changing that choice did not work anymore.
The reason being that the stroke method wasn't being updated on clicking
stroke. We fix this by setting the stroke method when OK is clicked.
When creating the dialog we also set the stroke method, to reflect the
last used choice, since that was also missing.
See discussion in !946: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/946#note_1768869
On Windows/macOS, the pad device is probably not even showing at all
right now, though I can't test. Also it could be eventually implemented
with pad actions support (see Luca Bacci comment in the same MR) using
WM_POINTER API on Windows.
On X11 though, the pad device is shown, except it is kind of pointless.
So I am disabling the frame (making it insensitive) and add a tooltip.
Handle some statefulness in actions taking a double parameter, in order
to make them friendly to GtkPadController and its pad ring/strip
integration.
The GtkPadController emits those actions with a double parameter
expressing the absolute value (e.g. 0-360 for rings, 0-1 for strips),
take care of converting these absolute values to relative changes
that increase/decrease the current GimpDoubleAction value.
Going for relative increments/decrements increases the genericity
of rings when mapped to actions, as going with the given absolute
values would mean means rings could be mainly mapped to angle-like
actions, reducing its usefulness.
We have everything in place to create GtkPadControllers converting
events into actions as configured in settings, and the signaling
to trigger the (re)generation of those as device, window or configuration
changes appear.
Only the last bit attaching those controllers to actually handle
input was missing, now done in this commit.
Since there may be multiple configured tablets and pads, we need to
keep track of per-device controllers to handle the configuration for
those. This mapping is kept in GimpImageWindow as the "main" toplevel
(i.e. the one(s) typically considered "keyboard focus" and receiving pad
events) and ensured to be kept up-to-date through the ::configure-pad
signal.
This API call will snapshot the current configuration of a device
into a GtkPadController, that is created and attached to a toplevel
(this event controller only acts on toplevels).
This controller will handle pad events, trigger actions, and update
compositor feedback (e.g. GNOME Shell pad OSD) as per the actions
mapped in the configuration dialog.
If a pad device configuration gets changed, or reset, we should trigger
the creation of new pad controllers for the existing toplevels.
Add the plumbing so that saving/resetting a device configuration will
result in the same ::configure-pad signal, and trigger it from the
relevant places.
In order to apply the pad configuration so it does something, we
need to create GtkPadController objects on each toplevel for each
configured pad device.
This signal will work as a hint that a new GtkPadController should
be generated for the given device and current configuration. At
the moment, emit it when pad devices are added or removed.
The UI is heavily inspired in the existing one for midi devices
and the such, as the restrictions are somewhat similar. Since there
is not enough information to introspect the device without the help
of libwacom (and the UI should work with tablets unsupported by
it, regardless) the list starts empty, and there exists a "grab
event" button to press pad buttons (or use rings/strips) and
create/focus a list item for the button/mode.
Double clicking on an action (or pressing the "edit" button) spawns
a different dialog with a GimpActionEditor to select an action.
And lastly, actions can be deleted with the "delete" button.
Pads may have different modes (e.g. leds in the tablet) that apply
to all pad features, the list will allow different actions to be
set on the same button in different modes. This basically multiplies
the amount of mappable actions by the number of available modes.
This object holds the mapping of pad device features (buttons/rings/strips)
to actions, given the current mode (e.g. leds in the device), and can be
serialized/deserialized from configuration files.
Fixing:
> Scalar value @inargs[...] better written as $inargs[...] at pdb/lib.pl line 247.
> Scalar value @outargs[...] better written as $outargs[...] at pdb/lib.pl line 386.
This continues the theme definition work from bd398d5c.
A new edge-border-color tag was created
to allow for defined widget edges in both
light and dark themes.
The box-shadow highlights for buttons
and header/menubars was defined to
reduce system theme leaks. Some CSS
attributes were rearranges as well.
Per the official format specification and hardware implementation,
BC1 cutout pixels are always black with 0 alpha, whereas previous
versions of the plugin interpreted them as white. Commit f97e718e
partially fixed this, but made the behavior an import option that
also ignored the alpha component. This commit reverts the addition
of this option in favor of consistently following the spec.
The export properties "save-type" and "mipmaps" were left as ints
in Commit 427130be due to uncertainty on whether options could be
conditionally disabled on GimpChoice properties. From testing it
this functionality appears to work fine and is used in other plugins.
Now all combo props are GimpChoices and fully configurable from dds.c
Moves most of the code relating to YCoCg and Alpha Exponent into
misc.c/h, in the interest of making the rest of the codebase cleaner.
Removes the decode option from the import menu, as encoded files are
always decoded now (there used to be a menu button for doing this
after import, but with it gone there's no reason ever to not decode).
Finally, the remaining functions in color.c were only ever called once,
so these were extracted and inlined, and the empty file deleted.
Partial refactor of parts of ddsread to better handle DX10+ files.
Though not included here, this is necessary to import formats that
have no DX9 equivalent, namely BC6H and BC7, as the current handling
simply downgrades DX10 files and imports them like DX9 ones.
Extensive formatting and cleanup in the read-write files, and addition
of some comments where they seemed appropriate. Renamed a couple of
single-letter variables to be more descriptive.
Also removed an unnecessary global variable in ddswrite.c, and made
the "config" variable in ddsread a GimpProcedureConfig type, as was
previously done for ddswrite.
Fixes two major issues with mipmap generation, namely sRGB transforms
being applied both backwards and in 8-bit precision, causing severe
color degradation. sRGB transforms are now handled correctly and all
mipmap generation is done at 32-bit floating-point precision.
A new cubic filter has also been added (Catmull-Rom) which rounds-out
the existing lineup of cubic filters.
Also includes extensive code cleanup (sorry I couldn't separate this)
to mipmap.c/h and color.c/h
Recently some extra input validation was added, which caused the
gimp-image-set-selected-layers command in script-fu to fail with an
invalid value for argument 2.
This is caused by the object array contents always being set as
GIMP_TYPE_DRAWABLE, while the actual type may be a layer, etc.
So, let's set the actual type of drawable being used here by using
G_OBJECT_TYPE on the first data element.
Adds specific definitions for some widget borders that
are currently only defined by the system. This avoids
clashing colors depending on the system theme.
Resolves #10033
Not all system themes set a GtkRadioButton border-radius, so it
can default to 0. This creates a "box" around the radio button.
This patch defines the border-radius at 100% to make it universal.
These were using gimp_procedure_new, which was causing warnings like
LibGimpConfig-WARNING **: 13:56:33.270: couldn't serialize property
GimpProcedureConfig-plug-in-metadata-editor::image of type GimpImage,
and
gimp_plug_in_destroy_proxies: ERROR: GimpImage proxy with ID 1 was
refed by plug-in, it MUST NOT do that!
This also saves us from having to define image and run-mode parameters
ourselves.
We remove two warnings:
1. warning: format '%ld' expects argument of type 'long int', but
argument 5 has type 'GType' {aka 'long long unsigned int'}
Since GType is gsize, and this is not used in translations, use format
specifier G_GSIZE_FORMAT.
2. warning: enumeration value 'SF_IMAGE' not handled in switch (and more
similar ones).
Add a default block to let the compiler know we handle all values.
These are not generic undo function, but specific to the resize case (and even
more particularly when calling the GimpItem's resize() class method).
Also the variable was wrongly named no_undo when it actually was meant for the
opposite meaning, i.e. when we want to push an undo for a resize() call. This
made the call harder to understand. Furthermore the usage of double negation did
not help with understanding the code.
This is a fixup commit to MR !961, fixing a particular commit 5c2373a125 saying
that when canceling painting with layer expansion, strokes outside of the layer
remain visible.
When auto expanding layers, there is an option that allows user to fill
the newly expanded part with the pattern. But without this change, it
was not possible to change the active pattern without switching to some
other tool like bucket fill tool. This commit allows that.
Also added option in Edit->Preferences->"Tool Options"->"Paint Options
Shared Between Tools" that decides weather the options should be shared
between different tools.
Canceling a paint stroke restores the layer and mask (if present) to the
original size if they were expanded during the stroke. The part of
stroke that is outside the layer remains visible though.
In ink tool, if last_blobs is empty, the copy of blobs present in
last_blobs and blobs_to_render was same. Due to this, when layer
boundary is expanded, we move same blobs twice. Due to this a straight
line was drawn when starting painting from outside layer boundary. Fixed
the issue by storing a duplicate version in blobs_to_render. Updated
free part accordingly.
In layer expansion if user is trying to draw outside the layer boundary
with expand option turned on but the "Lock position and size" enabled,
the lock square will be blinked. If user is painting on layer mask, the
corresponding layer's lock will be blinked. It will be blinked only
once per stroke.
When resizing drawable for dynamic layers, the resize drawable function
would push Modified Layer/Channel item to undo stack. Initially, I was
checking if the drawable is being painted upon and used it to disable
the undo, but this when using resizing layers with layer mask, even if
mask is being painted upon, we still want to resize the main layer and
vice versa. But the main layer is not being painted upon so it would
push the undo to stack. To prevent this, I was using
gimp_drawable_paint_start before resizing, but this method is very
inefficient, as this function duplicates buffers. So added a new member
to drawable->private that will store weather to push undo or not.
Added option to tool settings that will decide how newly created parts
of layer and layer mask should be filled. For layer, same options are
provided as present in "Set Layer Boundary Size" dialog. For layer mask,
first two options from "Add a Mask to the Layer" i.e. "White" and
"Black" are added.
This commit changes gimp_channel_resize function to actually use the
passed fill type instead of using hardcoded GIMP_FILL_TRANSPARENT.
Hardcoding this value if required should be done in function calling
this function (which is already the case with all the instances already
present afaik).
Modified gimp_gegl_buffer_resize function to add three new parameters,
pattern, pattern_offset_x and pattern_offset_y. If pattern is not NULL,
then we set the pattern of buffet to this value. Like in
gimp_gegl_buffer_resize function, this logic is mostly copied from
gimp_drawable_fill_buffer function with minor changes.
This function returns resized version of the input buffer. It also takes
in a color argument. The layer background will be filled with this
color. Fill background logic is similar to gimp_drawable_fill_buffer.
The lock in the layers tab only sets lock for the actual layer and not
for its mask, so also check the lock on the actual layer and not just on
the mask when editing layer mask.
Everytime the layer expands, if the undo extents are empty, then make
them non zero. If the undo extents are zero, then user will not be able
to undo the expansion of the layer. This is perticularly required by
MyPaintBrush as just clicking the image without any motion does not draw
anything, but expands layer if required.
This function returns TRUE if the drawable is expanded. Otherwise, it
will return FALSE. This removes the need to check width and height of
the drawable to infer the same.
Made `gimp_image_editor_image_flush` and
`gimp_image_editor_image_flush_idle` functions idle. For expanding
layers dynamically, we need to use gimp_image_flush funtion from the
paint therad. The gimp_image_flush eventually calls these functions.
When painting the layers with a layer mask, if the layer need to be
expanded, the layer mask is also expanded with it. The same is done even
if layer mask is being painted upon.
Undo works with these layers by adding resizing of both the layer and
mask to the undo group if the layer is resized during painting.
Now layers will expand when trying to draw beyond layer borders with ink tool.
Tool options similar to paint tools have been added (expand_use and
expand_amount).
When painting with "Expand Layers" option turned on but "show all"
turned off, layer will not expand beyond image borders.
Layer will not expand if "Lock size and postion" is turned on.
Created a separate function gimp_paint_core_expand_drawable that handles
layer expansion while painting. The gimp_brush_core_get_buffer function
now uses this function to expand drawable. It has been separated so that
it can be reused for ink tool.
When painting with paintbrush tool, the borders of active layer will
automatically expand to accomodate the stroke. The undo does not work
with expanding layers.
This patch adds better handling for group begin and end markers
within ASE palettes. As a result, this fixes an issue where the last
color was not imported in some ASE files without groups.
Additionally, this guarantees that colors are imported using 4 bytes
per https://gitlab.gnome.org/GNOME/gimp/-/issues/10359#note_1921462
Resolves #10359
When compiled with -Werror=strict-aliasing, the build fails
on this line due to converting pointer datatypes.
This patch switches to using memcpy () instead.
Currently we only use and retain "critical" PNG chunks,
discarding any safe-to-copy but non-image chunks.
This adds code to store them as parasites and then
include them on export, thus preventing loss of data.
when loading a BMP image with an invalid compression value.
The invalid compression check was missing a goto out (error exit)
causing the GError to be overwritten, which caused a GLib warning.
We add the missing goto statement here.
Overwriting a GIF animation results in loss of frames if a previous export turned off
animations.
This sets a parasite on import which we check for on overwrite. If it was an
animation originally, we overwrite as an animation as well.
Though we mostly removed floating layers/masks (formerly floating
selections) in many interactions, at least for default behaviors for
basic pastes, there are still advanced usage attached to this concept
and some advanced users are willing to have easier access to such items.
For this reason, this commit:
- adds edit-paste-float and edit-paste-float-in-place for pasting the
contents of the clipboard as floating data with default positionning
algorithm or in-place respectively;
- renames select-float to select-cut-float which does a cut and paste as
float in one action;
- adds select-copy-float which does a copy and paste as float in one
action;
- reorganize a bit the `Edit > Paste as` submenu with sections for the
floating data variants;
- add a "Float" submenu in "Select" root menu, containing the 2 variant
actions select-cut-float and select-copy-float.
This adds an import option for DDS DXT1/BC1 images to always use
transparency. This is the default behavior, since this was what always
happened until now and it seems that DDPF_ALPHAPIXELS is very rarely
set for these type of images.
However, as the mentioned issues explains, advanced compression
algorithms can use this transparency data instead to mean a black
pixel. There is however, no certain way to determine this.
For that reason, we add an option here, that, if disabled, will
interpret fully transparent values as a black pixel.
Some games apparently need dds images to be vertically flipped.
We already have an option to flip dds images on export, so it makes
sense to also allow flipping on import.
The anchor and merge down buttons are visible at the same time, which should not be the case.
Their visibility is now dependent on the existance of a floating selection.
The New Group and Search/Link buttons are also disabled when there's a floating section.
In addition to the requested DXGI variants we also load the older
D3DF versions, including handling of the signed versions.
We also set signed when the pixelformat flag DDPF_BUMPDUDV (added in
the previous commit) is set.
As shown in issue 10287, the system theme can create a
large white border around GimpSpinButton.
This patch fixes this, and also improves the border appearance
by assigning it to the background color rather than system default.
This adds support for loading RGBA DDS images with 16- and 32-bit per
channel. Loading is supported for 16-bit half float, 32-bit float,
16 and 32-bit unsigned and signed int.
This supports both the DX10 formats and the D3D FOURCC versions.
16- and 32-bit per channel images with less than 4 channels are not
yet supported.
When saving a PDF, you have the option to export layers as pages.
This works for a single layer group that contains multiple layers.
However, the option is disabled because the plug-in only checks
"top level" layers.
This patch adds code to check if the single layer is a layer group,
then enables the option if there are more than one layer in that group.
This completes commit 685c8bde99 where the http:// scheme was automatically
transformed into https:// in some cases, in particular while typing (when
pasting for instance, it was still possible to add an http URL). So let's block
"toggled" signal handlers when the URL is explicitely edited to prevent this
annoying issue.
(cherry picked from commit b991f8b361)
This is only a temporary solution meant to be backported to gimp-2-10 branch,
so that at least the preview now matches how angles always worked in at least
the 2.10 series: angles are measured clockwise.
Now there is the question that in the documentation of the Brush Editor, it is
written that angles are supposed to be counter-clockwise. A solution was
proposed to make them so, but only for generated brushes (whereas angles stayed
clockwise for other types of brush) which is a very bad inconsistency.
Furthermore I find the whole tool options vs. brush editor settings mess quite
confusing. Some decision should be made for GIMP 3.
For GIMP 2.10 though, this should be an OK fix: no behavior change on-canvas,
only making the preview actually match what happens on-canvas (even though it
goes against what the docs say but it's probably better than breaking workflows
relying on actual on-canvas behavior).
Note: this commit is based on an initial proposition by Alx Sa in MR !1119,
except that the patch was only working when the preview needed to be scaled.
Instead we must go through this brush transformation code path for generated
brushes, whatever the scale.
While exiv2/gexiv2 could be able to load metadata from JXL files
directly, success is not guaranteed (depends on version and
configuration, for example support could be disabled or compressed
metadata could not work).
Loading metadata via libjxl should work all the time.
It is also important not to display dialog to rotate the image
according the orientation from EXIF, because in case of JXL,
the orientation is stored in codestream and it has priority.
This fixes this warning (as appeared with commit ad8b47bff7):
[1/235] Compiling C object libgimpwidgets/libgimpwidgets-3.0.so.0.9900.17.p/gimpdialog.c.o
../../../../../../../dev/src/gimp/libgimpwidgets/gimpdialog.c:774:1: warning: ‘gimp_dialog_set_title_bar_theme’ defined but not used [-Wunused-function]
774 | gimp_dialog_set_title_bar_theme (GtkWidget *dialog)
We could either put the whole `gimp_dialog_set_title_bar_theme()` declaration,
definition and usage into #ifdef, or only the implementation (making the
function a no-op on non-Windows platforms). I chose the former. There was some
discussion that maybe some implementation may happen later for other platforms,
but until then, no need to call it needlessly (even more as we don't know when
any theoretical other implementation would happen).
Certain dds images can have non-zero unexpected pitch_or_linsize values.
Until now we were only computing this ourselves in case it was zero.
Let's just always compute it and print an error to the terminal if it
differs from the value in the file.
A sample can be found in Galactic Civilizations 3: Bokeh_Hex.dds.
This change also allows us to safely load the poc in security issue
ZDI-CAN-22093 as that issue was apparently only caused by an invalid
value of pitch_or_linsize.
Optimize dds loading a bit by moving code that doesn't change outside
the loop:
1. The number of bits to be shifted when the source isn't exactly 8 or
16 bits depends on bytes per sample and isn't changing inside the loop.
2. Use rowstride variable to compute width * d->bpp once.
3. The check for rowstride > hdr->pitch_or_linsize doesn't change
inside the loop so move it out.
Inside the loop we only check the DDSD_PITCH flag once and move both
the size check and the fread check inside it.
Resolves #10262.
The gradient color was being used if Confetti or Color from Gradient
dynamics had been set, even if dynamics had been disabled.
This adds an additional check to make sure dynamics are enabled
first - otherwise, the brush's existing stamp or color is used to paint.
There were 2 issues here:
1. When more than 8 bits per sample are used, a previous commit changed
it so that we would be using 16-bit integer mode instead of 8-bit.
However, the actual code for this specific format was not updated to
reflect that.
We fix this by computing 16-bits per channel values and upshifting the
10 and 2-bit samples to 16 bit per channel.
2. The computation of masks was incorrect. It computed each channel
mask separately, based on whether it was <= 8 or not.
However, if any channel needs more than 8 bits, all masks should be
computed 16 bits since we will then 16-bit integer mode.
We fix this by checking all channel bits together, and if any is higher
than 8, but not more than 16, we use 16-bit masks.
I also took this opportunity to add support for 32-bit masks if we
ever need those.
@Wormnest noted remaining regressions after 8faad92e.
The second fread() only runs if the DDSD_PITCH flag is set,
so the error handling check should also be conditional.
Additionally, the ZDI-CAN-22093 exploit no longer runs but
still could cause a plug-in crash. This patch adds an additional
check to ensure the buffer size was within bounds.
@Wormnest pointed out that compressed files are likely smaller than
width * height * bps, so our check to prevent ZDI-CAN-22093
also caught valid files.
The size check is removed from load_image () and moved to load_layer ()
before the two fread() functions, as we know exactly how much we'll
try to read at that point.
When loading an xcf file, if a a font has already
been used, its file's hash is compared against the hashes
from the xcf file (to speedup loading), but if the font is from a .ttc file (a font
collection), then all fonts from that file will have the same file
hash, so the wrong font might be selected. a simple solution is to not
use the hash except as a last resort if every other field is identical.
These are not usable by plug-ins anymore which should store their data between
runs as arguments or aux arguments (in case of values which should be stored
from one run to another but are not really usable for non-interactive scripts).
These are per-plug-in (not polluting the whole process space with just random
strings as identifiers which could be used by other plug-ins) and even survive
restarts of GIMP.
I still keep these functions, but only internally, as they are used to store
settings of GimpAspectPreview, GimpDrawablePreview and GimpZoomPreview across
plug-in runs. Still I changed their API to set and return a GBytes directly
(mimicking the private PDB functions' API).
Also I remove gimp_pdb_get_data_size() which is useless when exchanging GBytes
directly.
Note that the 2 functions are still exported in the library, and only not
advertized through headers (so they are not really internal, just hidden), on
purpose, because we need to call them in libgimpui. So it is still relatively
easy for a plug-in to use them. Nevertheless I made clear in the function
documentation that these must not be considered public and could end up deleted
at any time. Any plug-in still trying to call these takes the risk of having
their code relying on unreliable API.
...by adding parameters and porting to
GimpProcedureConfig/GimpProcedureDialog.
Code was also rearranged to match the ordering
of other plug-ins.
As a note, the help message is "Special effects that nobody understands".
It would be nice if someone with more familiarity with this plug-in could
update the help messages to explain the parameters.
I had the case when "Sphere" script crashed, bringing down the whole script-fu
plug-in (while trying to reproduce #10214). Then after being run, we get a
dangling pointer to a finalized action object.
Even in successful use cases, we will want to give the ability to unregister
normal plug-ins/procedures wrapped as GIMP extensions, and there is also the use
case of temporary procedures, so I'm sure this bug could be reproducible even in
normal non-problematic runs.
I am pretty sure that this should be in single selection mode because we don't
even really have code to handle cases with multiple brushes or font selected.
Right now, we assume in many places that there is only one font or brush (or
other data) active at a given time.
Yet this code (or older versions of it) is old apparently and I realize that
even in 2.10, I can ctrl/shift click to select several data objects. This is the
weird part.
Anyway let's put this in single selection mode and see how it goes. If there
were actually use cases which I didn't know about, I'm sure we'll soon have
reports.
I could still see annoying scrolling up/down happening when we are deselecting
an item (typically with ctrl-click). In such a case, the cursor is on a
deselected item. Just make it bump to a closest item, preferably a visible one.
Note that "save-type" and "mipmaps" were left as ints rather than GimpChoice,
as some options are conditionally disabled and I don't know if that
is available in GimpChoice just yet.
A DDS loading bug related to 6ad54ca3 was also resolved.
The correct header value to check for the pixel size was not "depth" but "bpp".
My first versions were commits 98f0c448 then 1d8782915e but the more I go, the
better I understand the implications of the selection vs. the cursor. In
particular, when setting a cursor, which also initializes the selection to this
item only, the tree view would also scroll to this item. The current
implementation, which sets the top item as cursor, is therefore particularly bad
for multi-selection which doesn't fit fully in the view, because we also end up
scrolling up. Say you have a long list of layers, you first select the top
layer, then scroll down to the bottom layer and ctrl-click it: the selection
(now 2 items) works but you end up scrolled back all the way up.
This alternate version is much better, by ensuring that your cursor is at least
within the selection (hence avoiding the discrepancy between keyboard navigation
and pointer navigation, and which was fixed with commit 98f0c448), so that we
don't try to change the cursor when possible.
This was broken in commit 3e101922. Setting a cursor basically resets to a
single selection, invalidating pointer-made multi-selection.
But then we got back the bug it fixes, which is that we must grab focus after
the selection is actually made. So we now grab at the end.
This also had a bad consequence for multi-selection (again): if the focus was
not already on the tree view, gimp_container_tree_view_selection_changed() was
not called. This function was where the actual selection-changing is meant to
happen. So we had to shift-click (or ctrl-click) twice. The first time, nothing
would happen (but focus was given to the tree view). The second time, we could
finally update the selection.
This is why we add 2 different cases of focus grab, which should hopefully
handle all cases correctly, though this code is really extra-complex. This
replaces MR !1128.
I also remove (without replacement) 2 usages of gimp_get_data() without
associated gimp_set_data(). According to the comment, it looks like the
associated data was likely set by the GAP plug-in instead. Let's drop this.
Finally I see a lot of arguments, several of them being float arrays, so I
wondered if they were related to the curve and point arrays we are storing as
aux arg now. Apparently these arguments are not even used in the plug-in, right
now, which is explained in commit e318651c99. Maybe if these were actually
used/set and if we implement float array (de)serialization, would this aux
argument become useless?
Lastly, I deleted some code paths which were never used. For instance, stored
bval.total_steps was never set to anything else than 0 anywhere (so I removed
both the variable and the other code-path, which actually ended up being the
GAP-related data get). Additionally in p_bender_calculate_iter_curve(), there
was a big else block which was only happening when the GAP-related variables
were set. It got deleted too (as is a function only used in this block of code).
The argument is the serialized description of the generated fractal. Actually it
may even be useful as a non-aux argument. A GFile argument could eventually be
interesting too, though one arg per setting would be better of course (it allows
more easily to generate animated frames for instance). In such a case, the GFile
would be used in priority, otherwise the other args.
Notes:
* I didn't port to GimpProcedureDialog though it looks like it would not be too
hard (most of the GUI would still be custom GTK code, yet we could have the
generic "reset to initial|factory values" buttons and load/save).
* The custom "Reset" button (identical to what "reset to factory values" would
do) works fine anyway.
* The "run with last vals" works fine where there were indeed previous runs
(which may be in previous sessions), but crashes when it's actually the first
run ever. Some of the base structure data were not initialized. It should not
be too hard yet would require a bit of code reorganization to fix this.
- Argument "parameter-uri" becomes "parameter-file" (GFile instead of URI
string).
- Adding a "settings-data" auxiliary bytes argument to handle all settings for
the time being, instead of using gimp_get_data() and gimp_set_data().
- "last_file_name" was also removed from the ValueType struct, using the
"settings-data" arg instead.
- Fixing the non-interactive usage which was missing a gegl_init() call.
- Use GIO for various reading and writing to a CML parameter file.
- Better bubbling up of error messages.
- Fix the loading of the last section of CML parameters file.
- Also fixing deactived file dialog when clicking the open button a second time.
We use a GBytes auxiliary argument (i.e. not visible in the public API) which
perfectly replace gimp_[gs]et_data() API, in even better (since it also works
across sessions).
The "Reset to initial values|factory defaults" still don't work. We could make
these work even with the AUX args, but I feel like this would be far too much
work for a non-optimal solution anyway. The real solution can be when we get
more public arguments to this PDB procedure to handle every setting
individually. This can happen after GIMP 3 release (especially now that
arguments number and order don't break the PDB API anymore).
I added a bunch of arguments, in particular nearly all the settings in the main
dialog, except for "Colormap" as I'm unsure yet how to handle it. It looks like
a mix of GimpChoice and GimpDrawable. I guess it could just be both (2 args,
using values from the GimpChoice if GimpDrawable arg is NULL).
And I didn't make the settings in the "Edit Flame" dialog into arguments as I'm
not sure if the "Speed" and "Variation" in particular should be args, or are
just temporary args only meant to construct a flame (in particular, it looks
like it builds data defining the flame?). These data should be their own args
probably?
Maybe we could also have the "file" as alternative way to init the flame data
(the "Open" button)?
For now, I'm just storing the whole settings struct as an aux argument, so that
"Load/Save Settings" work, as well as the initial values from previous run.
Also the whole code is still a bit of a mess. I feel like we could really
simplify a lot of the code, all these values stored globally or duplicated now
in both the GimpProcedureConfig and the control_point structure.
Resolves #9989
In 2.10/GTK2, clicking an already selected toolbutton caused the
background color to change to indicate this action.
This patch restores that behavior through CSS updates.
It also slightly rearranges the CSS to group related button styles.
Since we were not chaining up with parent's finalize(), we were not
removing the instance from the gimp-debug infrastructure which assumed
the object was leaked and would try to read its reference count for
debugging purpose, when GIMP_DEBUG=all was set.
In fact, the object was not leaked, therefore we got into a segfault
when dereferencing already freed memory.
I added a few specific validations for range types (int, double…), and a
generic validation at the end, meant to catch all yet uncaught invalid
argument cases (yet with less details on the what and why).
In Preferences > Toolbox, clicking on an item below the
initial scroll window view causes it to jump to the top
automatically. This patch prevents this by setting the
clicked index in the GtkTreeView before grabbing focus.
I had this one crash upon exit, inside gimp_align_options_update_area() as a
consequence of gimp_align_options_image_changed() being called on an image
change. I could not reproduce after this one time and it's very likely a race
condition when everything is getting finalized, and the tool options object is
getting finalized earlier than the user context.
Anyway this should fix the potential crash.
gimp_procedure_new_return_values() takes ownership of the passed GError (it
allows, among other things, to call it directly as return value). So we must not
try and free it afterwards.
These are stored in the Extended Block. This block also holds metadata
in Exif, IPTC, and XMP formats, but those are not yet implemented in this
patch. A comment stating Exif was implemented in PSP 10 was corrected
to PSP 8 as well.
Changes only to ScriptFu.
The third term (the default) of a SF-FONT etc. spec is now ignored.
Test case is SF>Test>Sphere. There are still crashing issues
related but separate.
Changes were made to the click code for layers & masks
due to the introduction of multi-select, and this seems to
have caused the view highlight to be inconsistent.
This patch adds the gimp_layer_tree_view_update_borders ()
call after a click or selection to fix this.
On Windows, the title bar can be set to light or dark mode via DwmSetWindowAttribute ().
This adds code to update the main title bar and dialogue title bars based on the current theme.
The main title bar uses "prefer-dark-theme", while the dialogue title bars
uses the color of the widget background to assume the correct color.
If we leave a space between the macro name and opening parenthese for argument
lists, the args are not considered macro args (which will be discovered when
using it). I experienced this issue while testing code on some plug-in
yesterday, so thought I might as well fix all these broken macros for casting to
the specific GimpPlugIn subclass, so that we won't have a next time.
The gimp_procedure_run() already existed, though it was with an ordered
GimpValueArray array of arguments. Its usage feels redundant to the series of
gimp_pdb_run_procedure*() functions (which is confusing), but
gimp_procedure_run() was actually a bit more generic, because it does not
necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a
local GimpProcedure, such as the case of one procedure which would want to call
another procedure in the same plug-in, but without having to go through PDB. Of
course, for local code, you may as well run relevant functions directly, yet it
makes sense that if one of the redundant-looking function is removed, it should
be the more specific one. Also gimp_procedure_run() feels a lot simpler and
logical, API wise.
A main difference in usage is that now, plug-in developers have to first
explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when
they wish to call PDB procedures on the wire. This was done anyway in the
gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name
directly).
Concretely:
* gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and
gimp_pdb_run_procedure_valist() are removed.
* gimp_procedure_run() API is modified to use a variable args list instead of a
GimpValueArray.
* gimp_procedure_run_config() and gimp_procedure_run_valist() are added.
* gimp_procedure_run_config() in particular will be the one used in bindings
which don't have variable args support through a (rename-to
gimp_procedure_run) annotation.
Passing (name, type, value) triplets is actually useless because we can get the
type information from the procedure/config anyway. That only adds one more
verification to do. Let's just change the function so that we pass (name, value)
couples instead, pretty much like in `g_object_set()`.
As far as plug-in API is concerned, at least the calling API, order of arguments
when calling PDB procedures doesn't matter anymore.
Order still matters for creating procedures with standard arguments (for
instance, "run-mode" is first, then image, or file, drawables or whatnot,
depending on the subtype of procedure), but not for calling with libgimp.
Concretely in this commit:
- gimp_pdb_run_procedure_argv() was removed as it's intrinsically order-based.
- gimp_pdb_run_procedure() and gimp_pdb_run_procedure_valist() stay but their
semantic changes. Instead of an ordered list of (type, value) couple, it's now
an unordered list of (name, type, value) triplets. This way, you can also
ignore as many args as you want if you intend to keep them default. For
instance, say you have a procedure with 20 args and you only want to change
the last one and keep the 19 first with default values: while you used to have
to write down all 20 args annoyingly, now you can just list the only arg you
care about.
There are 2 important consequences here:
1. Calling PDB procedures becomes much more semantic, which means scripts with
PDB calls are simpler (smaller list of arguments) and easier to read (when
you had 5 int arguments in a row, you couldn't know what they refer to,
except by always checking the PDB source; now you'll have associated names,
such as "width", "height" and so on) hence maintain.
2. We will have the ability to add arguments and even order the new arguments in
middle of existing arguments without breaking compatibility. The only thing
which will matter will be that default values of new arguments will have to
behave like when the arg didn't exist. This way, existing scripts will not be
broken. This will avoid us having to always create variants of PDB procedure
(like original "file-bla-save", then variant "file-bla-save-2" and so on)
each time we add arguments.
Note: gimp_pdb_run_procedure_array() was not removed yet because it's currently
used by the PDB. To be followed.
Similar to commit 6905b0bbef for "file-pat-save-internal". For interactive
usage, nothing is changed, but for non-interactive ones, we can now choose a
list of drawables to export.
Pending more changes, relative to the discussion in #7370.
Since now the name of arguments will become more important, over order, let's
name the first parameter "run-mode" even in cases when this is a dummy argument
(most often the case when a procedure always acts the same, whether interactive
or not). I keep the mention of the parameter being useless in the nick and blurb
strings, as it's useful information. But let's keep using our "standard" arg
name "run-mode" for this first argument.
This partially revert some of the changes in commit 652a1b4388 because the
Windows CI suddenly failed because of this (my local build on Linux didn't have
any problem though) with:
> /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_save_defaults':
> /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2570:(.text+0x633): undefined reference to `_gimp_procedure_config_save_default'
> /usr/bin/x86_64-w64-mingw32-ld: /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2576:(.text+0x644): undefined reference to `_gimp_procedure_config_has_default'
> /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_load_defaults':
> /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2549:(.text+0xa2f): undefined reference to `_gimp_procedure_config_load_default'
> /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_constructed':
> /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:368:(.text+0x11b1): undefined reference to `_gimp_procedure_config_has_default'
This is because these functions are used not only inside libgimp but also
across inside libgimpui. As a consequence, the build fails when linking
libgimpui.
This goes with our planned change of not making GimpProcedure arguments order
relevant anymore regarding the PDB API. In particular, it means we don't want to
use GimpValueArray for various procedure arguments API, but directly
GimpProcedureConfig objects.
This change will allow to add or reorder arguments in the future, so that we
won't have to create new PDB procedures when adding new arguments, while still
keeping PDB API stability.
Some of these should not even be visible by libgimp and were just fine as static
as well! For the rest, I make them really private (not only with a private
header).
We cannot be 100% sure generically (i.e. for all possible bindings available
with GObject Introspection) if bindings add their own reference to objects or
not. Clearly we have cases when they always do (Lua, Javascript), cases when
they do only in certain conditions (global Python variables) and cases when they
don't (Vala). What we know for sure is that in these script languages,
developers don't manually manage memory anyway. So the additional reference is
not their fact.
So let's just maintain a list of automatic memory managed binding languages,
among the few we officially support (i.e. the ones for which we have working
test plug-ins) and verify by executable extension if the plug-in is written in
one of these.
Both keeping a manually-updated list and verifying by extension are not so
pretty solution, but for now it will do.
Resolves the second half of #300.
This adds conditional code to the gtk_window_present () call in gui.c
to prevent it from running if the user requested it stay minimized in the shortcut
or commandline call on Windows.
It also keeps the splashscreen minimized in that case.
As explained in the comment above, the reference might actually be owned by the
binding code (not by the plug-in code) and therefore can still be released
afterwards. Freeing it now while we don't own the reference exposes us to
double-free crashes.
This will be needed in particular for GIMP on Windows/Aarch64. Also even on
other OSes, it is useful to support lua plug-ins not only with luajit but also
upstream lua.
This is in part a port of commit 6f921b27bb from gimp-2-10 branch, except that I
could not easily cherry-pick because too much had changed already in the master
branch.
There are also a bunch of additional changes in some other glue scripts.
Also some rules which were in the 2.10 branch don't apply to the main one, such
as Python being copied from the x86 binaries, since clang-aarch64 has Python3
(unlike Python2).
See discussion in #9170 and !1091. It looks like this soon won't be a problem
with a recent llvm-windres (which is now patched). But until then, let's patch
upstream GIMP but only for this build.
Note: the additional `rm` call was done for this error:
> + mv _install-arm64 /home/SYSTEM
> mv: cannot move '_install-arm64' to '/home/SYSTEM/_install-arm64': Directory not empty
I guess the home directory is not properly wiped-out between runs, which is not
a huge problem as long as the runner is private to our project. Let's clean
things ourselves.
In some very hard-to-reproduce conditions, I experienced
tool_manager_selected_layers_changed() running on an invalid GimpToolManager
pointer (because tool_manager_exit() had already run) and therefore segfaulting
on quit. Let's make sure we disconnect the signal handler.
Add Border enlarges an image by twice the specified border size and creates the border in this
additional space. If an image already has the intended final size, this behaviour is not desired.
This change adds a toggle to (dis)allow resizing, similar to the drop shadow script.
This came up in a reddit thread by /u/rapidexchange
https://www.reddit.com/r/GIMP/comments/6csofx/im_new_to_gimp_so_sorry_if_this_is_a_stupid/
Adds code to read in PSP_SELECTION_BLOCK.
If there was an active selection in the PSP file when it was
saved, that selection will now be active in GIMP as well on load.
This is a consequence of commit 98f0c448. Apparently setting the tree view
cursor also reset visually the selection. So I make sure I only set the cursor
on the first path in the list of selected items.
Using gegl_parallel_distribute_area() for gimp_gegl_is_index_used() is just far
too slow by 2 order of magnitudes compared to a threaded implementation where I
process each buffer at once (but each in their own thread from a pool).
I guess the basic value check is too basic to warrant being done in threads
(note: even growing the distributed area by bumping the thread cost a lot was
not enough).
I didn't fixup commit dbaa8b6a1c directly so that we keep a trace of the
gegl_parallel_distribute_area() implementation in case we can do better later.
Additionally I fixed gimp_gegl_shift_index() to use the full drawable format,
including the possible alpha channel. Otherwise shifting indexes may result in
dropping the alpha value.
This comes with a "colormap-delete-color" into the "colormap" action group. The
action/button will be insensitive when the selected color is used in the image,
since it is only possible to delete unused colors.
Until now, it was not really possible to delete a colormap color, but since we
now use GimpPalette, people would definitely try to do so. It just makes sense
to allow doing this, but only if the color is unused.
Additionally when we do this, all the pixels refering to bigger indexes will be
edited so that they continue to refer to the same color (bigger indexes are
shifted by -1). Therefore removing an unused color does not change the image
render.
I wondered if we might want more options, e.g. the ability to delete a color
without fixing indexes (i.e. that colors over the deleted color index would
shift to the next color). This would even allow to delete used colors (though
now the last index would have to be unused one, unless we cycle colors).
Yet I don't think this should belong to this basic API. The most expected
behavior when deleting a color from an image colormap is to fix all indexes
stored in pixels so that the image still shows the same. So that's what this
function will do in this generic usage.
Improper counting of args declared by scripts versus pspecs in a ProcedureConfig.
Scripts don't declare run_mode, while pspecs have run_mode and an extra internal pspec
that is not an argument.
This is meant to replace gimp_image_get_colormap() (see also #9477).
We likely won't need a gimp_image_set_palette() because we can simply edit the
image's colormap/palette with GimpPalette API now and it is directly updated.
For instance, the following code changes the first entry in the image palette to
red, immediately:
```python
i = Gimp.list_images()[0]
p = i.get_palette()
c = Gimp.RGB()
c.r = 1.0
p.entry_set_color(0, c)
```
For this to work fine, I added a new concept to GimpData, which is that they can
be tied to a GimpImage (instead of a GFile). Image palettes are not considered
internals, they are just tied to their image, therefore they can be edited by
scripts/plug-ins.
Additionally with this commit, editing an image's colormap from libgimp API also
generates undo steps now.
Original patch by @ellestone.
The current tooltip is somewhat confusing for two reasons: It doesn't
mention the word "ICC", leaving room for doubt as to what a "color
profile" might be. And as @TheTooleMan suggested, it's easier to read
and understand if the action (opening a file . . .) is in front of the
modifier (. . . with an embedded ICC profile) instead of vice versa.
bootchk had the case in commit 6781a35668. I again had it with gfig. I think it
just makes sense to init GEGL, especially as the errors are not that explicit
and that the plug-in code may not even call GEGL code directly (so it makes it
harder to guess).
After the recent port.
* contrast-retinex: Initialize format & src_buffer to NULL
* curve-bend and map-object: Remove no longer needed functions
* file-load-gif: Fix C++ style comment
When the selection changes, the focus must be on one of the selected items. Not
doing this was creating a very annoying behavior where you would select an item
in the tree view with the pointer first, but then when moving up/down with the
keyboard arrow, the move originated from the previously set item. This was
because the arrow move used the "cursor path", i.e. the keyboard focus, and not
the item selection as origin.
In our case, let's make sure these match (i.e. the cursor path is the path of at
least one of the selected items, which is the most expected behavior for mixed
pointer/keyboard interactions).
See code in gtk_tree_view_move_cursor_up_down() from GTK code.
Resolves #10119.
If the user sets the "Image Spacing" and "Hole Width" values
to 0, the hole creation code gets stuck in an infinite loop.
This patch adds a check to the allocation code for the hole
to make sure both its dimensions are greater than 0. If not,
then the hole is not created in the first place.
… with another default shortcut.
This won't happen with the standard US layout, but among all the layouts which
exist (or will exist), there is no say that the characters behing <shift>2-5
keys are not another one of our default shortcuts for other actions. We don't
want to print this case, because it is special enough that it's really not a
bug. In this case, we just ignore the transformed shortcut on the zoom action
and be done with it.
Calling gimp_resource_delete() on a data with a file which was not stored yet
would fail on missing file as reported by Lloyd in a comment in #9976. We could
just special-case the code to make the already-inexisting case acceptable on
deletion, but there are a few more issues.
In particular gimp_data_create_filename() relies on actually checking file
existence on the file system. Therefore generating the file path too early
(before any possible rename, i.e. for uniqueness or other formatting need) would
easily generate duplicate paths (which means one of the data object would be
overwritten on exit). It's better to kinda *reserve* the set file path
immediately by saving the data file.
The only drawback I could see on saving early is possible I/O slowdown if a
script were to create many data, but I actually don't think it's a valid use
case (no script should likely create enough data files that we would notice a
slowdown, i.e. likely creating hundreds of data objects at once) anyway. So
let's go with it, at least for now.
If the GIF has a value other than 0 or 49 in its PixelAspectRatio
header, then we now use it to set the non-square pixel resolution.
For reference, GIFs calculate this value like so:
PAR = (Value + 15) / (float) 64.
It returns all the fonts (possibly more than 1) with a given name. I left the
function gimp_font_get_by_name() as a utility when one don't want to choose (or
is not able anyway, e.g. a script with minimal information), though I wondered
if we should not simplify with a single function (the new one, which is the
correct one now that it is possible to have several fonts with a given name).
It is easy to test with fonts named the same. For instance I could find 2
different fonts, both named 'Holiday'. This call in the Python console returns
both:
> Gimp.fonts_get_by_name('Holiday')
As part of this commit, I also implemented resource arrays (or subtype arrays)
as PDB arguments and return types.
… description.
- The returned value as width/height/etc. of the glyph extents (or bounding
box), not "of the font" (which doesn't mean much).
- Adding some definition for ascent and descent. This text is straight out
copied from Pango documentation comments in pango/pango-types.h.
- I don't see why we were negating the descent value. Let's keep the value sign
as defined in Pango.
- Fonctions were renamed: s/gimp_text_fontname/gimp_text_font/ and
s/gimp_text_get_extents_fontname/gimp_text_get_extents_font/
- The size_type arguments were removed. Even in 2.10, this argument was marked
as "dead" and ignored. It was only kept for API compatibility.
- The font name (string) was replaced by a GimpFont argument.
gimp_text_font() is easily tested in the Python console with:
> Gimp.text_font(Gimp.list_images()[0], None, 10, 40, "Hello World!", 1.0, True, 100, Gimp.context_get_font())
And gimp_text_get_extents_font() with:
> Gimp.text_get_extents_font("Hello World!", 100, Gimp.context_get_font())
- First do not write the protocol-version (and therefore don't read it either
nor compare it to the current one). This file does not depend on the protocol
version.
- Secondly when reading an unknown identifier, simply print a message on stderr
for debugging/reference, but ignore it up to the next closing parenthese.
- Finally do not use the file-version as a terminal error as well. When we read
a shortcutsrc with the wrong version, we still try to read it as best as we
can. There might be issues, but it's better than fully dropping the whole list
of shortcuts as it's a pretty important file (people might have spent a lot of
time tweaking their shortcuts!).
Fixing:
> [809/2421] Generating libgimp/GimpUi-3.0.gir with a custom command (wrapped by meson to set env)
> libgimpwidgets/gimppropwidgets.c:37: Warning: GimpUi: multiple comment blocks documenting 'SECTION:gimppropwidgets:' identifier (already seen at gimppropwidgets.c:23).
Hardcoded colors don't work well with theme customization (on a dark theme in
particular, it was bad).
Anyway built-in units are already grayed-out and non-editable. I don't think
further styling is needed.
This function is not perfect and in particular doesn't seem usable with binding
because of GimpUnit being some weird mix between an enum and some kind of class.
So this will have to be fixed too. See #8900.
… function gimp_font_get_pango_font_description().
Also updating file-pdf-save which is the only plug-in using these right now.
Note that I am not fully happy with the new function
gimp_font_get_pango_font_description() because I experienced some weird behavior
in file-pdf-save which is that some fonts were wrong if this is called after
pango_cairo_font_map_set_resolution().
But let's say this is a first step looking for improvements.
...and to GimpProcedureDialog.
Also resolves #25 by adding the missing PDB parameters to the GUI.
Note that there are a few remaining tasks:
* The config values are being copied to mapvals.
Eventually the rest of the code needs to be updated
to directly use the config.
* The material tab uses icons from the Lighting plug-in. They didn't show up before the port; this needs to be fixed.
* The drawable buttons are huge compared to the original plug-in. The styling needs to be looked at.
I am using the same GimpDrawableChooser with an additional drawable_type
argument to only show the appropriate tab if we want to limit what can be
chosen.
None of our plug-ins actually use a GimpLayer or GimpChannel only arg so far,
but if we have some day, or if some third-party plug-ins want to have such arg,
now they quite easily can!
After testing, setting a window as transient to another from another process is
still broken on Windows and it's hard to diagnose without using Windows
directly. Since it's not just broken, but it even hangs the whole process, which
is quite a blocker issue, let's disable again the whole code on Windows.
Converted to GimpProcedureDialog as well, and changed the
string argument for the combobox to GimpChoice.
Some widgets are still standalone and could be further improved
to work with GimpProcedureDialog.
A new aux parameter for upper/lower border area was added so this could be generated
as part of the GUI.
I received warnings about serializing the FloatArray and GBytes parameters, so I did not integrate
the existing variables with GimpProcedureConfig in this current version.
The only missing feature is that we don't constrain the various argument
drawables to RGB/grayscale or to the same dimension as the input drawable. This
could actually be quite easily implemented, either through a set of constraint
flags, or a more flexible callback function (similar to the API of
gimp_drawable_combo_box_new()). It could either be implemented on the argument
level (which has the advantage of letting libgimp handle argument sanity of
plug-in developers, even in non-interactive calls, with generic error messages)
or within the new GimpDrawableChooser API.
I was actually implementing this when I realized that this plug-in works fine
even with images of different dimensions. As for the format, GEGL handles format
conversion automatically. There is absolutely no reason to limit ourselves.
So let's drop this feature for now, because we should not over-engineer. If it
turns out useful and we get requests, we can always create later either a
specialized arg macro GIMP_PROC_ARG_CONSTRAINED_DRAWABLE() or a method to
specialize the widget with gimp_drawable_chooser_new_constrained() for
instance).
This was not working properly and needed some external build script as well as
the stamp/bogus header trick like for other similar in-source generated code.
In the same time, I get rid of old meson code which was meant for when using
meson < 0.57.0 (since our requirement is now meson >= 0.59.0).
I believe it should not happen in normal GUI case (which is when you create a
GimpProcedureDialog). I had the issue while moving around some plug-in code and
moved dialog creation before gimp_ui_init() by mistake. The issue was not
obvious until I followed the trace inside libgimp. This would be even more
frustrating for plug-in developers so let's have a clear warning message giving
the possible plug-in crash reason.
The various drawing APIs are cumulative which is not right when we want to
change a preview (especially if the preview changes dimensions! Then we end up
with pieces of the previous drawing behind the new one).
This new function will allow to reset the whole drawing. Note that we may end up
with some black background if the preview are doesn't have the right dimensions.
This should be improved later too.
Similarly to the various GimpResource select PDB calls, this allows to call a
core dialog in order to choose a drawable which will be returned back to the
calling plug-in.
This new GimpPickableSelect dialog is a subclass of GimpPdbDialog and uses the
same GimpPickableChooser widget as GimpPickablePopup, except that since it's
inter-process window management, it is harder to make a popup positioned
accurately relatively to a parent (especially on Wayland). This is why it's a
separate widget as a simpler dialog (which we will still try to make transient
as much as possible across platforms).
Improvements of GimpPickableButton:
- Update the selected pickable live as you choose it in the popup. This allows
for instance to get live preview of GEGL operations while staying within the
pickable popup.
- Store the initially selected pickable (before popping up) so that when one
cancels (either with Esc key or by clicking outside the popup, but not on the
parent button), the button comes back to the previous pickable.
- Properly destroy the popup when the parent widget is finalized to avoid
annoying cases where the popup might still be alive.
Additionally I split the GimpPickablePopup with a GimpPickableChooser containing
most of the GUI, which will make it usable as plug-in pickable chooser as well!
Clicking on the parent (typically a button, as in the GimpPickableButton case
used in GEGL operations' generated GUI) used to emit "cancel". Let's have it
emit "confirm" instead.
Also it makes for a "confirm" interaction through pointer action as there were
none until now (only key "confirm", e.g. Enter or Space keys), unless
implemented in a child class (e.g. GimpPickablePopup would emit "confirm" on
activate-item of the tree view widgets, e.g. when double-clicking an item; that
was not ideally discoverable).
A few minor code style issues were also fixed.
Note that there's only one procedure parameter (Preset name),
but it's not retained between runs.
I want to ask about this before making a full conversion to
GimpProcedureDialog widgets.
This name was really irking me because it's not a button (anymore? Maybe it used
to be just a button). Depending on the specific widget, it will have several
sub-widgets, including a label. And it can theoretically even be something else
than a button.
So let's just rename these widgets with the more generic "chooser" name.
Similar to the latest commits for GimpBrush:
- gimp_pattern_get_buffer() returns a GeglBuffer and allow getting a scaled
version of the pattern.
- Old gimp_pattern_get_pixels() is made private.
- Moved GimpPattern into its own file and store the buffer to avoid re-querying
it through PDB continuously.
No as for the widget to select a pattern:
- Preview frame ensured to be square.
- Default size increased.
- Drawing code using the new gimp_pattern_get_buffer().
- Cleaned up code.
So what I realized was that the core was sending contents without transparency.
Actually the mask was our transparency channel here. Since in most use cases,
what you want to do when you request a brush buffer is to be able to draw it
somewhere, having a buffer already with alpha is much better, even more because
by default, it looks like background color is black which is possibly not what
you expect usually from a brush preview.
If someone wants absolutely no-alpha, it's easy to get rid of the channel. It's
simply better that the default behavior is the most expected use case.
- Increase the default size to 40x40 and multiply it by the current window scale
factor to have decent preview size.
- Make the brush preview always square with a GtkAspectFrame: even though
brushes are not necessarily square, this is a much more obvious size rather
than letting GTK choose a random allocation size which ends up very weird
looking.
- Scale down the brush to the biggest possible dimensions which fit the square
preview area (if the brush native size is already smaller, I don't scale up
though) while keeping aspect ratio: previous implementation was really weird,
as we were only seeing a tiny corner of much brushes as we weren't scaling
them down. Obviously I use new gimp_brush_get_buffer|mask() functions for
this as it supports scaling.
- Implement drawing color brushes too: the previous implementation was only
drawing the brush mask, which was absolutely not what would be expected for
such brushes.
- Add a white background behind color brushes with transparency.
- Simplify and clean up the code.
One of the consequences of this new implementation is obviously that it's
mandatory to call gegl_init() when using this widget.
… and gimp_brush_get_mask().
gimp_brush_get_pixels() was a bit crappy, returning raw data with only
dimensions and bpp to go with (no color model/space, no bit depth…). So the
assumption is that we work with 8-bit per channel data, possibly with alpha
depending of number of channels as deduced from bpp, and very likely in sRGB
color space. It might be globally ok with many of the brush formats (and
historical brushes) but won't fare well as we improve brush capabilities.
- gimp_brush_get_pixels() is in fact made private.
- The 2 new functions are using this old PDB call _gimp_brush_get_pixels() to
construct buffers. This has some limitations, in particular that it returns
only 8-bit per channel sRGB data, but at least the signature won't change when
we will improve things in the future (so if some day, we pass fancy brushes in
high-bit depth, the method will stay the same).
- This new implementation also allows scaling down the brush (keeping aspect
ratio) which is useful when you need to fit a brush preview into a drawing
widget.
- Current implementation stores the buffers at native size in the libgimp's
GimpBrush object, hence save re-querying the core every time you need an
update. This can be improved as current implementation also means that you
don't get updates if the brush changed. This should handle most common use
cases for now, though.
- Also with this change, I move GimpBrush class implementation into its own
dedicated file.
- Move the property widget functions for GimpResource properties into a new
libgimp/gimppropwidgets.[ch] file. This mirrors the files
libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types.
- Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new().
- gimp_prop_chooser_factory() doesn't need to be public.
- Add a label to GimpResourceSelectButton, make so that the
gimp_prop_chooser_*_new() functions set the property nick to this label and
add this label to the size group in GimpProcedureDialog.
… from the plug-in normal runtime crossed streams!
I also add a huge comment in-code, because this was annoying enough to
understand and debug that I don't want someone to remove the idle without proper
consideration and testing in the future, thinking it's useless.
- Removing useless or redundant code.
- Simplifying various logics.
- Using GimpResource directly in temporary PDB procedures, not resource names.
- Better cleanup of the core resource chooser when the plug-in dialog quits (we
need it to ask core to close also any visible resource chooser dialog).
- Replace the "Close" button by more common OK/Cancel. In particular, the
GimpPdbDialog now properly keeps track of the initial object and when hitting
"Cancel" (or Escape key), this initial object is set back.
- Clean up some of the comments, especially when the code is self explanatory.
There is still much more to clean and improve, but it's a first welcome step.
Found by the definitely useful libgimp warnings:
> gimp_plug_in_destroy_proxies: ERROR: GimpPattern proxy with ID 13 was refed by plug-in, it MUST NOT do that!
One instance of `(GIMP_VALUES_GET_INT (args, 0)` was missed during the initial conversion.
This caused a compiler error. The value is now retrieved from the GimpProcedureConfig
object.
Brush, font, gradient, palette and pattern choices are currently chosen through
a dialog created by the core, which then returns the user choice to the calling
plug-in. This has the unfortunate consequence of having a pile of likely at
least 3 windows (main GIMP window by core process, plug-in window by plug-in
process, then the choice popup by the core process) shared in 2 processes, which
often end up under each other and that's messy. Even more as the choice popup is
kinda expected to be like a sub-part of the plug-in dialog.
So anyway, now the plug-in can send its window handle to the core so that the
resource choice dialog ends up always above the plug-in dialog.
Of course, it will always work only on platforms where we have working
inter-process transient support.
Instead of passing a guint32, pass the proper type, since our the HANDLE type
can be 64-bit on Windows (according to links I found).
I was hoping it might be the reason for the breakage under Windows, though I
also found Microsoft documentation saying that the 64-bit handle can be safely
truncated: https://learn.microsoft.com/en-us/windows/win32/winprog64/interprocess-communication?redirectedfrom=MSDN
Nevertheless I'd appreciate testing again from NikcDC or anyone else, as I
reactivated setting transient between processes on Windows.
Note that I also pass the proper types on X11 now (Window), even though guint32
worked fine. Better be thorough.
Having windows ID as guint32 is a mistake. Different systems have
different protocols. In Wayland in particular, Windows handles are
exchanged as strings. What this commit does is the following:
In core:
- get_window_id() virtual function in core GimpProgress is changed to
return a GBytes, as a generic "data" to represent a window differently
on different systems.
- All implementations of get_window_id() in various classes implementing
this interface are updated accordingly:
* GimpSubProgress
* GimpDisplay returns the handle of its shell.
* GimpDisplayShell now creates its window handle at construction with
libgimpwidget's gimp_widget_set_native_handle() and simply return
this handle every time it's requested.
* GimpFileDialog also creates its window handle at construction with
gimp_widget_set_native_handle().
- gimp_window_set_transient_for() in core is changed to take a
GimpProgress as argument (instead of a guint32 ID), requests and
process the ID itself, according to the running platform. In
particular, the following were improved:
* Unlike old code, it will work even if the window is not visible yet.
In such a case, the function simply adds a signal handler to set
transient at mapping. It makes it easier to use it at construction
in a reliable way.
* It now works for Wayland too, additionally to X11.
- GimpPdbProgress now exchanges a GBytes too with the command
GIMP_PROGRESS_COMMAND_GET_WINDOW.
- display_get_window_id() in gimp-gui.h also returns a GBytes now.
PDB/libgimp:
- gimp_display_get_window_handle() and gimp_progress_get_window_handle()
now return a GBytes to represent a window handle in an opaque way
(depending on the running platform).
In libgimp:
- GimpProgress's get_window() virtual function changed to return a
GBytes and renamed get_window_handle().
- In particular GimpProgressBar is the only implementation of
get_window_handle(). It creates its handle at object construction with
libgimpwidget's gimp_widget_set_native_handle() and the virtual
method's implementation simply returns the GBytes.
In libgimpUi:
- gimp_ui_get_display_window() and gimp_ui_get_progress_window() were
removed. We should not assume anymore that it is possible to create a
GdkWindow to be used. For instance this is not possible with Wayland
which has its own way to set a window transient with a string handle.
- gimp_window_set_transient_for_display() and
gimp_window_set_transient() now use an internal implementation similar
to core gimp_window_set_transient_for(), with the same improvements
(works even at construction when the window is not visible yet + works
for Wayland too).
In libgimpwidgets:
- New gimp_widget_set_native_handle() is a helper function used both in
core and libgimp* libraries for widgets which we want to be usable as
possible parents. It takes care of getting the relevant window handle
(depending on the running platform) and stores it in a given pointer,
either immediately or after a callback once the widget is mapped. So
it can be used at construction. Also it sets a handle for X11 or
Wayland.
In plug-ins:
- Screenshot uses the new gimp_progress_get_window_handle() directly now
in its X11 code path and creates out of it a GdkWindows itself with
gdk_x11_window_foreign_new_for_display().
Our inter-process transient implementation only worked for X11, and with
this commit, it works for Wayland too.
There is code for Windows but it is currently disabled as it apparently
hangs (there is a comment in-code which links to this old report:
https://bugzilla.gnome.org/show_bug.cgi?id=359538). NikcDC tested
yesterday with re-enabling the code and said they experienced a freeze.
;-(
Finally there is no infrastructure yet to make this work on macOS and
apparently there is no implementation of window handle in GDK for macOS
that I could find. I'm not sure if macOS doesn't have this concept of
setting transient on another processus's window or GDK is simply lacking
the implementation.
...and to GimpProcedureDialog.
selection-to-path-dialog.c was also removed as the code can now be contained
within selection-to-path.c thanks to the new API.
… is set.
The order for thumbnail creation in gimp_imagefile_create_thumbnail() is now:
1. If there is a GimpThumbnailProcedure, it is run first.
2. Otherwise we check if a thumbnail is in the metadata.
3. As last resort, we just load the full image.
Part of the fix was to copy gimp_image_metadata_load_thumbnail() into the core
code. I have been wondering if we could not drop the same function from libgimp
and remove the GimpThumbnailProcedure frome file-jpeg, since it just uses the
metadata thumbnail and it is the only plug-in using this code.
Also it is much faster to run this in core and it's generic function which makes
thumbnail loading from Exif data working for every format supported by Exiv2.
On the other hand, the file-jpeg thumbnail procedure also gathers a few more
useful information, such as the color model (in a reliably manner, since based
on JPEG header, unlike from metadata which may be wrong).
The various information (width, height, image type and number of layers) are
those of the full image, not of the thumbnail. Make it clear in the docs of
GimpRunThumbnailFunc.
Additionally:
- file-xmc was returning the proper information but variables were wrongly
named, which was confusing.
- Fix file-ico thumbnail proc which was returning the thumbnail width/height.
- In file-darktable, initialize width/height to 0 so that we just don't show any
size when we don't get the information. It's better not to show anything than
completely wrong information (the thumbnail target size).
We were choosing the bigger icon in the ICNS list. Instead let's choose the
bigger icon within the target size bounding box. In case there is no smaller (or
equal size) icon, we falls back to the smallest bigger icon.
Also make sure we set width and height to the full image size, as this is used
as information on the full image (not the thumbnail).
SVG is a vector format which is easy to render exactly within the size×size
bounding box. Let's make sure we do so.
This makes for much sharper SVG thumbnails (and also possibly faster thumbnail
render).
… than a GimpValueArray.
Similar to other GimpProcedure, move to using a config object. A difference is
that thumbnail procedures are always run non-interactively.
Also fixing WMF load thumbnail procedure: the dimension computation was wrong
when the image was wider than tall.
Also the palette argument is now a proper GFile argument (not a string).
There is also a palette argument for the export procedure, but it's currently
unused. A palette storing function will need to be implemented.
Some bit of additional logic cleanup was done.
Again, I am losing a tiny bit of UI, in particular the ratio fields, but also
the update of the size label (this was kinda broken anyway, as it updated only
when updating some fields, not others).
Also moving the default resolution to 300 PPI.
Last but not least, I transformed the "paths" int argument to a GimpChoice
argument.
The new dialog is not fully on-par with the old one. We lost the X and Y ratio
fields as well as the ability to constrain dimensions to each other. This should
be improved when we'll get proper automatically generated widgets for dimension
arguments.
… a GimpProcedureConfig for arguments.
This also factorizes the code to load metadata. By default, a GimpLoadProcedure
will try and load metadata from a file (if Exiv2 knows the format). The run()
function will be allowed to edit the GimpMetadata object but also the load flags
before it is actually attached to the image, allowing plug-ins to have custom
metadata handling code when needed.
This is used in the generated GUIs for GimpChoice arguments, but also for
validation of property setting.
New functions:
* gimp_choice_set_sensitive()
* gimp_string_combo_box_set_sensitivity()
This is just a method to simplify transforming a GimpChoice argument into an
enum value, which is easier to deal with, in C. It also allows to benefit from
switch() warnings or the like to make sure no cases are missing.
Developers won't have to maintain manually a list of the possible values in the
help string. It can now be generated from the GimpChoice and will be therefore
ensured to always be up-to-date, and nicely formatted.
I also add some pango markup to the type helper texts to differentiate it from
the main argument docs.
These will replace the int arguments used in place of enums. The problem of int
arguments used as list of choices is that it makes calling PDB functions very
opaque. This is especially bad when a list is long, so you constantly have to
refer to the documentation to understand what a series of numbers mean in
argument lists.
And the second issue is that plug-in developers have to manually maintain a list
of values both in the GUI and in the documentation string. This help text may
get out-of-sync, may end up with missing values or whatnot. Also if it is used
as tooltips, it makes for very weird tooltips in the graphical interface, with
an overlong technical list of int-values mapping which should ideally only be
made visible in the PDB procedure browser listing.
- GimpLabelStringWidget widget makes any widget with a "value" string property
into a GimpLabeled.
- Add a "value" string property to GimpStringComboBox (which makes it usable by
GimpLabelStringWidget).
This will be used for creating limited lists of strings as argument types for
procedures.
Ideally enums are the best type for this, but it can only be used for generic
libgimp* enum types, not custom enums created only for a given plug-in. For
this, we currently just demote the args to ints which lose any semantic. A
limited list of string will give back some semantic and some better validation,
even though it's a tiny bit more annoying to work with strings than int types
(at least in C).
Also fixes some spelling issues and removes a warning about an
uninitialized variable.
Currently the only argument is for non-interactive mode, so
the dialogue isn't ported to GimpProcedureDialog yet.
The dialog itself is ported to GimpProcedureDialog. However, the
width and height require another API that allows for size entries with
multiple fields before it can be considered finished.
As usual, these got forgotten!
Also colorxhtml is actually deeply broken by commit 89c359ce47 which removed
gimp_drawable_get_pixel() (Niels thought it was not used, whereas it was simply
harder to spot with bindings!).
This will have to be fixed eventually.
I was hoping to redesign further but the whole logic of animated brush creation
is made so complicated that I think it would require a whole more complex GUI
with visual hints. So anyway I stopped at basic redesign and port to the new
dialog generation code.
It still makes the code much simpler and a bit more powerful (also less bugs
hopefully). I have also reviewed the procedure arguments, removing redundant
ones (display-cols and display-rows are just computed from cell-width and
cell-height) and adding some aux arguments instead to simplify dynamic GUI code.
The assert tests were not taking well into account the case where upper == lower
or where it's an integer spin which is just separated by 1 (both cases seem
silly, but it makes sense in the case of generic — or even dynamic! — spin
widgets where we want to adjust the min and max, e.g. depending on the property
of the image, or on other settings.
Now gimp_procedure_dialog_get_label() can work both with an existing property ID
or a new property ID. In the former case, it will simply sync the label with the
procedure argument, which will make it easy to update the label contents. In the
latter case, it just initialize with the provided text.
It's the basic stupid port, though this dialog is so bad that I think I'm going
for a second stage with a basic redesign of this GUI while also moving to
GimpSaveProcedureDialog. To be continued.
The expectation of 2 references per object in gimp_plug_in_destroy_proxies() was
wrong. It is true during most of the plug-in life, because both the
GimpProcedure and the GimpPlugIn have a hash-table keeping their own reference
to it, except that in gimp_plug_in_pop_procedure(), we release the reference
owned by the procedure with _gimp_procedure_destroy_proxies() first. So at this
point of the object life, its reference count is supposed to be 1.
The source of the bug was in fact in _gimp_plug_in_get_*() (where * can be
display, image, item or resource) which was behaving differently the first time
it is called for an object with the successive calls. In the first call only, it
was creating then refing into the table (so the object started directly with 2
references) whereas on successive calls, it just returned the hashtable-looked
up reference. In other words, it behaved as a (transfer full) on the first call
and (transfer none) on successive calls. And so did all public API which were
making use of this infrastructure (in particular gimp_*_get_by_id() functions).
The arg "num-images" is clearly redundant as the "images" array already has this
information. Moreover it is bug-prone, for instance running 'Repeat "Filmstrip"'
would crash the plug-in which was defaulting to NULL "images" and 1 "num-images"
(without any GimpItem serialization ability yet).
Of course, we could just fix this, but better remove the redundant arg and all
possibilities of future similar bugs.
Also I now display a proper error message when running without input images
which says: "\"Filmstrip\" cannot be run without any input images"
The widget_creator_func() given to gimp_prop_chooser_factory() will create an
object which will take its own reference. We must release the one we got with
g_object_get().
Metadata handling is also integrated in this API:
* while giving a possibility to disable metadata saving if you want to do it
yourself (e.g. in file-heif), by setting a NULL MimeType;
* and the GimpMetadata object is added as run() argument, allowing one to edit
the metadata during the run, while still letting the infrastucture handle the
save (e.g. in file-jpeg);
* or to save intermediate metadata with gimp_procedure_config_save_metadata()
(e.g. in file-tiff).
While we definitely should not use this inside app/, because having the private
structure easily accessible as a member is very convenient, it is clear that it
makes for a much nicer public signature. Also the priv member is of no help to
third-party developers using this API to make plug-ins and is better hidden in
such a case.
The dialog itself is ported to GimpProcedureDialog, but the original
plug-in only had one config parameter (Number of Tiles).
Some of the other options might make sense as config parameters
such as the horizontal/vertical toggles and opacity.
I needed a few more GimpProcedureDialog widgets, which I now have. The only part
still not generated in this plug-in is the image selection. This is hundreds of
lines less!
It now has arguments for every usable setting (except "keep-height" which is an
aux arg because it is simulated with a 0 "film-height" in non-interactive mode).
Also the film-height/keep-height default in interactive mode is now much better.
I override the film-height default and set it to be the image's height. This
makes for a much better default at all time.
The "Reset" button in Advanced section is not useful anymore since we now have
the generic "Reset" (to Initial/Factory) of GimpProcedureDialog, though it
actually doesn't work right for the time being, as it fails serializing
GimpFont.
This will be useful for plug-in developers but also for us. Seeing we leak the
config object is often a good indication that something is wrong in our handling
of internal references (since everything relies on the config object in plug-ins
now, in particular all the GUI).
I was clearly confused when I wrote this. The sinking part matters to take
ownership of a reference in the widgets table, but we don't need to ref widgets
again before inserting them in containers. We were leaking widgets and as a
consequence the config object (and as a second consequence, some objects such as
resources for resource-selection widgets).
It would be worth porting when GimpDrawableComboBox widgets can be used as
GimpProcedureDialog generated widgets. Or even better, if the GimpPickableButton
were ported to libgimp to be used by plug-ins (since it's actually a lot more
usable).
I didn't port to GimpProcedureDialog because we'd need first a GimpSizeEntry
generatable widget, which can map to several properties (here for instance 3
width properties).
… working with a GimpProcedureConfig.
These are the easiest ones to port as most of the work was already done (mostly
just some now useless calls to remove).
Same as with gimp_procedure_new2(), I will end up renaming the function to
gimp_image_procedure_new() once all usage of this function will have been ported
to the new function using GimpProcedureConfig instead of GimpValueArray
arguments.
The one in GimpResourceSelect is a very nice example of why using config objects
is much nicer, getting arguments by their name instead of an index (which in
this case had to be tracked down by a private function to handle different
cases).
Also in gimp_procedure_config_begin_run(), make sure we sync the arguments with
the config object first thing, even in interactive and with-last-vals case
(where the args may be further overridden). This was especially important for
Script-fu scripts as the image and drawable were not provided separately, so we
need to make sure that the config file has the right values.
Otherwise we will always try to reuse previous values or use the default,
bypassing the actual passed values.
I encountered this issue while porting file-glob and realizing that the
"pattern" argument was always passed to NULL, ignoring the explicitly set
pattern.
When a procedure has no run-mode argument, we should simply not assume anything
and use the passed arguments (which is what the non-interactive mode does).
A lot less lines for the same functionalities!
This includes improvements too:
* "include-pointer" as new PDB argument;
* settings storage thanks to GimpProcedureDialog;
* it should hopefully work better in non-interactive (though it's untested).
The macOS and Windows screenshots are untested after this change, though they
should still work the same. Please report if there is any problem!
This function allows to change the sensitivity of a widget depending on the
value of another property.
We already had gimp_procedure_dialog_set_sensitive() except it was only syncing
with a boolean property, whereas the new function can compare with any property
type.
This new function is meant to replace gimp_procedure_new() when all plug-in
usage will have been switched.
This function creates the GimpProcedureConfig object on behalf of the plug-in
and calls gimp_procedure_config_begin_run() and gimp_procedure_config_end_run().
This way we ensure that all plug-in calls with successful result are properly
stored without asking the developer not to forget to call these (if a "good
practice" is in fact something we request to do every time, especially for good
user experience, we might as well make it rather a core process).
Advantages:
* Better interactive experience: using any plug-in will result in saved
previously used settings.
* for developers, working on config objects is also much more comfortable than
working on GValueArray;
* step forward for the future macro infrastructure: if we can ensure that all
plug-in calls are properly logged, then we can replay plug-in actions, in
NON_INTERACTIVE with the same settings.
Resolves #10069
Currently, the DDS header information for the width, height, and bytes per scan line
are read in and assumed to be correct. As these values are used for memory allocation
and reading, it would be good to verify they do not exceed the file size.
This patch adds a condition after the header is read in to verify those values. If they exceed
the file size (mins an offset), the file is not read in and an error message is shown.
Resolves #9996.
While GIMP has background-colors set for specific buttons,
it did not have a default button background-color. This resulted
in "random" buttons showing system theme colors like the
[Reload Current Theme] button.
This patch defines a default background-color while leaving the
specific button themes intact.
This adds a border when hovering over icons in various
grid views (brushes, gradients, etc). This makes it more
visually apparent which option you can click to select.
Also refactoring: extract two functions
Add test case scripts/test/register-fail
Catches more registration errors.
Any errors not caught at least will not crash.
Remains to be ported to 2.10, but only a few lines, without the refactoring.
The bug is in fact in GTK. "image-missing" is supposed to never missing since
GTK embeds an icon as GResource. But it turns out that the code is buggy. So if
an icon is missing from GIMP theme, then system theme, then "icon-missing" icon
as well, GIMP crashes.
See: https://gitlab.gnome.org/GNOME/gtk/-/issues/3526
As a workaround for now, let's at least add our own "image-missing", at least in
our main themes (Color and Symbolic, not Legacy). This will make GIMP not
crashing at least by default when another icon is missing.
Of course a crash could still happen if one use Legacy or a third-party theme
and if their system theme doesn't contain "image-missing" as well, until GTK is
fixed.
This localization was added recently but it was not in the installer scripts.
Discovered with unit testing: meson test gimp:build / windows-installer-langs
Though GTK+3 is supposed to take care of scaling fonts with high density
displays, it turns out it is not enough for many, for various reasons (taste,
eyesight, distance to the display…). So we add this additional settings to tweak
further the font size.
With Aryeom, we experimented/discussed both a percentage UI vs. an absolute font
size field (e.g. as they provide in GNOME Tweaks). In the end, we went for a
percentage UI because we realize that we don't necessarily know what is the
current size at all. Mostly you just want bigger or smaller, and don't
necessarily care so much at which value is the font size.
This settings only has a single limitation (that we could find), which is when
used on a theme with widget rules using absolute font-size rules (px, or
keywords such as small/medium/large). As long as the CSS rules are relative
though (either to the parent widget, or to the root size), then it works fine.
Basically a theme hard-coding font sizes won't fare well with this settings, but
since we can consider this bad practice, it's an acceptable limitation.
GTK docs is pretty clear:
> It is a programmer error to pass an invalid accelerator string. If you are
> unsure, check it with gtk_accelerator_parse() first.
So now we verify validity of accelerator strings before using shortcuts from
config files (which can be consider "human input" as the file can be modified).
A first attempt at fixing this was going through the idea of changing the
concept of radio actions, such as allowing an active action in an action group
to be called again. Or having some action in the radio group which can be called
but never set active.
But in fact, I just realized that these zoom actions are simply not meant to be
radio actions. They are not stateful actions, nor are they exhaustive.
I also updated the `other_scale` storage logic. Instead of updating it each time
the zoom changed (which was even broken in some cases, like when changing zoom
through another action), I simply save the last custom zoom value. This is the
one which is reused across calls. I don't think always resetting to the current
zoom value is very useful (if you call this dialog, it's not to zoom to the
current zoom!). Also there was some concept of flagging this stored zoom value
as "dirty" by making it negative, but this was never actually used, which makes
me believe that current logic was not the original intent anyway.
Saving the previous custom zoom explicitly set seems to be a good enough
behavior, so let's go with it.
Resolves #10072.
The current PSP palette loading code does not check if
the file's palette entry count value is below the limit
(G_MAXUNIT32 / 4 due to each color being 4 bytes long).
This patch adds this check and stops loading if the count
is larger than GIMP currently supports.
Resolves #10071.
When reading RLE compressed data, a buffer was allocated to 127 bytes.
However, it can potentially be used to read 128 bytes, leading to a
off-by-one vulnerability. This patch allocates 128 bytes to the buffer
to prevent this from occurring.
This fixes 2 issues:
1. gimp_scanner_parse_string() may fail, which here would indicate broken input.
If it does, the string variable would not be set, so we need to initialize it
to NULL, otherwise freeing it could crash GIMP.
2. The variables set by gimp_scanner_parse_string() must be freed.
While I was testing some fonts I had on my system which were named exactly the
same, I also realized that all their fields were identical (among the ones we
store at least), except for the hash obviously. While the hash is great to
differentiate fonts when we use exactly the same files, there are various
reasons where one could have the right font installed with a different hash
(e.g. a simple reason could be if it was stored in different font formats).
So I'm thinking that maybe we'll want to add more fields in the future (if there
are any more fields allowing to better discriminate among some fonts named
similarly). This commit will allow this version of GIMP to still work when
loading the future serialized fonts with new and unknown fields. The unknown
fields will be ignored but at least it will still do its best to find fonts with
the known fields. Therefore we won't have to bump the XCF format version if we
only add new fields.
Similarly this allows to add the fields in-between, reorder existing fields or
even remove some in the future if we realize something is really unneeded. It's
less a big deal than the ability to add new fields without bumping XCF version
though.
Rather than looping fully over the full list of fonts once more, and
re-computing a second time the same font similarity score (with the risk of
messing up the copy-paste), let's just store the indexes of "most similar" fonts
in the first loop, then only query and check the hash for these.
Resolves #8756 (along with !1065)
The system theme leaked due to the checkbox styling not being
defined for GtkTreeView checkboxes.
The background-image in particular overpowers other settings.
The normal checkbox styling is now specifically applied to
these checkboxes as well.
This is not the main reason for the specific output in #9994. These ones are
more probably because of similar usage in GTK (which updated its own calls to
g_file_info_get_is_hidden|backup() in version 3.24.38). But we should likely
also update the various calls we have to use the generic
g_file_info_get_attribute_*() variants.
To be fair, it is unclear to me when we can be sure that an attribute is set.
For instance, when we call g_file_enumerate_children() or g_file_query_info()
with specific attributes, docs say that it is still possible for these
attributes to not be set. So I assume it means we should never use direct
accessor functions.
The only exception is that I didn't remove usage of g_file_info_get_name(),
since its docs says:
> * Gets a display name for a file. This is guaranteed to always be set.
Even though it also says just after:
> * It is an error to call this if the #GFileInfo does not contain
> * %G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME.
Which is very contradictory. But assuming that this error warning was
over-zealous documentation, I kept the direct accessors since they are supposed
to be slightly more optimized (still according to in-code documentation) so
let's priorize them when we know they are set for sure.
Resolves #10015.
The border color of the menu checkboxes was not
specifically defined by the CSS stylesheet, causing
the boxes to appear invisible when unchecked in
certain system themes. This defines the border color
to the same as the menu text to ensure visibility.
Resolves #10007.
The menu separator color was not defined in the stylesheet,
so it could vary based on the system stylesheet.
It is now set to @stronger-border-color.
Resolves #10040.
A System Theme leak could cause a large border to be drawn around
the export options at the bottom of the Save Image dialogue.
This patch defines them specifically as 1px border with the
@strong-border-color CSS styling.
Resolves #10000.
The border around notebook headers was not specifically defined in
GIMP's CSS stylesheet, so if the system theme used a different color this
would also change. It has now been defined as @strong-border-color.
The existing CSS was also moved to the same area as the other notebook
header definitions.
Resolves #10020
For some reason, not having the border-radius CSS style set
in widgets inside scrollwindow viewports causes them to have
a giant black order if they're not a full height. This was previously
fixed for GtkGrids. This patch fixes it for GtkBoxes as well, such as
the Procedure Browser description area.
Per @Wormnest comment on ACB palette loading,
g_utf16_to_utf8 () now uses the string length rather than -1 to prevent malicious non-NULL terminated strings.
This commit and the ones prior are simple refactoring,
with no intended functional changes.
In anticipation of enhancements 9608 and 8404
which make returned values more scheme like.
Also makes code more readable.
- g_str_equal() doesn't have the proper signature for g_slist_find_custom() so
current code was never processing multiple subfonts in a markup layer text.
- Escape the font name parsed from the XCF. For old XCF format, it could contain
forbidden characters. And even for new XCF files (with fonts names generated
such as 'font123' so there should be no escapable characters), we should not
trust that the XCF/parasite contents is correct. It can be wrong for various
reasons.
- Search for ' font="%s"', otherwise the search-and-replace might catch other
XML attributes. For instance we don't want the font "ultrabold" to match
weight="ultrabold".
- The backward compatibility code didn't have code to stop 2 font name
replacements to chain up, i.e. if a real world font was named "gimpfont123"
and another "gimpfont321" and if our replacement code were to change
"gimpfont123" to "gimpfont321" then "gimpfont321" to something else. In the
end, we'd have only a single font. I am fixing it by replacing " font=" to
" gimpfont=" then only correcting the attribute name at the end. This
intermediate attribute name acts as a "done" flag.
There are 3 fixes here:
1. First, searching for "\"GimpFont\"" to determine whether or not this is a new
format text parasite is not enough, because this string can be found in a
text layer with "GimpFont" only as contents. It will serialize as:
> (text "GimpFont")
Instead search for "(font \"GimpFont\"" which cannot be created as part of
the text contents because of the unprotected double quotes).
2. We must verify that strstr() did not return NULL when searching for markup
delimiters. It may happen if the parasite contents is invalid (we must always
assume it can be, since it's user data).
3. When deserialization of a text from parasite fails (e.g. because parasite
doesn't actually exist or its format is wrong), still make sure the GimpText
has a font (setting the standard one before deserializing). Otherwise GIMP
crashes down the line.
For this, I also had to fix gimp_config_deserialize_object(): the object type
name must be parsed even if an object was already set in a GObject property.
The new parasite format cannot be loaded by old versions of GIMP. This means we
must bump the XCF version (even though technically we didn't really touch the
XCF format itself because text layers are stored in a hackish way, yet text
layers are just too important nowadays to not care).
Nevertheless if an old XCF with text layers was loaded and the text layers left
untouched, the old parasite will be saved back as-is. Therefore no need to bump
the XCF version in this specific case. Only when we created new text layers or
edited existing ones.
New code uses pango_attribute_as_font_desc() which appeared with Pango 1.50.
Since it's currently present in Debian stable, I don't bother too much and bump
this dependency.
Also let's use the same version for pango, pangocairo and pangoft2. They all
come from the same project/repository, so we must likely expect them to be equal
(if they are not, there is likely a problem).
Previous code was incrementing the similar_fonts count each time we found a
better candidate. So we ended up computing the hash even when we had only 1
candidate with maximum similarity.
Moreover this commit fixes a crash happening with the "standard font". The
lookup name must always be allocated, even when it's an empty string (otherwise
it crashes at free).
Additionally this commit factorizes the code so that gimp_font_get_hash() takes
care of hash computation instead of duplicating code.
Finally I do some code organization.
MR #1011 breaks that because now we have a display name
and a lookup name, so font info is saved in the xcf file,
and when loading, the font which matches these info is used.
This doesn't fix pango markup having the wrong fonts names.
In GimpText, The font used to be stored as a string containing its name,
Now, it is stored as a GimpFont object, which makes more sense and makes
operations on fonts easier (such as serialization).
Adds a class "gimp-offset-area-frame" to the frame containing a GimpOffsetArea in resize dialogues.
This allows the styling from 2.10 to be applied to indicate canvas size when resizing layers.
Since GimpOffsetArea is a GtkDrawingArea object, it can't have CSS directly
applied to it - that's why the class is added to the frame instead.
GIMP's .gpl palette format and Swatchbooker's .sbz format can contain
metadata on the number of columns. This value was ignored before;
now the import dialogue checks for this value and uses it.
from plug-in
I get a critical error when calling gimp_text_layer_new and the function
doesn't return a GimpTextLayer:
(file-psd:47120): LibGimp-CRITICAL **: 16:00:59.035:
gimp_gp_param_to_value: type name GimpTextLayer is not registered
Adding the above line to libgimp/gimp.c fixes the problem.
This was a regression appeared with commit 1b3af8a89b. We still don't want to
flush the whole image, but if the selected layers change, we want to flush the
display shell.
Filling with Middle Gray requires getting the image format
for conversion from CIE Lab. This works when filling a layer,
but new images are not yet available in the context.
This adds the image to the context before gimp_drawable_fill ()
is called so it has access to the image format.
For characters outside ASCII:
1. repr is wrong in REPL
2. sharp constant #\<codepoint> fails to evaluate
3. sharp constant hex #\x<hexdigits> accepts invalid UTF-8 codepoints
4. a call to error with such a character eats the output string
Also, changed the repr of ASCII control characters (was #\x7)
to their unicode repr (now a box glyph with hex)
Test framework and tests in Scheme, and portable.
Work in progress. Expect commits for more tests.
Testing framework is stable, more or less.
Add more tests
Add tests layer and layerMask.
test Item methods
More tests, selection
Test memory, vector in TS.
More tests char functions
sharp expr tests
Generating the devel docs fails on Windows because it can't find
Babl-0.1.gir, which is only available for me in GIMP's prefix.
Adding that path with -add-include-path fixes the issue for me.
While `length` is always assigned a value by gimp_color_profile_get_icc_profile (),
some compilers don't recognize this and warn about it being uninitialized.
This assigns six instance of `length` to 0 when declared to remove the warnings.
Exif tags Exif.Image.Artist, Exif.Image.ImageDescription, and
Exif.Image.Copyright were not being synchronized with their Xmp and
Iptc.IIM equivalents in the metadata-editor.
This commit adds synchronization of reading and writing of the metadata.
We adjust the struct for equivalent_metadata_tags by removing unused
fields and adding a field that points to the equivalent Exif tag in
a new struct called exif_tag_info.
On loading of the metadata tags we now also check a limited set of
Exif tags. If no value was set yet, we use the Exif value, or else
we check to make sure both had the same value. If not, print a
warning in the terminal.
On saving of metadata, we now also save to the marked Exif tags, or
if the value is NULL, we remove the tag.
In passing, we also fix two memory leaks by freeing with g_strfreev
temporary string lists.
Dates in Xmp include a time and timezone, so add a default time when
selecting a date since we can't edit time and timezone yet.
So far, we didn't take into account that IPTC-IIM has separate date
and time+timezone values instead of the combined value in XMP for
DateCreated.
When loading DateCreated check if it has the same value as IPTC
values DateCreated and TimeCreated combined. If not, we show a
terminal error and ignore the IPTC values.
If neither Xmp nor Iptc has a DateCreated, then use Exif.Photo.
DateTimeOriginal combined with OffsetTimeOriginal to set an initial
value.
When saving, synchronize with IPTC-IIM by splitting the DateCreated
value in date and time+timezone and save each to the appropriate tag.
Also make sure that for IPTC-IIM the date separator is a '-'.
Adds a bottom margin to the grids because the horizontal scrollbar
was overlapping the bottom-most row of the grid.
Adds wordwrap and left/right margins to multiline text widgets,
mainly to make the text not start right at the edge of the widget.
We were using a string for the metadata mode, meaning we had to compare
string values in a lot of places.
We simplify and probably speed-up comparisons here by replacing the
mode string by an enum value.
The only place still needing the string values sometimes is
metadata-impexp.[ch] where we added a conversion table to convert
the mode to a string.
to fix the issue when 'Standard' can be actual font from the list
or a font which starts with. (ie. Standard Symbols PS)
Fixes: #3104 (GNOME/Gimp tracker)
OpenEXR allows for arbitrary channel names. Instead of failing once the common ones are checked, this patch
checks the number of channels in the file.
If there is only one channel, it is treated as
grayscale (similar to OpenImageIO's behavior).
A debug warning with the channel name is also printed.
When replacing a selection, take and apply markup (if any)
from the first character of the selection for the entered
text.
This fixes the case when you no longer can change the
global layer text properties after replacing the text.
Also, this changes the behavior introduced in #1220.
Fixes: #7948 (GNOME/Gimp tracker)
Organizing sub-dependencies into modules helps. Later if for instance we need to
remove or change OpenEXR, we know that they are related and that Imath can be
removed if we remove OpenEXR.
The targets were just being left floating, and the pre-generated in-tree
source were always used instead
When bison/flex are found, ensure we actually dep on their output - thus
actually running the targets - and only use the in-tree copies as a
fallback
After discussions on IRC with ender/Jernej and frogonia:
* exchndl.dll (drmingw) requires dbgcore.dll and dbghelp.dll which seem to ship
with win10+, but not win7 (we don't know for Win8). So for Win7, Jernej had to
manually add it back (otherwise, building then running on Win10, it looks
fine, but GIMP fails to start on Win7).
* MSYS2 dropped Win7 support anyway and supports now Win 8.1+.
See: https://www.msys2.org/docs/windows_support/
So even though it looks like GIMP works fine on Win7 (after special-casing the
2 DLLs above by adding them manually in the installed files), there might be
unforeseen issues in the long run.
* Win7 official support by Microsoft now ended. And Win8 support is soon to be
(it actually already has, "except for Server 2012 [based on Win8], which's
supported for another 2 months"). Win8 never had much adoption anyway.
* frogonia confirms they didn't see many Win 7 reports, if at all, in the last
year.
So based on all these, and in order not to make our life over-complicated, we
drop Win 7/8 support for the next 2.99 versions and for the upcoming stable 3.0
series.
Though we keep support to these versions in the 2.10 series, in order not to
disrupt current usage too much.
Crossroad repo was finally moved to Freedesktop.
See: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/477
This should avoid the too many failures we have lately on TuxFamily
infrastructure (and also gives a proper bug tracker for Crossroad). I am very
thankful to TuxFamily for all these years! :-)
Let's not be said that I moved the repo because I don't like this friendly FLOSS
host anymore. I just needed something different for Crossroad project now.
Some fonts which pango identifies correctly, became broken
after renaming them in fontconfig, so the strategy was to
rename only fonts which pango can't see.
To check if pango got the correct font, the PangoFont
has to be loaded from PangoContext, which is costly.
It Turns out that querying FontConfig with more attributes
fixes this. Hence renaming every font doesn't affect
the fonts pango already sees.
We use fontconfig directly to rename fonts to fix some issues
with Pango (see MR !1011), and fontconfig is present on all
platforms supported by gimp (even on windows, pango is build with
fontconfig as a dependency), so it makes little sense to keep this
code path which is now never used.
in gimpchannel-select.h
Looking at the version in gimpchannel-select.c, the calls made to it,
and also what is usual, the corner_radius_x should be before
corner_radius_y.
Found looking at the cppcheck logs.
When changing the width we got a division by zero crash because we
did not consider the case of bpp * bitspp being less than 8.
To fix this we check if bitspp is less than 8 and in that case multiply
the amount of bytes by 8 and then divide by the number of bits per
pixel.
When building using MSYS2 CLANG64 profile using clang 16, we get the
following error (besides other required patches):
../../gimp/app/widgets/gimpwidgets-utils.c:931:12: error: incompatible
pointer to integer conversion returning 'HGDIOBJ' (aka 'void *') from a
function with result type 'guint32' (aka 'unsigned int')
[-Wint-conversion]
For now, let's use the same GPOINTER_TO_INT macro we use in
gimpprogressbar.c. In the end, we need a 64-bit type available to
plug-ins, but that needs more work.
Resolves issue #9809, fix by @mareroqpoland.
When "Separate Layer" is selected, the entire drawable is always
filled rather than using the selection. This patch uses the selection
instead (which will be "all" if there is no active selection)
Looking further, the @help is only used in gimp_proc_view_new() so far (for the
Procedure Browser) where the blurb and argument descriptions are already
localized. It makes no sense to only keep this in English. So let's ask to have
both arguments translated.
Now clearly we should not ask for @help to be mandatory. Very often, it makes no
sense to have a longer help string (the small blurb and the few arguments may be
very self-explanatory). So I make this argument nullable.
There is only the @help_id which I wonder if we could not have a simpler
function gimp_procedure_set_documentation_uri(). Indeed while having a unified
infrastructure with a XML summary and help IDs and whatelse makes sense for GIMP
as a whole, I think that many third-party plug-ins would work much better with a
very simple direct URL. Or it could even be a GFile to a local file (for
plug-ins which want to embed their documentation in the plug-in folder for
instance). To be continued…
I add a new class method deserialize_create() to GimpConfigInterface which
returns the GimpConfig object per deserialization, instead of modifying an
existing bare object.
This matters for cases like our GimpResource (and later our GimpItem) classes
which are fully managed by libgimp and should be unique objects per actual
resource. It should even be possible to compare the pointer itself for identity.
That's why we need to let GimpResource create the object (in reality request it
to the infra and only ref it) through this new class method.
With this commit and the previous ones, all GimpResource are now properly stored
as plug-in settings (e.g. the "film" plug-in has a font setting which is now
properly remembered).
These identifiers are not portable (across various installations and therefore
not for XCF either), but at least they are reasonably identifying data on a same
installation (unlike GimpResource's int ID which is only valid within a single
session) which makes them very fine for plug-in settings storage.
When a data file disappears, we fallback to the context default data instead.
This finds the core resource knowing its type, name, collection and internal
state (in other words, the values returned by _gimp_resource_get_identifiers()).
The way we were creating a GimpData identifier was simply wrong, because it was
based on the assumption that the source file uniquely identifies a GimpData (cf.
gimp_tagged_get_identifier() which clearly says that the returned string must
uniquely identify this data). The very simple counter-examples for why this is
a mistake to consider a data file to be a good unique identifier are collection
files. For instance, TTC files (TrueType Collection) contain multiple fonts.
Instead I am adding the concept of "collection" with the assumption that
**within a given collection**, data names are unique (I do hope this to be and
stay true). So I add gimp_data_get_identifiers() and gimp_data_identify() to get
identifiers and check for identity.
The collection will use the old implementation of gimp_data_get_identifier()
because it is quite nice to have paths relative to data and config directories
(it allows some cases of data relocation without losing data identification).
The new implementation to compute a GimpTagged identifier on the other hand will
construct a string from the quality of being internal or not, the data name and
its collection.
Rather than reimplementing the same checks for every possible resource data
type, just do it once and redirect to the correct factory container.
For the libgimp API, we leave per-type functions `gimp_*_get_by_name()` (where *
can be brush|gradient|font|palette|pattern so far), but internally they all use
gimp_pdb_get_resource().
Note that eventually we want these functions to return a list of resources as it
should be possible to have several resources of a given type with the same name
(since they are made by third-party who might have had the same idea of a name).
… fails.
This happens for plug-in settings storage. Serialization stops at first failed
property serialization, whereas we could store more. This feels like the last
settings feature is broken.
(except from the aliases "Sans-serif", "Serif" and "Monospace")
The code to get the file path was inspired by code in MR !1011 by Idriss Fekir.
My initial idea was to use FcFreeTypeQueryAll() when adding each font
individually through FcConfigAppFontAddFile() but we were only doing this for
our additional directories (not the system ones) and also before we actually
loaded all the fonts through FontConfig. So this would have required more work
to get right. Though it also means that now the ! USE_FONTCONFIG_DIRECTLY code
path is more broken than ever (as we consider this path information quite
important for plug-ins now).
Additionally to make this work, I got rid of the code making all GimpFont
objects internal data by default, which is nonsense to begin with. Fonts are not
writable by GIMP, sure, yet they are external to GIMP and loaded from a file!
This will be important for an upcoming commit (which is currently in a branch
related to issues #50 and #9250), where we want to implement GimpResource
storage as plug-in settings, because fonts were the only GimpData without a file
and we are using this information to generate a collection identifier.
Note that there is a `container_obsolete` too in GimpDataFactory and I don't
apply the "unique-name" property to it because I'm unsure what it is.
Furthermore, eventually we'll want all types of data to allow duplicate names
(brushes, patterns or whatnot may come from all sources and may be named the
same by different people). But for now, let's focus on fonts before breaking
other parts of the codebase which we might not look into right now.
… the GIMP_DEBUG_FONTS environment variable is set.
Turns out nearly a thousand font files get ignored on my installation (and I
don't install much; a lot of them seem to be bitmap fonts (PCF) in a X11
directory). I still want output so that this topic doesn't get forgotten and
hopefully some day, we can do better. But a single line on stderr (and an
environment variable for details) is enough for now.
Remap font names to unique generated names
so that pango sees them.
keep the font name for display and the internal
name for everything else.
* Fonts are still broken When exporting to pdf
* Not sure if xcf files would be usable on other systems
maybe use hash of psname internally instead
* Not sure if plug-ins using text layer work correctly
(do they use internal font name or the actual name?)
This is definitely not core type material. Also it's much better in the proper
header gimpimage-snap.h and the type name should reflect the file namespace,
especially as we make it public.
When using airbrush tool, if the layer has a offset, then the offset was
applied to the the coords multiple times creating a series of dots when
holding the airbrush still (from the gimp_airbrush_stamp function).
Fixed this problem by storing the original value of coords before it
gets updated.
Inline completion is case sensitive, this makes it
broken, because fonts desplayed in the pop should be
quried in a case-insensitive manner.
This fixes #2832.
See gtk issue #275.
We use US English which uses behavior. So we replace all occurrences of
behaviour.
Most notable is File Open behavior in preferences. Besides that several
mentions in function documentation and a few in comments.
...the tab itself. Noted by @user062. This adds a right margin to the
close button on the image tabs so that the tab size is pushed out
to fit the button.
Use the dedicated function rather than comparing strings.
Because of this, menu items for the "windows-display-*" actions were not
destroyed, neither were the relevant images because the proxy menu item was
keeping a reference to the image (for the small in-menu preview in Windows
menu).
It's nearly the same list of placeholders which will make it easier to
third-party developers (though format still changed, devs will have to add
square brackets for section names).
Now some section names are missing because we would need to break some list into
smaller sections yet want to avoid having separators everywhere. This makes me
wonder if removing my first placeholder implementation was the right idea.
Anyway this new implementation is cleaner and we should find a way to add
sub-sections without creating separators in menus.
Also I didn't try to add new section names (though I did once or twice, e.g. a
"Close" section around quit/close actions which didn't exist) but eventually we
should. Being able to name logically parts of the menus will make them even more
organized (if we can't name a group of actions, it may mean we didn't think
properly the organization and order).
Per @ajonsson, gettext does not like < or > used as symbols
and throws a warning. They are replaced with HTML entities
< and > to prevent the problem.
These should be hidden on stable releases and shown on unstable branch. But
we'll also want to show these in the stable branch, outside of release
(typically when we'll be at 3.0.1).
The combo box button is contained within a box element.
The box was also having its background-color set,
so there were small square "corners" around each dropdown menu.
This patch separates the box color from the button color to prevent
this.
"Windows" and "Help" should always be last. New top-level menus (created by
plug-ins, scripts or GEGL ops) will be appended in the order of creation between
"Filters" and "Windows" menus.
There were some mixups between a few representations of menus:
* "_Some Menu" and "Some Menu" should both map to an existing submenu "Some
Menu" (in the GimpMenuModel, the stored path doesn't contain mnemonic).
* The menu item on the other hand should contain the mnemonic and not lose it.
* Not only this, but "Some _Menu" should still map to the same menu, even if it
was already created with a different mnemonic. It means that the first
registered menmonic "wins", as we don't want duplicate submenus with same
title (even if they have different mnemonics).
So this new code is better handling the canonical menu path (no mnemonic, no
section name, no double slashes, no trailing slashes, etc.) vs. the
canonical-with-mnemonic menu path to avoid weird duplicates.
Some additional bugs are fixed where we were creating weird empty submenus
containing the same items as the parent menu as well, or when a submenu title
was a perfect prefix of another submenu title at the same level.
File/Quit, Edit/Preferences|Input Devices|Keyboard Shortcuts should not be in
the main menu bar on macOS because they are already in the "app menu".
See #9322.
- Remove the wiki which is now dead.
- Update the roadmap link and title it in plural.
- Move the "Bug Reports and Feature Requests" inside "GIMP Online/" submenu.
I'm not sure what's the default for random string attribute, but better be
explicit anyway. I think this way, we make sure that gettext won't try and
translate these.
This removes a bunch of inconsistencies we had from the before-2.99.16 version
because new items from plug-ins were all added at the bottom of their respective
submenu.
This will replace the "placeholder" concept where I was using an invisible item
with a label and no action, making it invisible. Instead let's just name
(internally) our sections. This has the following advantages:
* Conceptually more correct: basically we just want to place items among the
same category of actions.
* Easier to search for plug-in developers who'll want to place their plug-in
procedures in menus, because it uses an actually searchable attribute
("section-name").
This is used by the core by allowing a special syntax in menu paths: if finished
by "/[Section]" then the item will be place in the specific section named
"Section". In case one actually wanted to create a submenu called "[Section]",
they can use a double bracket: "[[Section]" and "[[Section]]" will both map to a
normal submenu (not a section name) titled "[Section]".
All other usage of square brackets will not be processed in a particular way.
E.g. "Hello [World]" will end a submenu titled "Hello [World]" or "Bye]" will be
a submenu and so on.
Finally this system is currently limited to the position of the item itself,
i.e. must be placed as last element in the path. In particular, you currently
cannot use it to position a new submenu inside a section. E.g. say that I want
to create a submenu "From Platforms" under the "Open" section of the File/ menu.
This is currently impossible. With this syntax, we can create new items directly
in the "Open" section, or create a "From Platforms" submenu in the end of the
File/ menu, containing our new procedures.
This could be a good improvement to come.
Sphere-designer: Since some of the strings are translated versions, we
can't know in advance how long they are going to be.
Let's use string copy/cat functions that explicitly check the size and
are guaranteed to add a NULL.
- Add modern error handling using GError.
- Check return values of fseek and fgetc for errors.
- Remove most occurrences of g(u)long.
- Fixed overflow issue with maxred/green/blue found with coverity.
I noticed this in coverity. I couldn't find any actual script using
SF_DISPLAY, so the impact probably isn't very big.
Because the enums start at 0, the size of the array should be at least
one more than the value of the last enum, which was not the case here.
Increase the size of the array by 1, so that accessing SF_DISPLAY,
which is the enum with the highest value, is valid.
Resolves #5742.
The check is for a horizontal line (where the Y coordinate
would be the same for all three points), but the X axis was
checked instead due to a copy/paste error.
Resources are stored by the plug-in infrastructure and their memory should not
be managed by plug-in code.
My commit 4f69995b46 was crappy and modified a generated function. I was just
too tired with all the heat in here, I guess!
Similarly to how we handled image items, all resources are handled and stored by
the plug-in infrastructure and should not be destroyed. This wrong annotation
was triggering bindings to unref resources when going out of scope, hence
crashing plug-ins.
Note that in the future, we expect this to be possible to create other brushes
with a same name. Maybe we should have a special function allowing to request
core resources (the ones installed by GIMP itself).
Adding unsupported messages was overwriting the old message without
first freeing it. In addition, the first message was initialized
as a string constant.
We now start with duplicating the (empty) string, so that it can be
freed. We then add a define to reduce boilerplate to add the string
for each unsupported feature. The code in this define takes care of
adding the new message and freeing the old message.
Make sure we use gsize for intermediate results to not get integer
overflow on large image sizes.
This still is not ideal, but better than a crash, since we may (try to)
allocate a very large block of memory, which we should eventually fix
by looping over smaller size buffers.
Brushes can't be large enough to actually cause overflow here, but
since the result is gsize, it can't hurt to have the intermediate
results to gsize too.
Though I didn't encounter this bug in my commit 54b22c717a, 2 unit tests are now
failing with:
> Bail out! Gimp-Widgets-FATAL-CRITICAL: gimp_ui_manager_update: assertion 'GIMP_IS_UI_MANAGER (manager)' failed
I am assuming this is a consequence of this code I just changed.
This GTK widget code could be reach from a thread calling gimp_image_flush().
Yet all GUI-related code must happen in the main thread (also even though
actions are not GTK code anymore, they can trigger GUI updates).
No issue happened from this so far (that we know of), but a trace by SBDaule for
their growing layer project showed that we'd reach this code if calling
gimp_image_flush() from the paint thread.
It looks like we left out the multiplication by 3 when passing the
colormap size to get to the number of bytes in commit 89c359ce
This fixes a crash when saving an XPM file
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/9711
After 59cb3e36, the GimpOverlayFrame that contains
the on-canvas text editor is still partially visible as a dot.
This patch now hides and shows that as well based on
the "Show On-Canvas Editor" option.
Resolves #9676.
Per @pixelmixer and @programmer_ceds's research,
setting the color attribute on the switch's image children
removes the 1/0 labels on non-System themes.
This was introduced in commit 95fa902827. Unfortunately Gitlab web UI is really
not good at showing indentation issues (or any other space coding style issues,
for that matter).
This results in an infinite loop and there is no change done, so no reason to
flush anything. Mitch had a fix for this (probably the same, per the IRC
discussion), but I really wanted to just release GIMP 2.99.16. So Mitch, if you
read this, sorry for not waiting for you to push this one!
We already search for a compatible Python version in the root meson file, no
need to look up Python 3 again in the PATH, each time we run an external Python
script in the build.
This should hopefully fix #9687.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/9653#note_1780587
Looking at MSYS2 logs, it looks like they very recently "fixed" the search paths
for lua files, which in turn broke our workaround (searching in subdirectories
of bin/ instead of share/ and lib/).
This should work better (though untested) with the workaround removed now.
Commit on luajit package at MSYS2:
703c7bae2f
In commit 48c27770 some unicode related changes were made. As a result of
that on Windows display_device, which was previously a duplicated string,
is now referenced directly.
However, the g_free was not removed, causing a crash.
We resolve this by removing the obsolete g_free.
Switching to the cfitsio library's fits_read_img () function in 03ea666f
caused RGB FITS images to be read in upside down per SiriL developers and
NASA standards (odd, since cfitsio is maintained by NASA). This flips them back.
The Microsoft style guide and other places online suggest that using a
hyphen is recommended between a number and the related word, when modifying
a noun, so let's do that in our Image -> Encoding submenu too.
The developers of SiriL sent me some RGB FITS images that rendered incorrectly
after d4f42076. These must be read in as
planes rather than individual rows.
The creation of the BMP welcome images for the Windows installer (part of
-Dwindows-installer=true build option) fails in the Windows job. After much
debugging, I could run GIMP, yet it was not enough. One of my hypothesis so far
is that the environment variables for DLLs won't work, since all the DLLs must
be in the same directory as the main binary (though with the WSL thing, I am
unsure, maybe it is still supposed to work), which only happens once GIMP is
installed. So GIMP runs successfully but not plug-ins.
Anyway I wasted too much time working on this and without a local Windows, it
just takes too long (mostly testing thanks to the CI) and is frustrating. Let's
just move to building both the localization files and the images on the main
Debian job (gimp-meson-debian), then use these as dependencies of the
win-installer-nightly job, i.e. when building the installer.
The common order logic for list of directories in environment variables is that
left paths have precedence. This is at least the case for LD_LIBRARY_PATH (and
probably GI_TYPELIB_PATH too).
Make sure that our local libraries and introspected binaries (in the build
directory) are used and not any version installed on the system or by previous
`ninja install` calls.
This was a first attempt at fixing this error on the CI:
> Cannot open display:
Though it was not enough (see next commit calling plug-ins as non-interactive
when called without interface), it is still a useful change overall.
We had the following warning:
In function 'make_remap_table',
inlined from 'gimp_image_convert_indexed' at
../../gimp/app/core/gimpimage-convert-indexed.c:1057:7:
D:/msys64/mingw64/include/glib-2.0/glib/gmem.h:261:19: warning: argument 1
range [18446744071562067968, 18446744073709551615] exceeds maximum object
size 9223372036854775807 [-Walloc-size-larger-than=]
This is apparently caused by inlining in combination with using a signed
int.
See also: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=85783
Casting to (guint) silences the warning here.
… being installed.
There is already most of the main code logic for this, though now plug-ins need
to be in their own subdirectories, which breaks for plug-ins/common/ and
plug-ins/python/, while I needed plug-ins in both these categories to generate
the Windows installer welcome images (file-png, and python-fu-eval in
particular).
Once again, meson was not very helpful, since all its functions still refuse to
output generated files in subdirectories, so I end up duplicating plug-in files
with a custom Python script.
This should fix the CI. It was working on my machine as GIMP was installed, but
such a build rule should work even without GIMP installed.
This will also be useful in the future when we'll want to run unit tests of
plug-ins through the finale GIMP binary itself.
After discussion with Jernej, InnoSetup should now work better with rescaling
a big image properly to the window size, yet the ratio should still matter.
Apparently the welcome image is a hack and this is why it requires specific
ratio images. We don't use the big size yet, but since Jernej told me which
dimensions are expected, I already added the code for it to make it easier
later.
So anyway this code would allow us not to have to commit welcome images each
time, which are basically resized copy in BMP of the splash screen, slowly yet
surely filling up our repository with image duplicates.
After all, we develop a scriptable image editor! We should use it to edit images
and export in expected formats!
I only use this script for the devel installer for now, for testing and see how
it goes.
While some packages may be needed only when building (and others only when
packaging), we should probably have a shared list of packages needed for both
steps so that we avoid discrepancies which lead to missing libraries in our
installer.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/9653#note_1777596
Even though it's just for 3 dots, this may actually be formatted differently in
different languages. Let's not assume we all share this punctuation mark.
Fixes several missing declaration warnings because in fact of missing include,
such as:
> warning: no previous declaration for ‘console_editor_new’ [-Wmissing-declarations]
Fixes 2 old-style definitions:
> warning: old-style function definition [-Wold-style-definition]
The previous commit did fix one such reason (multiple separators next to each
other), but I realized there is one other case where single separators are just
too big: when the menu is embedded in a GtkHeaderBar, each separator would have
a weird margin of several pixels (at least in my case, probably taken from the
underlying system theme). And worse, this margin was using another background
color.
So anyway this CSS rules takes care of not adding weird margins to menu
separators.
Resolves issue with #8461.
This provides a conditional value for the fill options to only show
a color and pattern, rather than fore/background colors.
Currently only used for the text editor.
Though not a bug, this change will get rid of the following warning:
> app/dialogs/module-dialog.c:291:28: warning: ‘location’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> 291 | text[INFO_LOCATION] = gimp_module_is_on_disk (module) ?
… to long format of unit names.
We can clearly see that the main part of the widget is correctly resized but not
the popup. Unfortunately we don't have access to the popup widget which is
private data, so the best workaround I found so far was to pop the menu down and
up, which basically provokes a redraw to the correct size after contents change.
This fixes MR !385.
There was a bug in commit ca6b58e970 which went under the radar. The gimp
variable was not set at creation, so this line was crashing:
> container = gimp_data_factory_get_container (text->gimp->pattern_factory);
Since MR !706, (style solid) doesn't exist anymore which makes gimprc parsing
fails (hence losing configuration).
This fixes:
> Gimp-Config-Message: 21:20:21.018: Error while parsing '/home/jehan/.config/GIMP/2.99/gimprc' in line 18: invalid value 'solid' for token style
> Gimp-Config-Message: 21:20:21.018: There was an error parsing your 'gimprc' file. Default values will be used. A backup of your configuration has been created at '/home/jehan/.config/GIMP/2.99/gimprc~'.
Replaces "Solid Colors" option in Fill Path with Foreground/Background
Colors options. This allows users to fill with either, rather than
having to switch the foreground color each time.
GIMP_CONTEXT_PROP_MASK_BACKGROUND was added to the fill and stroke
contexts to allow the background color to be recognized.
In places where Solid Color was used as a default, Foreground Color is
now used instead.
In our use case it is necessary to save the transform matrix, and the
easiest solution is to make the label selectable. If we print the
whole matrix into a single label, formatted with tabs and linefeeds,
then the whole matrix can be copied with a single operation.
This adds a new boolean to text options, "Show on-canvas editor".
When toggled, it immediately hides (or re-shows) the current
text layer's on-canvas text editor.
It uses the same signal and function as the "use-editor" property.
With more recent logic, not all actions are inside the application's action map.
We need to look up actions in our GimpUIManager.
This fixes failing to find the actions with the "text-editor." prefix (in the
text tool editor's toolbar).
Resolves #9636.
gimp_object_get_name (gimp_display_get_image (display)) returns NULL
instead of the filename. documents_raise_display was changed to call
gimp_image_get_imported_file () or gimp_image_get_file() instead to
get the actual filename.
When porting depth-merge to GimpPlugin in 5154b271 the return statements
were not fully replicated. As a result, the depth-merge function was
called even if the dialogue had been cancelled.
This patch adds the missing return statements to prevent this.
Half of the smaller dimension seem a better value, since once we reach any half,
it means we will compute using all pixels anyway. Any width higher than this is
useless.
Adds a check to cast resolution to an int if units are pixels,
rather than calling gimp_unit_get_scaled_digits().
This prevents a LibGimp-CRITICAL about "_gimp_unit_cache_get_digits:
assertion 'unit >= GIMP_UNIT_INCH' failed"
Since commit 89c359ce47, it's supposed to return a GBytes, yet it was returning
raw data (probably intermediate hacking state which was not properly cleaned
up).
It was crashing for instance GimpDrawablePreview widgets at drawing time.
Partially resolves #7211.
plug-in-ripple is a wrapper for the GEGL ripple effect. GEGL allows for
double values for period and amplitude, while the GIMP PDB only allows
integers. This patch aligns the datatypes.
Note that Angle and Phi are still limited to the current design.
For all the test-ops thus far in gegl, gimp:menu-label has been
the same as title + "..", to keep the number of duplicate strings
that need to be translated and the number of needed boiler-plate
lines of meta-data in GEGL down, this is the default behavior when
a title key exists.
The checkbox label wasn't included the :hover CSS, so its background
color didn't change. This created a "box" around the label without the
highlight color when the mouse was over it.
My previous commit was improving the case where we just get many "dirty" signals
and successful inhibition. But if the inhibition request was failing, we would
just retry again and again.
This new version will hold off on on requesting the inhibition for the next 10
minutes. Then it will try again, in case the failure reason might have been
temporary.
… the reason message changes (i.e. when number of dirty image changes).
Some actions in particular would trigger several "dirty" signals, there is no
reason to uninhibit then re-inhibit repeatedly. And as a more general rule,
there is no reason to do so even for different actions while we are not planning
to update the inhibition reason.
It may not be the main reason for #9446 (because if it hangs for several
minutes, there is likely something going on, deeper at the dbus call level), yet
it would definitely alleviate the issue (dividing the wait by as many times as
the dirty signal was emitted!).
The RGB histogram shows three histograms overlaid on each other.
This multiples the pixel and count attributes by 3. To correct this,
the result of gimp_histogram_get_count () is divided by 3 for the
pixel and count displays.
Resolves #414.
Currently GIMP only loads the palette colors used in a GIF, discarding
the rest. This can cause issues when a consistent palette is required
(e.g. a video game sprite or background).
This patch uses either the global or local GIF max palette value to set
the colormap size, thus retaining the full palette on import.
Rename fields of ConsoleInterface more desciptive
Add c,h files for object editor and history
Extract object ConsoleEditor
Extract object ConsoleHistory
Extract TotalHistory methods
As @bootchk noted, gimp-file-load-layers does not check the result of
file_open_layers () but the final return variable
which is always NULL at this point in the function.
This patch corrects the problem so it checks the proper variable.
The order of GIMP_PROCEDURE_SENSITIVE_DRAWABLE |
GIMP_PROCEDURE_SENSITIVE_DRAWABLES was reversed in
gimp_procedure_set_sensitivity_mask (), which caused scripts using
SF_ONE_OR_MORE_DRAWABLE to crash.
… the main instance.
Note that it doesn't say if the batch command succeded, only if they were
successfuly communicated to the main process for processing.
When passing an application ID (which is necessary for application inhibition to
work, i.e. logoff/reboot/shutdown inhibition), GApplication will try to ensure
process uniqueness, which will trigger a new activation to an already running
process. Since our current code assumes that the application can be activated a
single time only, this was what was triggering a whole lot of errors (on the
first running process) in #9598 because there was all the initialization code
which ran again, whereas it was not supposed to.
This doubly-running initialization code was also what completely messed up the
session files, hence broke the GUI after a restart (#9599).
Therefore passing G_APPLICATION_NON_UNIQUE advertizes we don't want GIO to
handle process uniqueness for us.
Note that this is actually a very interesting feature which we have had in GIMP
codebase forever. It would be interesting to kill all our own uniqueness code in
favor of GIO code (and let them handle/maintain passing command line arguments
from one process to another, for all possible platforms). So I added a TODO for
this (for now, we just ignore this feature as it doesn't work well with current
codebase).
Additionally to the F1 shortcut, a secondary icon is now shown in the
action search entry. It works exactly the same as F1, i.e. that by
default, it shows the action search manual page (when nothing is
selected), or the manual page for the specific action currently selected
otherwise.
The default F1 result (if no action is selected) is to show the generic
help page for the action search. If an action is selected, it will show
the specific help for this action.
Since we are already building a static (build-only) libapp, to be used with
tests or tools, let's also use it for the main (GUI) executable.
For the CLI executable though (gimp-console-2.99), we must re-compile
libapp_sources from scratch anyway, because we define the additional macro
'GIMP_CONSOLE_COMPILATION'.
While Debian testing is the sensible choice for dependency requirements while we
are in full-dev mode, now we are getting closer to 3.0 release, and Debian 12
"bookworm" barely got out.
If we continue to develop at current pace, GIMP 3.0 should be released before
the next stable Debian, so we should not use dependencies unavailable on the
latest stable (otherwise GIMP 3.0 won't be distributable soon enough on Debian,
nor on Debian derivatives such as Ubuntu, Mint, etc.).
This is why we are now basing GIMP dependency requirement on Debian bookworm.
We'll likely get back to the next "testing" after GIMP 3.0 release.
Now that we don't blindly generate a messy list of all non-special cased actions
in Filters > GEGL Operations, "GEGL Graph" is all alone in this submenu. It just
makes sense to bring it back to the Generic submenus where it used to be.
Instead of unconditionally add all the non-special-cased GEGL operations into
the menu, only insert the ones which explicitly use the new "gimp:menu-path"
GEGL key.
See new operation "gegl:adaptive-threshold" added in commit 7c2a70eee for such
an example.
Note that the other operations will still get their own generated action (which
means for instance that you can still search them through the action search and
that you can create custom shortcuts for your favorite actions). But now you
won't get an overlong generic list of non-organized actions in a single submenu.
Some people were finding this messy when they had a lot of custom GEGL ops.
Also it means that GIMP doesn't assume that any custom GEGL op is usable in
GIMP. Indeed some ops are really not meant to be used as filters, which is why
we have the gimp_gegl_op_blacklisted() internal function; but this cannot apply
to custom operations. Therefore from now on, instead of GIMP guessing, operation
developers will have the say on whether their op should show in menus and in
which menu path exactly!
Moreover the "gimp:menu-label" key will be used as short label, i.e. the label
which is used in menus in particular, where the menu path is a helpful context
(hence allowing to use shorter menu labels).
The main "title" will still be used as long label, for places where there is no
such context, for instance the action search.
When reverting commit d51c64ec06 and reimplementing as fa2e9adc29, the code to
make sure the generated per-op action name is unique disappeared. This code
ensures that the action name is indeed unique, otherwise the action will
override a previously registed action, which could be made from a plug-in, or
even by another GEGL operation. Indeed, while GEGL operation names are supposed
to be unique, they are post-processed to be valid GIO action names. So it is
totally possible to have 2 GEGL ops with different GEGL names, yet the same
GAction name.
8bpp and below ICO formats use a 1 bit mask for transparency.
When imported the mask is treated as an additional transparent color.
If the icon used the max palette (e.g. 2 colors for a 1bit icon),
the default export format will become larger than necessary.
This checks if the layer still has 1 bit alpha, and subtracts the
mask color from the count.
This patch does the following things:
- An option "Merge menu and title bar" (this is hopefully more understandable
than calling it "Client-side decoration" or again "header bar") is added in
Preferences > Image Windows. This option triggers the restart warning.
Moreover when checked a small warning message will tell that in some cases, it
may not work (there are feedbacks of people having 2 title bars when using GTK
applications using CSD).
- For the reason evoked above (sometimes 2 title bars) and also because the CSD
concept seem really to divide people a lot (some love this as much as others
hate this), this new option "custom-title-bar" on GimpGuiConfig is FALSE by
default.
- When the option is checked, the image windows will use a GTK header bar
containing the menu, the window title (image name and information) as well as
the usual minimize/maximize/close buttons per your OS conventions.
- Since the header bar is set to be hidden when maximizing, if you checked "Show
menubar" for the "Default Appearance in Fullscreen Mode" in Preferences >
Image Windows > Appearance, the menu will be moved to its "old style"
position, i.e. above the canvas. This makes the menu possibly visible (if
relevant option is checked) even in fullscreen mode.
- I tweaked the Default theme to show the header bar with minimal height,
because I find GTK default theme's headerbar height unreasonably high
(especially if the point of the header bar is to save screen space). I am
unsure if this was the right move though, because maybe the default theme
should not do such choices (maybe this should go in the Compact theme?).
I don't see a reason why the quick mask menu was sharing the same
manager as the image menu (the main top menu and on-canvas). This was
why it was receiving all notifications to create menu items on <Image>,
as registered by plug-ins.
Giving it its dedicated manager makes sure this doesn't happen.
This reverts commit 3a35974e3a.
This is not the right fix for the issue (which was happening on the
Quick Mask menu specifically) because root menu models are set with a
NULL path. So forbidding root menu models to handle new subpath means
preventing plug-ins to register new top-level menus.
The correct fix for the issue on the quick mask menu will happen in a
coming commit.
See issue #9586.
In commits a6756b515b and 23da44e3c8, newer API of librsvg were used, over our
current minimum requirement. The reason why we don't bump this requirement is
that librsvg 2.40.x are the latest versions which are full-C. While we have
nothing against Rust, it is not available on all existing platforms, and we
really want to have GIMP buildable everywhere, while also have SVG support
always present (even though it's a vector format, it's an important one in
graphics work nowadays).
See issue #6821.
So in the end, let's keep the old minimum requirement, but test against librsvg
version to compiler either with old API or new one. The changes are limited
enough that it's not too much a bother.
...trying to get the index. Resolve #9568.
The color picker tool calls this twice if you're in Add to Palette mode,
and the editor's color may not be set the first time it's run.
This adds a check to ensure the color is set before trying to retrieve
it from the palette to prevent a CRITICAL.
Don't set both a branch and a commit, otherwise flatpak-builder will
compare the HEAD of this branch (which may evolve with the commit).
Fixes:
> Failed to download sources: module qoi: Git commit for branch master is dfc056e813c98d307238d35f7f041a725d699dfc, but expected f6dffaf1e8170cdd79945a4fb60f6403e447e020
The layer resize to selection and crop to content menu commands were
using the same help ids. This made it difficult to have them both listed
separately in the index of the manual.
Since we use separate help ids everywhere else for menu commands, let's
give each its own help id here too.
Though this doesn't make a problem in normal use (AFAICS), we have crash
in a unit test in CI because the action_factory object was apparently
invalid when calling gimp_action_factory_delete_group().
Because of this, the script was failing to get the version string, which
in turn was breaking InnoSetup.
This fixes the following InnoSetup bug:
> Error on line 116 in C:\_r\_builds\k3_3muaB\0\GNOME\gimp\build\windows\installer\gimp3264.iss: Value of [Setup] section directive "VersionInfoVersion" is invalid.
This commit makes no real changes but style.
As discussed, this makes it much easier to compare commit diffs, rather
than an overlong line where you have to search which package may have
been added/removed/changed.
Resolves #9560.
The Simulation Intent and BPC widgets in the Preference Dialogue needed
to be connected to their properties with `gimp_prop_*` when created to
show the saved default image values.
It does absolutely nothing except sitting there, providing an is-a
relation (both ways because GimpData is its only subclass). This will
simplify having more libgimp API on GimpResource, without having to
add different PDB code for app and libgimp.
This replaces the various GimpHSV/GimpCMYK .aco palette conversions with
Babl.
As a result, it now possible to support importing CIE Lab palettes
(colorspace 7)
Much like for images and items. Change the PDB to transmit IDs
instead of names for brush, pattern etc. and refactor a whole
lot of libgimp code to deal with it.
modified: libgimp/gimpplugin-private.h
The Extensions dialogue assumed that it had a header bar. Since this is
not always the case, conditional checks were added to prevent
GtkHeaderBar code from running. This also fixes a crash when you
double-click to expand the extension description.
The name of the nl-filter plug-in in the manual was recently changed to be
more in line with its description.
Since that is already the name of the plug-in file here, let's also update
the name of PLUG_IN_PROC to be in line with this.
Use g_idle_add() instead of g_timeout_add(300ms), which makes
it respond instantly, while still keeping the actual zoom
call out of the slider callback.
Fixes #9500
By doing `gimp_display_shell_pointer_grab()`, we actually prevent events
from a tablet coming through. There doesn't seem to be a reason to use
it and it's not regressing in functionality either, so let's just remove
it.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/8016
Some images have Exif.Photo.PixelXDimension and Exif.Photo.PixelYDimension
metadata tags in addition to Exif.Image.ImageWidth and
Exif.Image.ImageHeight (mainly tiff images). So far, we were not updating
these optional tags, meaning they could get out-of-sync with the actual
dimensions when resizing and then exporting the image.
Since these tags are non essential, we will only update them if they are
already present.
This way we handle all kinds of proxies (particularly buttons).
Also add a small hack that prevents extended multiline tooltips of
GimpButton from being overwritten by gimp_action_update_proxy_tooltip().
If "data" is a GimpItemTreeView or a GimpImageEditor, we REALLY want
only the image from these dialogs, even if NULL, and NOT some other
image from a display or context that randomly is around anyway. Fixes
the sensitivity states of lots of buttons in these dialogs.
According to the ::drag-drop GTK documentation: "The call to gtk_drag_finish()
can be done either directly or in a “drag-data-received” handler which gets
triggered by calling gtk_drag_get_data()"
The GimpToolbox's vbox handling DnD chooses however to do both, the drag-drop
handler is calling gtk_drag_get_data() and invariably calling gtk_drag_finish()
to hint that the DnD operation is ending. While this worked in practice in X11,
This is a harder either/or in Wayland resulting in the transfer being cancelled.
In order to behave better wrt the documentation, and make DnD into the toolbox
work on both X11 and Wayland, avoid the first gtk_drag_finish() if the data is
being requested, and only bail out if no offered target matches what the widget
can handle. The handling done indirectly through gimp_toolbox_dnd_init() and
gimp_dnd_*_dest_add() will take care of finalizing the DnD data transfers
successfully.
Closes: https://gitlab.gnome.org/GNOME/gimp/-/issues/7373
Apparently this has never worked until we refactored our menus, now it
suddenly does but not as originally intended. Simply remove the
accelerator and let only the canvas event handler deal with the Tab
key. Restores 2.10 behavior which was quite ok.
Fixes #9352
distress-selection.scm uses gimp-image-set-active-channel which has been
removed causing script failure when a channel is selected instead of a
layer.
Use the new multi-layer aware gimp-image-set-selected-channels and also
use the gimp-item-id-is-* functions instead of the deprecated
gimp-item-is-* functions.
In GimpLayerTreeView, set the action states using GimpActionGroup
instead of using gimp->app directly to look up the actions ( after
trying to get the Gimp from a NULL GimpContext).
Fixes #9433
What we call "System" theme should have very minimal edits over the
actual system theme. So let's drop all the "font-size" properties (one
"larger" one, but especially the many "smaller" ones).
This means that the "Default" theme also will keep system font size.
This is as discussed with Ville and Liam, the later saying he can barely
read dockable texts because of this.
On the other hand, we use "small" font size as a general rule in the
"Compact" theme, which is especially meant for people who want a compact
theme.
The Default theme may have been a bit too dark. Instead let's have it a
tiny bit lighter (and also foreground color a bit less white).
For now, the old "Default" dark theme doesn't disappear totally and is
moved to a "Darker" theme as we have been discussing and wondering on
whether this is prefered by some people (it is). Aryeom also thought a
darker theme may be a good idea.
Moreover Liam actually thought that losing some of the contrast
(especially with the text a tiny bit less white now) is not desired in
his case where eyes may not be as sharp as they used to. Therefore a
"High Contrast" theme may be needed.
Aryeom also suggested that sliders to choose colors could be a much more
generic solution, which might be possible yet would require more ugly
hacks generating on-the-fly theme changes (we do something similar for
dark theme choice already).
This is all work-in-progress and a result from Wilber Week 2023 work.
… for Windows.
Though it's useless for actually building the GIR files, we still need
this package now, for building script-fu with introspection abilities,
to generate GIMP and GEGL enums.
See the 2 previous commits for more information.
This allows our script-fu plugins to use the GIMP enum values, just like
all our other plug-ins know them.
In other words:
* Names are consistent with those of other plug-ins
* Introspectable enums are automatically added as they are added to the
introspection file, without even needing a recompile
* No need to keep track of our enum types anymore, as that is just a
redundant implementation of introspection in practice. This in turn
will let us simplify some of the pdb code
Currently, patterns are loaded as-is - if the full pattern is larger
than the preview, its cut off and you only see the left corner.
In those cases, the pattern is scaled using gegl_buffer_get ()'s scale
parameter.
and Plug-in/Procedure Browser size.
gtk_widget_set_size_request () is applied to the dialog, as it does not
seem to bubble up from being applied to individual elements.
The existing 2.10 width/height values are used.
getting rid of using the the deprecated pointer grab API.
Since there is something fishy and gtk_get_event_widget(event) always
returns the GtkInvisible we grab on (not the actual event widget), we
just steal the "find widget at pointer" code from gtkinspector and
find the help widget that way.
The height of the boxes was never determined by the preview but by the
label+entry, causing vertical padding around the preview. Now the
preview fills the area in more cases, at the cost of a few less
horizontal pixels for the entry.
gimp_toggle_action_real_toggle(): set "active" before emitting
"change-state" so we don't infinitely try to set the state in case of
a recursion.
gimp_toggle_action_toggle(): add notify("active") because it wasn't
done anywhere.
Fixes #9392
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.
