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
Popovers may get relocations optimized away if only x/y changed
in the GtkAllocation. So make sure the toplevel updates popover
positions on all situations.
https://bugzilla.gnome.org/show_bug.cgi?id=729140
If the same position is requested on a popover, it should at least ensure
the window is realized and raised, even if no resizes are queued on the
content. Otherwise other widgets being mapped might raise the windows over
the popover's if its original position is unchanged.
https://bugzilla.gnome.org/show_bug.cgi?id=734129
So far, gtk_window_set_focus just did not work when called on
a hidden window. Change it to record the desired focus widget
for hidden windows, and apply it when the window gets shown.
This is similar to how we tread other window properties that
can't be set before the window is realized, like maximized
or fullscreen.
This is related to
https://bugzilla.gnome.org/show_bug.cgi?id=734033
Don't shadow existing variables. Instead of sharing the allocation and
then overwriting the width/height when convenient, declare it in the
block we use it in, as, really, the three different paths are all
extremely different, and there's no sense in sharing the variable.
It's hard to figure out what the "expected_reply" means except under
close examination -- it's actually talking about whether this was a
reply to a ConfigureRequest or not. The inversion in the check doesn't
help either.
Make the code cleaner by moving it above the freeze/thaw case, and
making the check more explicit and without a confusing variable. If we
haven't sent any ConfigureRequests out, then it must be a gratuitous
ConfigureNotify.
Keep Ctrol-Shift-D as a straight toggle-the-inspector keybinding,
but make Ctrl-Shift-I always bring up the inspector, and point
it at the widget under the pointer.
Resize grips were introduced for GNOME 3.0, before we had any of the
"new GNOME app" features like invisible borders and CSD. With OS X 10.6
and 10.7, Apple has replaced the classic grips in their applications
with invisible borders as well.
New GNOME app designs don't use resize grips anymore and the new
default theme for GTK+, Adwaita, disables them entirely by forcing their
width and height to 0.
They're past their time. Remove the code to support them. This can
always be reverted if some app relies on them.
When showing and hiding the inspector window repeatedly without
dismissing the dialog, we were hiding the inspector, but not
the dialog, leading to a confusing user experience.
https://bugzilla.gnome.org/show_bug.cgi?id=732443
Since we have a paint clock, we shouldn't be sending out EXPOSE events
for OR windows inside the ALLOCATE cycle. The idea here was that we
would have to wait for a map to get an OR window to paint to, but since
then this has been abstracted away inside GDK and the paint clock.
We already update the grip position in _gtk_window_set_allocation, which
is done through the size_allocate above. Receiving a ConfigureNotify
also won't ever change a grip's visibility, so there's no point in
refreshing it.
This way plain clicks can be handled in gtkmain through the usual delivery mechanism,
and get possibly handled too by widgets holding a GTK+ grab. If window dragging is to
be started, the sequence will be claimed (and a grab will happen afterwards), notifying
properly the grabbing widget that event delivery was interrupted.
This makes it possible to dismiss popovers by clicking on window headerbars, while
still making it possible to drag the window with the popover opened.
For csd override-redirect windows, we don't set up resize handles,
but we were not ignoring the margin in all places, causing some
size calculations to go wrong.
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
Every button press/release event reaching the the multipress gesture in GtkWindow
and happening in the "title" region must be handled, regardless of the event widget.
Children there wanting the event(s) for themselves are (and were always) expected
to stop event propagation.
So the only place to check for the event widget's "window-dragging" style property
is the "content" region, which matches the pre-gestures behavior.
This fixes some issues with sequences being mistakenly claimed (and events not
propagated further) on situations it shouldn't.
The multipress gesture must react to either direct events on the
GtkWindow (special cased through _gtk_widget_check_handle_wm_event),
or bubbled events from child widgets. Ensure bubbled events go
through the gesture, those are fed manually to make sure events are
only handled once, in either one or other place. The implicit grab
will ensure that doesn't change mid-action.
The events to those are fed outside the regular event propagation scheme,
through _gtk_window_check_handle_wm_event(), so set the controller to
GTK_PHASE_NONE so events aren't processed first manually, and then
automatically.
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.
A multipress gesture is used to control all this, replacing
single/double click custom code, and triggering window dragging
when the multipress is stopped, yet active (ie. the sequence remains
pressed).
This avoids a bunch of policy problems with deciding how to lay
out the window menu under different WMs.
For now, we use the special event _GTK_SHOW_WINDOW_MENU, but we
hope to have this standardized in wm-spec quite soon, as KDE wants
it as well.
With the keybinding, it is possible that users may trigger the
inspector unintentionally. Show a dialog that informs them about
whats going on and gives them a chance to back out.
The warning dialog can be bypassed with the
org.gtk.Settings.Debug inspector-warning setting.
