In non-composited environments, we were ending up with all-black
drag icons, because nothing was drawing the background of our new
toplevel. Fix this by drawing background when we are not composited.
We don't do this when composited, since we want to allow transparent
icons.
The documentation clearly says that the widget is not destroyed,
but we were in fact failing to keep it alive, since it was still
a child or the icon_window when we destroy that. Fix this by
reparenting the icon_widget out before. Also, deal with the
possibility that the application might destroy the widget
halfway through, for whatever reason.
We should conform to a minimal set of reasons for the gtk side to emit
a better GtkDragResult than GTK_DRAG_RESULT_ERROR. This fixes the notebook
tab DnD feature, where we rely on GTK_DRAG_RESULT_NO_TARGET.
In the wayland side, unfortunately we can't honor either NO_TARGET nor
USER_CANCELLED, we don't know of the latter, so we could return false
positives on the former.
https://bugzilla.gnome.org/show_bug.cgi?id=761954
Grabbing must stay a bit longer until all other backends than x11/wayland
catch up with GDK DnD, so ignore deprecation flags are used on those. The
uses of GdkDeviceManager can be entirely avoided though.
When this is in use, there's essentially a bunch of dead code here.
When all backends are ported, we'll be able to remove grab/cursor
management plus a bunch of source-side event handlers.
I hadn't noticed the :drop() pseudo state in the CSS4 Selectors
spec when I added this a while ago. This commit renames
GTK_STATE_FLAG_DND to GTK_STATE_FLAG_DROP_ACTIVE and adds
:drop(active) as equivalent to the :dnd pseudo state.
Remove some now unused includes and dead code, and rename
gtk_drag_set_icon_window to gtk_drag_set_icon_widget_internal,
since it is no longer restricted to toplevel windows.
Under Wayland, the compositor does it, so there is no need
for us to move the window ourselves. For X11, we are now
doing the animation from the X11 backend. Trigger that by
calling gdk_drag_drop_done().
What changes here is that we have to keep the icon_window
alive for as long as the drag context exists. Use a weak
reference to do so.
When we start a drag cancel animation, we can just keep the existing
window. The reset was only necessary to convert from cursor icon to
window and we removed the cursor handling.
The Wayland dnd surface must remain in place until the drag
is over. Setting it directly as the hardcoded window of the
widget we construct carries the danger that it might get
destroyed prematurely, e.g. when the application calls
gtk_drag_set_icon_name more than once and we recreate the
widget.
Instead, create a dedicated toplevel, and reparent the widget
into it. To keep the code simple, we use the same approach
under X11 as well, and make it the responsibility of the
GDK dnd code to keep the window position updated. We already
pass the current pointer position to gdk_drag_motion, which
makes this very easy.
As a side-effect of these changes, it is now possible to use
non-toplevel widgets as drag icons.
https://bugzilla.gnome.org/show_bug.cgi?id=748763
The size of icons is a property that is relevant to who is rendering the
icon, not to the icon itself.
Example: Starting a DND operation from an entry icon should cause the
icon to resize (from the entr icon's size to the DND icon size).
Make gtk_icon_helper_ensure_surface() a private function that just
ensures the surface was loaded.
Add gtk_icon_helper_load_surface() that is called by the above function
and the dnd code to actually load the surface.
This is wrong by all accounts there, as we can do no tricks there to show
a "drag failed" animation, which is performed by the compositor itself
on wayland.
The current widget lookup code bails out on insensitive widgets, there's
however legit cases where we want DnD handled by a parent of the insensitive
widget, so just keep going upwards in that case.
We also use now the widget state flags, because get_sensitive() doesn't
propagate across hierarchies, so we could conceivably find a drop site
inside an insensitive widget.
https://bugzilla.gnome.org/show_bug.cgi?id=751793
Nowadays (and for quite some years now) we rely on GdkEventGrabBroken
events to be received. This fake button event seems a remnant of
the early Gtk 2.x days, and is currently even inconsistent with our
event delivery model, so just remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=749737
If the icon happened to come from the drag site icon helper (ie. set through
gtk_drag_source_set_icon*), it would be referenced on the GtkDragInfo,
but not hooked into its context. This results on non visible drag windows,
until set_icon_helper() happened to be called on some path.
Add a gtk_drag_cancel() function that can be used on the
source side to cancel an ongoing drag operation. This can
be useful, e.g. if the data that is being dragged becomes
unavailable.
There was some X11-specific code before an early exit
in the functions that grab and ungrab keys during DND.
It seems to not cause a problem under Wayland, but moving
it out of the way seems right anyway.
This was forgotten when making DnD use a GtkGesture in the handlers
attached to the widget in gtk_drag_source_set(). The gesture must obey
the specified button mask, and switch to denied state if the pressed
button isn't part of the given mask.
https://bugzilla.gnome.org/show_bug.cgi?id=735965
Event controllers now auto-attach, and the GtkCapturePhase only determines
when are events dispatched, but all controllers are managed by the widget wrt
grabs.
All callers have been updated.
The propagation phase property/methods in GtkEventController are gone,
This is now set directly on the GtkWidget add/remove controller API,
which has been made private.
The only public bit now are the new functions gtk_gesture_attach() and
gtk_gesture_detach() that will use the private API underneath.
All callers have been updated.
This gesture is used by gtk_drag_source_set() to determine
whether dragging moved past the threshold. The gesture events
are handled via the usual ::event callbacks, so we don't mess
up with callers expecting that to happen in a signal handler.
If the sequence gets claimed somewhere else in the event widget
stack, the DnD gesture will be cancelled.
When making the entire window a drop target, as file-roller does,
we don't want to draw the drag highlight around the CSD window
decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=728526
Please enter the commit message for your changes. Lines starting
When trying to drag, we currently the position of the first motion
event to determine where the drag came from. This might be alright
in the case of the old animation, but the data will be inaccurate
if the user has moved the pointer quite a bit since pressing the
cursor to start dragging. While we could monkey patch the GdkEvent
at the widget layer, this is unintuitive and strange.
Add a new API that takes a set of pointer coordinates describing
the origin of the drag. Additionally, adapt most widgets to use
it and use it with correct coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=705605
We've recently a number of classes wholly. For these cases,
move the headers and sources to gtk/deprecated/ and adjust
Makefiles and includes accordingly.
Affected classes:
GtkAction
GtkActionGroup
GtkActivatable
GtkIconFactory
GtkImageMenuItem
GtkRadioAction
GtkRecentAction
GtkStock
GtkToggleAction
GtkUIManager
Mutter magically ignores override-redirect windows with geometry
-100-100+1+1, and this breaks the frame synchronization between
gtk+ and mutter. For now, we avoid the issue by simply giving
the window a different geometry.
https://bugzilla.gnome.org/show_bug.cgi?id=694217
A modifier of "0" is still a modifier and must be submitted normally.
A num_modifiers of 0 is essentially a noop in the server.
As mentioned by Peter Hutterer <peter.hutterer@who-t.net>
https://bugzilla.gnome.org/show_bug.cgi?id=662839
It turns out that simply using XIGrabKeycode instead of XGrabKey
makes the DND keyboard support mostly work (there seem to be some
minor issues with modifiers). This means we no longer grab the
keyboard actively during DND, which in turn makes Alt-Tab and
other window manager shortcuts work again during DND.
At the same time, bring the DND key handling code into the
multi-backend work, by checking for X11 and XI2 at runtime,
in addition to compile time.
At http://dev.laptop.org/ticket/10643 we are seeing that drag-and-drop
within the Sugar shell causes all of Sugar's custom keybindings to be
removed.
This is because gtkdnd tries to unbind XK_KP_Space, which (on my systems)
is resolved to NoSymbol by XKeycodeToKeysym(). NoSymbol has value 0,
the same as AnyKey, and XUngrabKey(AnyKey) is equivalent to unbinding
all possible keycodes.
Fix this by catching NoSymbol before binding/unbinding.
https://bugzilla.gnome.org/show_bug.cgi?id=652402
Now that we have wesome macros in glib 2.0, we can use them. Woohoo, GTK
2.0 will be so awesome in the future.
(Did anybody touch dnd code this millenium?)
which happened when the source widget was hidden or destroyed while a
drag was going on, like when dragging from a popup that got a grab
broken as result of the dnd operation.
This was claimed to cause problems for Chromium, see bug 599130.
Also work around apparent rounding errors in XIWarpDevice by
setting the 'small step' for keynav dnd to 2 instead of 1 - I notice
that a warp seems to sometimes warp a little less than I tell it to,
and if I tell it to only move by 1 pixel then moving less means
that you are stuck.
This commit does a number of things:
- remove some dead wchar configury from configure.ac and gdkconfig.h
- repurpose gdkconfig.h as header that contains GDK_WINDOWING_foo
macros for each included backend, include it in gdk.h and install
it in $includedir instead of below $libdir
- drop the backend from the library names
- build libgdk-3.0.la as a convenience lib and include it in libgtk-3.0.la
It does not yet enable building multiple backends at the same time.
