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.
Alx Sa