See discussion in !946: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/946#note_1768869
On Windows/macOS, the pad device is probably not even showing at all
right now, though I can't test. Also it could be eventually implemented
with pad actions support (see Luca Bacci comment in the same MR) using
WM_POINTER API on Windows.
On X11 though, the pad device is shown, except it is kind of pointless.
So I am disabling the frame (making it insensitive) and add a tooltip.
Handle some statefulness in actions taking a double parameter, in order
to make them friendly to GtkPadController and its pad ring/strip
integration.
The GtkPadController emits those actions with a double parameter
expressing the absolute value (e.g. 0-360 for rings, 0-1 for strips),
take care of converting these absolute values to relative changes
that increase/decrease the current GimpDoubleAction value.
Going for relative increments/decrements increases the genericity
of rings when mapped to actions, as going with the given absolute
values would mean means rings could be mainly mapped to angle-like
actions, reducing its usefulness.
This API call will snapshot the current configuration of a device
into a GtkPadController, that is created and attached to a toplevel
(this event controller only acts on toplevels).
This controller will handle pad events, trigger actions, and update
compositor feedback (e.g. GNOME Shell pad OSD) as per the actions
mapped in the configuration dialog.
If a pad device configuration gets changed, or reset, we should trigger
the creation of new pad controllers for the existing toplevels.
Add the plumbing so that saving/resetting a device configuration will
result in the same ::configure-pad signal, and trigger it from the
relevant places.
In order to apply the pad configuration so it does something, we
need to create GtkPadController objects on each toplevel for each
configured pad device.
This signal will work as a hint that a new GtkPadController should
be generated for the given device and current configuration. At
the moment, emit it when pad devices are added or removed.
The UI is heavily inspired in the existing one for midi devices
and the such, as the restrictions are somewhat similar. Since there
is not enough information to introspect the device without the help
of libwacom (and the UI should work with tablets unsupported by
it, regardless) the list starts empty, and there exists a "grab
event" button to press pad buttons (or use rings/strips) and
create/focus a list item for the button/mode.
Double clicking on an action (or pressing the "edit" button) spawns
a different dialog with a GimpActionEditor to select an action.
And lastly, actions can be deleted with the "delete" button.
Pads may have different modes (e.g. leds in the tablet) that apply
to all pad features, the list will allow different actions to be
set on the same button in different modes. This basically multiplies
the amount of mappable actions by the number of available modes.
Made `gimp_image_editor_image_flush` and
`gimp_image_editor_image_flush_idle` functions idle. For expanding
layers dynamically, we need to use gimp_image_flush funtion from the
paint therad. The gimp_image_flush eventually calls these functions.
The anchor and merge down buttons are visible at the same time, which should not be the case.
Their visibility is now dependent on the existance of a floating selection.
The New Group and Search/Link buttons are also disabled when there's a floating section.
I had the case when "Sphere" script crashed, bringing down the whole script-fu
plug-in (while trying to reproduce #10214). Then after being run, we get a
dangling pointer to a finalized action object.
Even in successful use cases, we will want to give the ability to unregister
normal plug-ins/procedures wrapped as GIMP extensions, and there is also the use
case of temporary procedures, so I'm sure this bug could be reproducible even in
normal non-problematic runs.
I am pretty sure that this should be in single selection mode because we don't
even really have code to handle cases with multiple brushes or font selected.
Right now, we assume in many places that there is only one font or brush (or
other data) active at a given time.
Yet this code (or older versions of it) is old apparently and I realize that
even in 2.10, I can ctrl/shift click to select several data objects. This is the
weird part.
Anyway let's put this in single selection mode and see how it goes. If there
were actually use cases which I didn't know about, I'm sure we'll soon have
reports.
I could still see annoying scrolling up/down happening when we are deselecting
an item (typically with ctrl-click). In such a case, the cursor is on a
deselected item. Just make it bump to a closest item, preferably a visible one.
My first versions were commits 98f0c448 then 1d8782915e but the more I go, the
better I understand the implications of the selection vs. the cursor. In
particular, when setting a cursor, which also initializes the selection to this
item only, the tree view would also scroll to this item. The current
implementation, which sets the top item as cursor, is therefore particularly bad
for multi-selection which doesn't fit fully in the view, because we also end up
scrolling up. Say you have a long list of layers, you first select the top
layer, then scroll down to the bottom layer and ctrl-click it: the selection
(now 2 items) works but you end up scrolled back all the way up.
This alternate version is much better, by ensuring that your cursor is at least
within the selection (hence avoiding the discrepancy between keyboard navigation
and pointer navigation, and which was fixed with commit 98f0c448), so that we
don't try to change the cursor when possible.
This was broken in commit 3e101922. Setting a cursor basically resets to a
single selection, invalidating pointer-made multi-selection.
But then we got back the bug it fixes, which is that we must grab focus after
the selection is actually made. So we now grab at the end.
This also had a bad consequence for multi-selection (again): if the focus was
not already on the tree view, gimp_container_tree_view_selection_changed() was
not called. This function was where the actual selection-changing is meant to
happen. So we had to shift-click (or ctrl-click) twice. The first time, nothing
would happen (but focus was given to the tree view). The second time, we could
finally update the selection.
This is why we add 2 different cases of focus grab, which should hopefully
handle all cases correctly, though this code is really extra-complex. This
replaces MR !1128.
In Preferences > Toolbox, clicking on an item below the
initial scroll window view causes it to jump to the top
automatically. This patch prevents this by setting the
clicked index in the GtkTreeView before grabbing focus.
Changes were made to the click code for layers & masks
due to the introduction of multi-select, and this seems to
have caused the view highlight to be inconsistent.
This patch adds the gimp_layer_tree_view_update_borders ()
call after a click or selection to fix this.
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.
This is a consequence of commit 98f0c448. Apparently setting the tree view
cursor also reset visually the selection. So I make sure I only set the cursor
on the first path in the list of selected items.
This comes with a "colormap-delete-color" into the "colormap" action group. The
action/button will be insensitive when the selected color is used in the image,
since it is only possible to delete unused colors.
This is meant to replace gimp_image_get_colormap() (see also #9477).
We likely won't need a gimp_image_set_palette() because we can simply edit the
image's colormap/palette with GimpPalette API now and it is directly updated.
For instance, the following code changes the first entry in the image palette to
red, immediately:
```python
i = Gimp.list_images()[0]
p = i.get_palette()
c = Gimp.RGB()
c.r = 1.0
p.entry_set_color(0, c)
```
For this to work fine, I added a new concept to GimpData, which is that they can
be tied to a GimpImage (instead of a GFile). Image palettes are not considered
internals, they are just tied to their image, therefore they can be edited by
scripts/plug-ins.
Additionally with this commit, editing an image's colormap from libgimp API also
generates undo steps now.
When the selection changes, the focus must be on one of the selected items. Not
doing this was creating a very annoying behavior where you would select an item
in the tree view with the pointer first, but then when moving up/down with the
keyboard arrow, the move originated from the previously set item. This was
because the arrow move used the "cursor path", i.e. the keyboard focus, and not
the item selection as origin.
In our case, let's make sure these match (i.e. the cursor path is the path of at
least one of the selected items, which is the most expected behavior for mixed
pointer/keyboard interactions).
See code in gtk_tree_view_move_cursor_up_down() from GTK code.
… with another default shortcut.
This won't happen with the standard US layout, but among all the layouts which
exist (or will exist), there is no say that the characters behing <shift>2-5
keys are not another one of our default shortcuts for other actions. We don't
want to print this case, because it is special enough that it's really not a
bug. In this case, we just ignore the transformed shortcut on the zoom action
and be done with it.
I am using the same GimpDrawableChooser with an additional drawable_type
argument to only show the appropriate tab if we want to limit what can be
chosen.
None of our plug-ins actually use a GimpLayer or GimpChannel only arg so far,
but if we have some day, or if some third-party plug-ins want to have such arg,
now they quite easily can!
After testing, setting a window as transient to another from another process is
still broken on Windows and it's hard to diagnose without using Windows
directly. Since it's not just broken, but it even hangs the whole process, which
is quite a blocker issue, let's disable again the whole code on Windows.
Similarly to the various GimpResource select PDB calls, this allows to call a
core dialog in order to choose a drawable which will be returned back to the
calling plug-in.
This new GimpPickableSelect dialog is a subclass of GimpPdbDialog and uses the
same GimpPickableChooser widget as GimpPickablePopup, except that since it's
inter-process window management, it is harder to make a popup positioned
accurately relatively to a parent (especially on Wayland). This is why it's a
separate widget as a simpler dialog (which we will still try to make transient
as much as possible across platforms).
Improvements of GimpPickableButton:
- Update the selected pickable live as you choose it in the popup. This allows
for instance to get live preview of GEGL operations while staying within the
pickable popup.
- Store the initially selected pickable (before popping up) so that when one
cancels (either with Esc key or by clicking outside the popup, but not on the
parent button), the button comes back to the previous pickable.
- Properly destroy the popup when the parent widget is finalized to avoid
annoying cases where the popup might still be alive.
Additionally I split the GimpPickablePopup with a GimpPickableChooser containing
most of the GUI, which will make it usable as plug-in pickable chooser as well!
Clicking on the parent (typically a button, as in the GimpPickableButton case
used in GEGL operations' generated GUI) used to emit "cancel". Let's have it
emit "confirm" instead.
Also it makes for a "confirm" interaction through pointer action as there were
none until now (only key "confirm", e.g. Enter or Space keys), unless
implemented in a child class (e.g. GimpPickablePopup would emit "confirm" on
activate-item of the tree view widgets, e.g. when double-clicking an item; that
was not ideally discoverable).
… from the plug-in normal runtime crossed streams!
I also add a huge comment in-code, because this was annoying enough to
understand and debug that I don't want someone to remove the idle without proper
consideration and testing in the future, thinking it's useless.
- Removing useless or redundant code.
- Simplifying various logics.
- Using GimpResource directly in temporary PDB procedures, not resource names.
- Better cleanup of the core resource chooser when the plug-in dialog quits (we
need it to ask core to close also any visible resource chooser dialog).
- Replace the "Close" button by more common OK/Cancel. In particular, the
GimpPdbDialog now properly keeps track of the initial object and when hitting
"Cancel" (or Escape key), this initial object is set back.
- Clean up some of the comments, especially when the code is self explanatory.
There is still much more to clean and improve, but it's a first welcome step.
Brush, font, gradient, palette and pattern choices are currently chosen through
a dialog created by the core, which then returns the user choice to the calling
plug-in. This has the unfortunate consequence of having a pile of likely at
least 3 windows (main GIMP window by core process, plug-in window by plug-in
process, then the choice popup by the core process) shared in 2 processes, which
often end up under each other and that's messy. Even more as the choice popup is
kinda expected to be like a sub-part of the plug-in dialog.
So anyway, now the plug-in can send its window handle to the core so that the
resource choice dialog ends up always above the plug-in dialog.
Of course, it will always work only on platforms where we have working
inter-process transient support.
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 not the main reason for the specific output in #9994. These ones are
more probably because of similar usage in GTK (which updated its own calls to
g_file_info_get_is_hidden|backup() in version 3.24.38). But we should likely
also update the various calls we have to use the generic
g_file_info_get_attribute_*() variants.
To be fair, it is unclear to me when we can be sure that an attribute is set.
For instance, when we call g_file_enumerate_children() or g_file_query_info()
with specific attributes, docs say that it is still possible for these
attributes to not be set. So I assume it means we should never use direct
accessor functions.
The only exception is that I didn't remove usage of g_file_info_get_name(),
since its docs says:
> * Gets a display name for a file. This is guaranteed to always be set.
Even though it also says just after:
> * It is an error to call this if the #GFileInfo does not contain
> * %G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME.
Which is very contradictory. But assuming that this error warning was
over-zealous documentation, I kept the direct accessors since they are supposed
to be slightly more optimized (still according to in-code documentation) so
let's priorize them when we know they are set for sure.
In GimpText, The font used to be stored as a string containing its name,
Now, it is stored as a GimpFont object, which makes more sense and makes
operations on fonts easier (such as serialization).
When replacing a selection, take and apply markup (if any)
from the first character of the selection for the entered
text.
This fixes the case when you no longer can change the
global layer text properties after replacing the text.
Also, this changes the behavior introduced in #1220.
Fixes: #7948 (GNOME/Gimp tracker)
When building using MSYS2 CLANG64 profile using clang 16, we get the
following error (besides other required patches):
../../gimp/app/widgets/gimpwidgets-utils.c:931:12: error: incompatible
pointer to integer conversion returning 'HGDIOBJ' (aka 'void *') from a
function with result type 'guint32' (aka 'unsigned int')
[-Wint-conversion]
For now, let's use the same GPOINTER_TO_INT macro we use in
gimpprogressbar.c. In the end, we need a 64-bit type available to
plug-ins, but that needs more work.
Remap font names to unique generated names
so that pango sees them.
keep the font name for display and the internal
name for everything else.
* Fonts are still broken When exporting to pdf
* Not sure if xcf files would be usable on other systems
maybe use hash of psname internally instead
* Not sure if plug-ins using text layer work correctly
(do they use internal font name or the actual name?)
Inline completion is case sensitive, this makes it
broken, because fonts desplayed in the pop should be
quried in a case-insensitive manner.
This fixes#2832.
See gtk issue #275.
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.
