We still need a drag gesture both on front (capture) and back (bubble)
to handle dragging from both the GtkWindow widget and chrome in the
headerbar. But we can do it through 2 drag gestures, instead of special
event handling code.
This renames the GdkWindow class and related classes (impl, backend
subclasses) to surface. Additionally it renames related types:
GdkWindowAttr, GdkWindowPaint, GdkWindowWindowClass, GdkWindowType,
GdkWindowTypeHint, GdkWindowHints, GdkWindowState, GdkWindowEdge
This is an automatic conversion using the below commands:
git sed -f g GdkWindowWindowClass GdkSurfaceSurfaceClass
git sed -f g GdkWindow GdkSurface
git sed -f g "gdk_window\([ _\(\),;]\|$\)" "gdk_surface\1" # Avoid hitting gdk_windowing
git sed -f g "GDK_WINDOW\([ _\(]\|$\)" "GDK_SURFACE\1" # Avoid hitting GDK_WINDOWING
git sed "GDK_\([A-Z]*\)IS_WINDOW\([_ (]\|$\)" "GDK_\1IS_SURFACE\2"
git sed GDK_TYPE_WINDOW GDK_TYPE_SURFACE
git sed -f g GdkPointerWindowInfo GdkPointerSurfaceInfo
git sed -f g "BROADWAY_WINDOW" "BROADWAY_SURFACE"
git sed -f g "broadway_window" "broadway_surface"
git sed -f g "BroadwayWindow" "BroadwaySurface"
git sed -f g "WAYLAND_WINDOW" "WAYLAND_SURFACE"
git sed -f g "wayland_window" "wayland_surface"
git sed -f g "WaylandWindow" "WaylandSurface"
git sed -f g "X11_WINDOW" "X11_SURFACE"
git sed -f g "x11_window" "x11_surface"
git sed -f g "X11Window" "X11Surface"
git sed -f g "WIN32_WINDOW" "WIN32_SURFACE"
git sed -f g "win32_window" "win32_surface"
git sed -f g "Win32Window" "Win32Surface"
git sed -f g "QUARTZ_WINDOW" "QUARTZ_SURFACE"
git sed -f g "quartz_window" "quartz_surface"
git sed -f g "QuartzWindow" "QuartzSurface"
git checkout NEWS* po-properties
And have a priv->display instead of a priv->screen.
Includes turning gtk_menu_set_screen() into gtk_menu_set_display(),
because that function just forwards to its window.
As we now refrain from sending the crossing events if there's an
implicit grab, those events must be sent on button release when
the implicit grab is broken.
Only if they fall outside the grab widget, in that case the widget holding
the implicit grab won't be receiving events anymore, so we can just undo
it.
Unlike GTK+ grabs which are global to all/one device, the implicit grab
is per focus, which means each may have implicit grabs on different or
the same widget.
Each toplevel will keep its own tracking of the current ongoing foci,
add the plumbing that will allow to create/update/remove those as they
come and go.
X11 was the only backend to support it and people can just override it
using XSetClassHint() directly.
The docs already advertised the function as "Do not use".
Keep the existing call to XSetClassHint() in place, so that we keep
setting the same values as in GTK3.
Introduce a private API meant for abstracting how to get a handle
of a window that can be shared with other processes. The API is
async, since some implementations will require that. Currently,
only X11 is supported, which doesn't.
Based on a patch by Jonas Adahl.
The list of popovers will specify the stacking order, a
_gtk_window_raise_popover() private call has been added so popover
widgets can request being on top.
Also, the stacking on popovers is ensured on gtk_window_size_allocate(),
after the size/stacking changes on the child widget have finished, this
will ensure popovers are kept on top of window contents.
https://bugzilla.gnome.org/show_bug.cgi?id=756670
This behavior has been made optional on add_popover() time, text handles
will keep being able to overflow the window, in order to allow text
selection on views too close to the window edge.
Regular GtkPopovers are reinstaurated to the previous size positioning
logic though, that is, limited by the visible area of the window.
This will be the widget that the popover relates to (::pointing-to in
GtkPopover, ::parent in GtkTextHandle).
Additional API to check the popover/parent relationship between widgets
has been added, which will be useful wherever this is necessary in a
generic manner.
https://bugzilla.gnome.org/show_bug.cgi?id=750993
This must be called while the window is not realized yet, and sets the
GdkWindow that will be used for the next GtkWindow's realize/unrealize
cycle. The GtkWindow takes ownership on the GdkWindow, and as such it
will be destroyed when the widget is unrealized.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
This is a rather hackish way to let GTK+ widgets declare popup windows
as subsurfaces, so they may work on wayland without the need of xdg_popup,
and without many changes yet on the GTK+ side.
https://bugzilla.gnome.org/show_bug.cgi?id=695504
This commit makes it possible to use client-side decorations for
override-redirect windows by calling _gtk_window_request_csd()
before realizing the window. Since the wm won't do interactive
resizing for us in this case anyway, don't bother creating
the border windows we use for this purpose on regular toplevels.
To make this accessible to themes, we set a "csd" style class
on client-side decorated windows. With this, .window-frame.csd.menu
can be used to define the shadow for csd menus, and .menu can be
used to define a border for menus under non-composited wms.
https://bugzilla.gnome.org/show_bug.cgi?id=731187
GtkWindow has 4 (!) APIs for setting window icons, and we
have to try them all in the right order to find the right
icon. This commit makes it so, and keeps the icon list
manipulation inside gtkwindow.c by adding a private API
for getting a single icon at the right size.
https://bugzilla.gnome.org/show_bug.cgi?id=722515
This makes it possible to move/resize client-side decorated windows that are
otherwise obscured by a GTK+ grab somewhere else, either a popover within the
window itself or a modal dialog above the window.
With proper notifications, plus an accessor method for that state. This
allows client to just listen to notify::is-maximized instead of tracking
window-state-event.
https://bugzilla.gnome.org/show_bug.cgi?id=698786
The window-dragging code had a number of issues: The code was
starting a drag on every button press, never bothering to cancel
them. This leads to the odd hand cursor occurring between the two
clicks to maximize. We relied on GDK's multi-click detection, which
gives us triple-clicks when we really want sequences of double-clicks.
Lastly, we didn't propery restrict double-click handling to the primary
button, so e.g. if you had a window on an empty workspace, double-right
click on the titlebar would maximize it, which is not intended.
This commit solves all three problem by a doing our own double-click
detection, and only starting a drag when the pointer goes out of
'double-click range'. We change the way dragging is implemented for
menubars and toolbars to just letting events bubble up, so they
get the same behaviour as the titlebar. To make this work, we
have to select for pointer motion events in a few more places.
Do the menubutton for app menu fallback ourselves in GtkWindow
for the csd, non-custom titlebar case. This fits better with
the way we handle other title buttons. Themes have control
over the placement of this button by placing menu in the
decoration-button-layout style property.
Rework how accels are handled on GtkApplicationWindow.
Instead of having GtkApplication fill the GtkAccelMap which is then used
by GtkApplicationWindow to create a GtkAccelGroup filled with closures
that is then associated with the window, do it directly.
GtkApplication now keeps a list of accels and their actions.
Accelerators on a GtkApplicationWindow ask GtkApplication to execute the
appropriate action.
This saves a fair bit of complexity and memory use (due to not having to
create all those closures and accelmap entries). The new approach also
supports multiple accels per action (although there is not yet a public
API for it).
This patch (and the ones before) Reviewed and ACK'd by Matthias Clasen.
Instead of reparenting the content, use input-only windows to
set cursors and capture clicks on the window frame. This avoids
some of the problems that were introduced by content_window, such
as black flashes and non-working opacity.
Don't mention "auto mnemonics", since those methods are purely about
scheduling a delayed display, and that makes understanding the code a
bit harder.
https://bugzilla.gnome.org/show_bug.cgi?id=697144
