I was trying to avoid too large dialogs as this `metadata` frame can
hold random plug-in settings. But let's go for always the same number as
columns as the max number of common settings (i.e. most often 3
columns).
… org.freedesktop.portal.Desktop (X11 only).
If we don't set this parameter appropriately, the created dialog is not
modal/transient relatively to the main GIMP window. This is especially
annoying because in my tests (GNOME shell), the screenshot dialog would
appear behind GIMP window, which makes it feel like broken behavior.
Note that the supported handles are X11 only so far. We'll need to
generate the appropriate Wayland handles too (created from xdg_foreign
protocol).
Today I have only re-tested the GNOME implementation (in particular not
the KDE one) of the portal API org.freedesktop.portal.Screenshot but I
assume it is similar because the dbus function does not provide any
useful options anyway. This is why the portal comes with its own dialog
providing the various common screenshot features (delay, window picking,
area selection, etc.). Showing our dialog first is therefore redundant.
Also I updated setting the monitor profile only in the case where the
loaded image result from the portal did not have an embedded profile. To
be fair, the GNOME implementation at least does not embed a profile to
this day. So this is only for the future case where they will finally do
the right thing and embed the display profile (or for other desktops'
implementations where they maybe already do the right thing).
This was true in the "old world" where X11 support being built-in meant
that X11 screenshot would be usable. Now we must not only check it is
built, but also that we are actually running under X11. Otherwise with a
Wayland compositor, screenshot would fail. Also it meant that the
Freedesktop portal was never tried if both X11 and Wayland support were
built-in.
Use gtk_widget_list_mnemonic_labels() to look for mnemonic of common GTK
widgets. Also warn when several mnemonic were set on a given widget
("wasting" keys when it seems we are always looking for available
mnemonics).
Also warn with core action IDs too when they miss a mnemonic.
Most important of all, we shouldn't assume that if a given GDK backend
is enabled at compile time, that this is also the one that is being
used. For example, on Linux, both `GDK_WINDOWING_X11` and
`GDK_WINDOWING_WAYLAND` can be set, but you still need to do a runtime
check if you're running under one WM or the the other.
A small cleanup is that we immediately check if a widget is realized by
checking if it's `GdkWindow` is NULL or not and return immediately
(since we need to check its type later on anyway).
Finally, we can remove `GDK_NATIVE_WINDOW_POINTER` as that is a GTK+ 2.0
construct, so it's dead code anyway.
Update `gimp_window_get_native_id()` a little to be more correct
(although it still won't work on Wayland).
Most important of all, we shouldn't assume that if a given GDK backend
is enabled at compile time, that this is also the one that is being
used. For example, on Linux, both `GDK_WINDOWING_X11` and
`GDK_WINDOWING_WAYLAND` can be set, but you still need to do a runtime
check if you're running under one WM or the the other.
A small cleanup is that we immediately check if a widget is realized by
checking if it's `GdkWindow` is NULL or not and return immediately
(since we need to check its type later on anyway).
Finally, we can remove `GDK_NATIVE_WINDOW_POINTER` as that is a GTK+ 2.0
construct, so it's dead code anyway.
Setting the `"transient-for`" property for popups is important to
certain window managers (such as Wayland), so that they know what the
parent surface is and can position the popup accordingly.
This fixes the `GimpTagPopup` in wayland giving a critical message, and
getting a random position somewhere on the screen.
`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.
`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.
This issue is happening on all 4 plug-ins using the new API, it would
seem, but only on Windows.
Looking at stack trace, I believe we might simply be freeing a mutex
twice because dispose() is allowed to be called several times. Let's
make this finalize() code instead (the data freeing we do there looks
much more adapted for finalize() anyway).
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.
Although most GObject bindings can't really deal with struct fields,
it's still a nice thing to be able to see that these are actually arrays
(it also becomes visible in the Vala VAPI file).
Adding names of people with significant contributions:
- Jacob Boerema for his awesome work (on too much stuff to list it all!)
- Daniel Novomesky (HEIF, AVIF support)
- Félix Piédallu (meson build)
- Elad Shahar (Python 3 plug-ins, Spyrogimp, Mandala symmetry
kaleidoscope mode)
Based on other tools wording, as well as the algorithm description. In
any case, it looks a bit better than the previous description (with a
typo even).
In gimp_dialog_factory_register_entry(), strings were passed to gettext
without checking for a NULL pointer. The gettext documentation [1]
points out that that's undefined behavior, and musl libc's
implementation of gettext segfaults in that case.
[1] https://www.gnu.org/software/gettext/manual/gettext.html#Interface-to-gettext
If setting a RGB or Grayscale "preferred" profile, it usually means
these are profiles we are commonly working with, and it is to be
expected that images one might load may already have said profile. In
this case, don't ask what to do with this profile (keep, convert…). The
graphist kind of already answered this by explicitly listing this
profile as a "preferred" one.
Note that I also check for the built-in profile equality, though it
doesn't look like it is useful (gimp_image_get_color_profile() will
return NULL for an imported image which uses the built-in profile).
This is mostly to be thorough.
Daniel Mustieles