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!
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.
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.
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).
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.
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.
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.
...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.
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().
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.
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().
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
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
The height of the boxes was never determined by the preview but by the
label+entry, causing vertical padding around the preview. Now the
preview fills the area in more cases, at the cost of a few less
horizontal pixels for the entry.
gimp_toggle_action_real_toggle(): set "active" before emitting
"change-state" so we don't infinitely try to set the state in case of
a recursion.
gimp_toggle_action_toggle(): add notify("active") because it wasn't
done anywhere.
Fixes#9392
GLib has a specific type for byte arrays: `GBytes` (and it's underlying
GType `G_TYPE_BYTES`).
By using this type, we can avoid having a `GimpUint8Array` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GBytes`, we allow other languages to pass on byte arrays as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with byte arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
Five icons in the Layer dockable were being replaced by GTK defaults at
runtime. A "gimp-" prefix was added so that GIMP's version would always
be used. A few dialogues were fixed to use constants rather than
hardcoding the filename, to make it easier to update the icon in the
future.
