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.
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.
- 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.
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.
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()
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).
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.
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.
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.
… 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.
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"
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.
In case someone passes a `GtkWidget` rather than a `GtkWindow` as a
parent to a `GimpDialog`, we still have another way of trying to get its
parent window, using `gtk_window_get_toplevel()`. If we still get a
window from that, it allows us to still specify a reasonable
"transient-for" value for our newly-made `GimpDialog`.
Per @Jehan, this solution would prevent default icons from being loaded
in custom themes if they did not include their own version.
The only thing kept from !909 is the replacement of hardcoded strings
in a few files with constants defined in gimpicons.h.
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.
GimpFrame has a property 'line-spacing'. gimp_frame_get_label_spacing ()
tried to access it as 'line_spacing', so it always returned 0.
Fixing the typo should now return the true spacing value.
These were the last use of the old GtkAction API and it was particularly
annoying here as this widget is used both in core GIMP and in plug-ins, yet core
GIMP actions were not GtkAction anymore (so the "activate" signal handler's
signature was different, which would crash the core code).
Now the clash is resolved as this widget just uses GAction (which both
GimpAction, for core code, or GSimpleAction, for plug-ins, are).
This is also the absolute last use of GtkAction (and other related API) in all
our code (core, libgimp* and plug-ins). \o/
In such a case, we may not want to connect to "query-tooltip", yet we still want
the normal tooltip to show up. This was a case for instance for the recently
opened file actions ("file-open-recent-*") or opened image actions which were
not showing their tooltips.
The tooltip contains the reason for action inactivity, if relevant. And in case
of a GtkMenuItem in particular, it will also contain the "Press F1 for more
help" text at the bottom.
RGB 0..255/0..100 and LCh/HSV settings are now remembered when closing
and reopening GIMP.
A few enums were explicitly cast to GimpColorSelectorChannel to clear
some compiler warnings.
There was one case in Inkscape which we could not do: distributing objects
keeping even gaps between them. Until now, we could only distribute keeping even
distance between anchor points (top, left, bottom, right or center).
With these 2 additional distribute options, I believe that GIMP is able to do
all the Alignment and Distribution options available in Inkscape (not the
"Rearrange" or node features, neither the text align/distrib; I just mean the
common align/distribute on objects), and even a bit more thanks to the anchor
point system (e.g. in Inkscape, we can't left or right-align to a reference
object/image center, or we can't center to a reference left/right/bottom/top
border; but we can do it in GIMP).
The icons are hopefully temporary, until we can make better ones.
Just "help" is not one of the standard icon names as per the Freedesktop Icon
Naming specification.
See: https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
Therefore when using this name, we usually don't have any icon (especially as we
don't provide any in our own icon themes).
Use "system-help" instead which is a standard name 'for the “Help” system
category'.
Automake doesn't accept the "if else" syntax. Instead, we must add a new if/else
inside the first else block.
While I'm at it, I also add a G_GNUC_INTERNAL to the internal function
_gimp_pick_button_win32_pick(), though I don't think it's absolutely necessary
(yet explicit is better).
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
Actually our X11 implementation is right, and the implementation from
the Freedesktop portal is "as far as it can do", i.e. that we get the
returned RGB value, which is unfortunately in display space. And it
doesn't return any space information together (we don't even know which
display the color comes from, in multi-display setups).
Therefore let's check if we are running GIMP on X11 and if so, let's
call this implementation first.
See this report on xdg-desktop-portal to get proper space info:
https://github.com/flatpak/xdg-desktop-portal/issues/862
This adds a Soft-Proofing pop-over menu when right-clicking the toggle
in GimpStatusBar. It lets users toggle proofing, using BPC and showing
out-of-gamut colors. It also lets users change the profile and
rendering intent.
Alx Sa