… when appropriate icon failed to be found.
gtk_icon_theme_lookup_icon_for_scale() apparently does all standard
fallbacks, but not the last "image-missing" one which is supposed to
always be present. To avoid crashing, let's add an explicit fallback
ourselves.
We also encountered this on the test-ui unit test because icons are not
installed (but this could happen anyway when running GIMP normally with
third-party icon themes).
When running tests, the data are not meant to be necessarily installed.
Therefore icons won't be found when calling gimp_widgets_init().
Add some special-casing to find them relatively to the install
directory.
… for the container tree view contextual menu.
A very annoying point of contextual menus is that they happen on button
press whereas menu item selection happens on button release. When the
menu corner is positionned on the click position, nothing bad happens;
yet when place is missing on screen, the menu might get positionned over
the pointer position. And worse, the mouse position might be just over
an activatable menu item. So we end up in this weird situation where a
click implies: press, menu opens, release, random item (whatever is
below the pointer) is selected and menu closes.
To get rid of this weird case, let's have our contextual menu happen on
button release. In reality, I don't think anyone cares that it happens
on press or release, you just "click". But what you certainly don't want
is to click random menu items!
To better explain the lock icons, have specific icons instead of reusing
other icons. We also tried to programmatically add the simple lock icon
over the other icons, but we only got ugly render. Better have
custom-made icons.
The gimp-lock icon is the Adwaita system-lock-screen icon, by Jakub
Steiner, simply renamed. Therefore its license is GNU LGPL v3 or
Creative Commons Attribution-Share Alike 3.0.
The other icons are derived from a mix of this same icon and other icons
in our existing set and have the same license too.
Freedesktop (XDG) portals are a collection of D-Bus APIs that work
across desktop environments, display servers and work within
containerized applications, like Flatpak. The internal implementation
can then choose to implement these in such a way that takes into account
security considerations, as well as making sure the user consents to
certain actions.
One such portal is the `Screenshot` portal, which contains a
`Screenshot()` method as well as `PickColor()`. We already use the
former for taking a screenshot, and this commit makes sure our color
picker also makes use of the latter.
By doing this, color picking is now possible on the major Wayland
compositors.
(Honestly, we should remove DE-specific backends like that of KWin, to
have less variation on the possible results of a color picking
operation).
Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/1074
This allows us to simplify some of the dragging logic, and makes us a
tiny bit more future-proof for GTK4, which uses a similar construction
with `GtkEventController`s.
While we're at it, stop storing a separate `priv` pointer, which would
allow us to use `G_DECLARE_DERIVABLE_TYPE()` in the future.
This functions has 2 `(out) (array)` arguments, where the array length
is defined by the return value. This can't be expressed in GIR
annotations unfortunately, so just add it as another `(out)` argument.
Also, by default `(out)` args are assumed to be `(transfer full)`, while
these were actually `(transfer container)`.
The GtkContainer::child signal is deprecated and it's write-only,
thus the notify::child signal won't work.
Use the GtkContainer::add signal instead.
Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/2928
The variables `screen` and `display` are only for the GDK_WINDOWING_X11
code path.
Fixing the following warnings:
libgimpwidgets/gimpwidgetsutils.c: In function 'gimp_monitor_get_color_profile':
libgimpwidgets/gimpwidgetsutils.c:502:21: warning: unused variable 'screen' [-Wunused-variable]
502 | GdkScreen *screen;
| ^~~~~~
libgimpwidgets/gimpwidgetsutils.c:501:21: warning: variable 'display' set but not used [-Wunused-but-set-variable]
501 | GdkDisplay *display;
| ^~~~~~~
Commit 8025962a20 was meant to make the icon code work on relocatable
builds, yet I realize that the gdk_pixbuf_new_from_file() calls were
still using the DATAROOTDIR build-time macro. I had forgotten to update
these.
Also update a bit the error handling by adding a GError (for more
debugging info) and a newline for pretty-printing.
Unit testing consider warnings as criticals and doesn't like when it
cannot find the installed application icons. To fix the `make check`,
just print the missing icon information to stderr, but don't make it a
GLib warning.
While passing the DATADIR macro works fine natively on Linux, it somehow
failed with the mingw-w64 build with a very weird error:
> <command-line>: error: expected identifier or '(' before string constant
I could not understand what it means, as the '-DDATADIR="/some/path"'
syntax is completely fine as far as I can see.
Anyway since I see that DATAROOTDIR is already defined in meson config.h
(but not in the autotools build, just the meson one!), and using
datarootdir instead of datadir seems to be just fine (actually maybe
even more appropriate when it comes to looking up the hicolor
application icons), I just switched to using it.
In the same time, I realized that my code using build-time macros won't
work for relocatable builds anyway. So this commit also adds a bit of
code path variant using gimp_installation_directory() in the case of
ENABLE_RELOCATABLE_RESOURCES code path.
From years of discussions, it turns out that:
- The thumbnailed-Wilber icon replacing the generic icon of GIMP often
makes the application harder to spot in the icon list of running
processes.
- In single-window mode in particular, it makes even less sense as we
just show the one active image anyway.
- Even in multi-window mode, nowadays many OSes or desktop group windows
of a same application under one icon. So we end up with several image
windows under a thumbnail only showing the top image. This happens in
KDE, GNOME, Cinnamon and Windows at least apparently (as far as is
being reported).
- Some platforms would just use only the OS-declared icon and not care
about runtime-declared ones. This is apparently the case on macOS, and
also on GNOME when the desktop file is seen by the desktop
environment. So all our code about generating thumbnailed icon is
wasted on these platform anyway.
- When intensively testing the current behavior, I had cases when the
icon was not properly updated. We could of course investigate and fix
the issues, but considering all the previous points, it might make
more sense to simply drop the feature which is mostly useless, or
worse bothersome, hence simplify the code greatly.
- Finally API to set icons from GdkPixbuf data has been removed in GTK4.
So long term, trying to keep this whole machinery feels like just
making our life difficult for a feature which all OSes seem to
deprecate and which might not be possible anymore soon (or just get
harder and harder to implement).
Note that I don't use gtk_window_set_default_icon_name() because it
would use the icon from our theme, yet so far we are not sure it makes
sense for the application icon which we probably always want to be the
same, whatever the chosen theme. Finally I just list various common icon
sizes because GTK API doesn't seem to be clever enough yet. I can't just
give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file())
and hope it does the resizing at the last minute. It turns out it
doesn't and we get an extra-small icon. So instead, let's generate
common sizes ourselves from the same SVG.
This zoom mode is handled pretty much the same as GIMP_ZOOM_SMOOTH
except that we do not apply adjustments for the scaling delta. Pinch
zooming is ultimately a different physical activity than smooth
scrolling and users likely expect different sensitivity.
… GimpProcedureDialog.
Technically I added:
- New gimp_prop_color_select_new() property widget to create a
GimpColorButton for a given GimpRGB property.
- gimp_procedure_dialog_get_widget() now supports a GimpRGB property and
will create a GimpColorArea by default.
- When the default doesn't suit you, a new function
gimp_procedure_dialog_get_color_widget() allows to create either a
GimpColorArea or a GimpColorButton (editable = TRUE), as well as
choose the area type (small or large checks, as well as flat area,
i.e. no alpha support).
When GIMP_DEBUG=Gtk we can get a warning like
State 0 for GimpChainLine doesn't match state 128 set via
gtk_style_context_set_state () when moving the mouse over
a chain like the one in the Scale Image Dialog.
Let's remove this warning by setting the correct flags by
calling gtk_widget_get_state_flags.
`g_object_notify()` actually takes a global lock to look up the property
by its name, which means there is a performance hit (albeit tiny) every
time this function is called. For this reason, we should try to use
`g_object_notify_by_pspec()` instead.
`g_object_notify()` actually takes a global lock to look up the property
by its name, which means there is a performance hit (albeit tiny) every
time this function is called. For this reason, we should try to use
`g_object_notify_by_pspec()` instead.
When run with GIMP_DEBUG=Gtk we get a lot of debug warnings for GimpRuler and once in a while for GtkScrolledWindow that State 0
doesn't match state 128 set via gtk_style_context_set_state (). This happens because we didn't enter the current state flags of
the widget but 0 and apparently Gtk isn't happy about that.
Let's fix this by using the actual state flags by calling gtk_widget_get_state_flags.
In GTK, a common scheme is to let a function creating a specific widget
to return a `GtkWidget *`, rather than the specific subtype, since you
often need to call API of GtkWidget, avoiding some useless casts.
For bindings however (and especially bindings to compiled languages),
this is a bit annoying, as you have to explicitly change the type of the
return value (downcast), which is not trivial (or at least desirable) in
each language.
Luckily, we can use `(type ...)` annotation for this use case, leaving
the C API unchanged, while improving the experience for bindings.
When creating a label bound to a property, only make the binding
directional if the property is read-write.
This fixes WARNINGs and broken label in the GimpDeviceInfoEditor widget,
such as this one:
> The source object of type GimpDeviceInfo has no writable property called 'vendor-id'
… gimp_label_spin_set_digits() and deleted gimp_prop_opacity_entry_new()
- The "digits" argument for the number of decimal places in
gimp_prop_scale_entry_new() is now mostly useless since GimpLabelSpin
(hence GimpScaleEntry too) got a nice estimation algorithm of sensible
values.
- Add gimp_label_spin_set_digits() function to manually set the digits
property when we don't like the estimated value.
- Also add a new "factor" argument to gimp_prop_scale_entry_new(). Its
role is to allow a GimpScaleEntry showing a factored range, typically
a [0, 100] range for some types of [0, 1] properties.
- Remove gimp_prop_opacity_entry_new() which was basically a
special-case of gimp_prop_scale_entry_new() and which can now be
easily reproduced by simply set factor=100.0.
- Update all usage of gimp_prop_scale_entry_new() in app/ and plug-ins/
with updated arguments. It is interesting to note that all existing
usage were either integers (digits=1) or when double, the estimated
decimal places are the same as the ones which were manually set (hence
showing the generic estimation is not too bad). So the new function
gimp_label_spin_set_digits() was not even needed once in current code.
Similar code was used in 2 places basically (GimpLabelSpin and
GimpProcedureDialog) so just make it an utils function. It's good anyway
to have a generic function to estimate suitable increments and decimal
places depending on a range.
As a consequence also gimp_label_spin_new() now takes a gint digits
(instead of guint), with -1 meaning we want digits computed from the
range.
Similarly gimp_prop_scale_entry_new() docs adds the -1 meaning too.
A -quick done- first step towards the addition of a smart selection tool.
Require the gegl:paint-select workshop operation.
Still LOT of work to do (wip):
- fluctuations removal (GEGL side)
- multilevels pyramid approach + banded graphcut for instant result on large
image (GEGL ? GIMP ?)
- Gaussian Mixtures for color models (GEGL side)
- drawable offsets (GIMP side)
- undo / redo (GIMP side)
- scribbles edition mode (GIMP side)
- dedicated icons
- ...
- New GimpLabelIntWidget which is a label associated to any widget with
an integer "value" property.
- New gimp_procedure_dialog_get_int_combo() which creates a labeled
combo box from an integer property of the GimpProcedureConfig.
- Renamed gimp_procedure_dialog_populate*() with
gimp_procedure_dialog_fill*(). Naming is hard! I hesitated using
_pack() as well (similarly to GtkBox API).
- New gimp_procedure_dialog_fill_flowbox*() functions to create a
GtkFlowBox filled with property widgets (or other container widgets as
we can pack them one in another). This is an alternative way to build
your GUI with sane defaults, with list of property names.
Jehan