... 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.
Resolves#13903
Our code was set to pan the screen if the user had the
space bar held, even if they had the space bar set to
"no action" or "switch to move tool" in Canvas Interactions
in Preferences. This patch adds a check to make sure we
have the action set to pan before continuing to pan when
the mouse moves.
...before trying to get its GimpColorConfig.
Resolves#13691
After the color space invasion, various GimpCanvas
functions are now aware of color management settings.
However, these public GimpCanvas functions do not
require the user to pass in a GimpCanvas, just a GtkWidget.
This can lead to crashes if we pass in a different kind of
GtkWidget, since it may not have a GimpColorConfig property.
One example is the Navigation Dockable, which crashes when
it tries to draw boundaries around the image when "Show All"
is turned on, because it passes a GimpView widget instead of
a GimpCanvas.
This patch adds a check if the "canvas" parameter is actually a
GimpCanvas, and sets the config to NULL otherwise.
Resolves#12428 (for now)
As noted by Thomas Manni, GimpDrawable
does not initialize its push_resize_undo value
except via gimp_drawable_new ().
If the drawable is created in some other way,
it defaults to FALSE and does not save the
original size in history when resized or cropped.
Thomas proposed initializing it to TRUE in
the init () function. This is likely the correct
approach, but could cause some new bugs
right before the 3.0 release.
For now, this patch calls
gimp_drawable_enable_resize_undo () for
GUI-specific operations (like opening as
layers or dragging and dropping layers) to
fix the regression for 3.0. Afterwards, we
can spend time confirming the init ()
approach and switch over to that.
Inspired by Mark Sweeney's work.
This patch passes the user-defined button
icon size from GimpDisplayShell to
GimpStatusBar, and updates the
Soft Proofing button and current tool
icon sizes based off of it.
This is an attempt to fix#12333 where from the look of the trace, the
segfault may happen if it tries to dereference a NULL view->priv->shell
whereas we have a view->priv->cursor_image. Even though I couldn't
reproduce, I'm wondering if it may possible to have no active image
display while the cursor is indeed hovering an image.
Furthermore this updated code is more logical anyway, because we should
use the "show all" value from the actual display shell the cursor is
hovering, not from the active display shell.
Since GimpUnit is now an object, if it's used in functions while
NULL it can cause issues. This patch initializes it to
gimp_unit_pixel () to remove the CRITICALs we received when
setting up rulers when "Show All" is enabled.
Additionally to fixing a deprecation, I also ensure that we don't limit
pointer source to what the system considers the "Core Pointer" on
Wayland.
It is another bug similar to #8016 and possibly what !924 was trying to
fix, even though it turned out this was not the same problem which I
initially reported. In this other variant, when you were hitting Space,
it would originate from the "Core Keyboard" which was associated to a
"Core Pointer". On a laptop, this Core Pointer could be the trackpoint
for instance (in my case) so you could pan with Space + trackpoint move.
Yet say you add a graphics tablet, which is a separate pointer: you
could not pan with Space + stylus move!
Now you can, because when we are pan-spacing, events from all pointer
sources are accepted. Only when the panning comes from a pointer source
(middle click) do we listen only events from this same pointer device.
This reverts commit 413cf9ad85.
As discussed with mitch during last Wilber Week, and commented in !924,
the fix was creating new problem and was not right. We definitely want
to grab pointer events when panning (or other similar interactions).
Also I think I had not tested under Wayland back then, only verified I
didn't see any huge issue on X11, but the commit did not in fact fix the
original issue #8016 (this time, I verified!). The problem I was
encountering seem to be more in how Wayland works + libinput, not giving
full control on input devices to applications and trying to be "smart"
with an option ("Disable Touchpad While Typing") which is often useful,
but other times counter-productive (e.g. in GIMP when we want to
space-panning — which should not be considered typing —, or again
shortcuts in video games, and so on).
Since commit 4e499810, GIMP could crash on switching to
multi-window mode on X11 Linux systems.
As suggested by Alx Sa it is enough to add a NULL check for
shell to avoid the crash.
