I noticed that the issue of the combo box popup getting immeidately
closed on Linux X11 (and probably macOS as well) only happens when using
GimpUnitComboBox as used in gimppropwidgets.c and gimpsizeentry.c while
there is no issue when used in gimpstatusbar.c
The only noticable difference I saw was that in status bar was that
the wrap width of combo box was set to 1 via
gtk_combo_box_set_wrap_width. Which was added as a hack for another
issue.
I did the same for the other two uses of GimpUnitComboBox and the issue
disappeared so I moved this hack to GimpUnitComboBox itself as it seems
to be generally useful.
The change doesn't make much sense to me and is a workaround for
something that should probably be changed in GTK but well.
As explored in !2654 I think we shouldn't use GtkComboBox but reimplement
using a Popover. This would get rid of these workarounds as we wouldn't rely
on internal behaviour of GtkComboBox.
Couldn't test macOS or Windows but Linux X11 and Wayland work just fine.
Tested by: GDK_BACKEND=x11 gimp and GDK_BACKEND=wayland gimp
Fixes#12491
Superseedes !2654
Previously, the on-canvas text editor would be repositioned only if it was completely
outside the display. If it was partially off-screen, it could be hard to
move it back inside (e.g. when only a small part of the editor was visible
and difficult to grab). Now, the editor is always adjusted to remain fully
visible within the display
Though my previous commit is not absolutely wrong (so I'll leave it in;
it does make sense that we don't set any lock actions as ACTIVE when
there are no items), this new commit is actually the real issue. The
previous commit was getting rid of the extra lock actions, but I
realized that the "edit-undo" action was made insensitive too.
This is because in multi-window mode, a flush was updating all action
groups for the visible image of all opened windows (in single window
mode too, but there is only 1 window, hence only 1 visible image, so no
bug happening). Depending on order of these updates, we could end up
updating actions based on items or undo stack of a non-active image. And
worse, this could even affect the active image itself (which was what
was happening with the locks).
...for dark mode.
The Navigation and Selection Editor
docks use GIMP_ICON_TEXTURE as their
default background when there's no
active image. On dark mode, this creates
large bright areas in the UI.
This patch removes the calls to
gimp_view_renderer_set_background ()
for these docks so the theme background
is used instead.
This patch adds to the code that updates
text layers when colors are drag and dropped
on them. It now also allows color and
pattern drag and drops to update the fill
of vector layers.
Link layers are also protected so they won't
be destructively changed unless
rasterized.
... to get limits in image coordinates instead of gimp_ruler_get_range.
Rulers return values in the active unit (e.g. mm, inches), while the
overlay logic works in pixels. This unit mismatch caused incorrect
clamping of the text overlay position, making it jump
when dragging if the unit wasn't set to pixels.
… input devices.
Per Carlos' advice on gtk#7534, I wait for us to get a focus, since the
pad devices are only created at that point.
Note that this is a Wayland-only issue, but since it doesn't matter too
much that input devices are not initialized before we have a focused GUI
anyway, let's make this simpler.
At the earliest, the splash focus can announce a focus, but since it is
possible to start GIMP without the splash, display shells will also
possibly announce the first focus (there will always be a display shell
focusing at some point for any GUI GIMP!).
This commit prevents the on-canvas text editor from being dragged outside
the image bounds by checking the overlay's position and adjusting the
coordinates to keep it within the canvas. Additionally, it checks whether
the overlay is entirely outside the canvas and, if so, pushes it back inside.
This patch connects GimpImageWindow's notebook
header to respond to external file/URI drag-n-drop.
If you drag files onto the image tab bar, it will create a
new image for each file.
Code based on a similar feature in gimpdisplayshell-dnd.c.
Our build files were relying 'sysroot' to find gexiv2.h but this is
not possible with Apple Clang om which sysroot points to macOS SDK.
So, exotic environments like Homebrew were failing. Let's fix this.
This happened to our artist in residency. She had a crash when
gimp_image_pick_layer() was apparently run with a non-NULL yet invalid
previously_picked layer. So let's make sure that we clear the stored
item pointer when the object gets finalized.
This was simply caused by two variables having been swapped.
Gimp 2 used to work properly because there were two separate mix-ups that
cancelled each other: one in the function arguments, and one in the code
itself. Gimp 3 had fixed the error in the arguments, but not in the code,
thus enabling the bug.
On some systems, it is possible for gimp_image_window_switch_page ()
to be signaled when private->initial_monitor has been set to NULL but
we don't yet have a GtkWindow. This eventually produces a CRITICAL
when gimp_dialog_factory_add_foreign () is run with a NULL monitor.
This patch adds a condition so that gimp_image_window_session_update ()
is not run with a NULL monitor in those cases.
Revert the logic of opening all files as link layers back into loading
their current content as normal layers.
Instead just add a new action dedicated to open images as link layers
and add it to the File menu.
Per UX discussions with Aryeom.
This patch improves vector layer UX based on feedback.
In summary:
* Makes vector layer editable from the Path tool
* Adds initial PDB for creating vector layers in scripts
* Size vector layers to the path size, rather than image
* Transform tools utilize the path for resizing
* Path tool automatically selects vector layer path
When the device is of type GDK_DEVICE_TYPE_MASTER, calling
gdk_device_get_vendor_id() and gdk_device_get_product_id() fails and
triggers a CRITICAL warning. This commit avoids invoking these functions
on master devices, where failure is guaranteed.
See #14219
Transform the `GimpControllerManager` so it encapsulates all the logic
related to managing all `GimpControllerInfo` objects, so we can pass
that object around, rather than dealing with the `Gimp` struct
everywhere and pretty hackishly retrieving the manager struct using
`g_object_get_data()`. By also making it a proper `GObject`, we can
later put even more logic onto it.
Rather than having to hold Ctrl to switch to edit mode, users can now
just click the start point from the end node to create a connected path.
This makes the Path tool consistent with similar tools in GIMP
(such as Free Select, Scissor Select, and Cage Transform tools) as well
as other programs with a Path tool.
Making sure that it's private then NULLified at end of construction so
that none tries to use this again later on during the life of the
display shell (it may have become invalid since then, cf. #12542).
Also NULLifying a similar variable stored in GimpImageWindow (though it
was already a private variable not used outside in this case).
We store an `initial_monitor` in several places, not taking into
consideration that a monitor object can become invalid, e.g. when
disconnecting or turning off a monitor. When the monitor is invalid,
it can cause a crash in `gimp_display_shell_set_initial_scale`.
Instead of referencing the initial monitor, we request the monitor for
our display shell. Since at that point we already know that shell is
valid, we should get a valid monitor too.
