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.
Moving the inspector into libgtk lets use reuse internals without
having to add public API for everything or inventing awkward private
call conventions.
https://bugzilla.gnome.org/show_bug.cgi?id=730095
We are keeping references on the widget we are handling as we
are iterating up, but that doesn't protect us against the entire
tree being axed from inside gtk_widget_handle_event.
https://bugzilla.gnome.org/show_bug.cgi?id=727644
We are getting bug reports from people who are irritated that
dialogs now have 'double headers' under any wm but gnome-shell.
As an example, xfwm4 seems to do ok with csd windows, and
on balance it seems better to have some invisible border issues
than to have double headers.
https://bugzilla.gnome.org/show_bug.cgi?id=727414
Setting windows undecorated was broken by some of the recent
shadow width changes. We need to ensure that shadow width is
zero for undecorated windows, then things work again.
If the delete event ends up destroying the widget, unsetting
priv->delete_event_handler will happen on invalid memory, so
unset it before the widget is possibly destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=726825
We did not set an input shape on the window, so the region outside
the invisible border where we draw the outer edges of the shadow
were still part of the window, as far as clicks and cursors were
concerned. Fix this by setting an input shape that makes all clicks
outside of the resize borders go through to the underlying window.
https://bugzilla.gnome.org/show_bug.cgi?id=726125
As those are internal children, there's no signal that GtkWindowAccessible
could catch when those are added or removed, so make GtkWindow use the private
GtkContainerAccessible methods to add/remove the child accessible when that
happens.
https://bugzilla.gnome.org/show_bug.cgi?id=725864
As discussed on desktop-devel-list [1], "There should be an intuitive,
consistent, immediate way to jump to the widgets that live in the
header bar." F10 has been suggested for this as it is already used to
active menubars.
F10 will focus the custom titlebar widget if the window has one and it
isn't already focused. If the titlebar widget doesn't exist or is
already focused then F10 focuses the menubar if there is one.
[1] https://mail.gnome.org/archives/desktop-devel-list/2014-February/msg00176.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=725141
It turns out popovers are already smart enough to cope with this
situation, so let popovers be internal children so things that rely
on gtk_container_forall(), like DnD, work without modifications.
https://bugzilla.gnome.org/show_bug.cgi?id=725727
c287845240 was trying to fix
the memory leak caused by popovers begin destroyed in
gtk_window_destroy before chaining up to gtk_widget_destroy,
which unrealizes the window, and would clean up the popover
windows if the popovers were still around.
Fix this in a better way by moving the popover destruction
after the chaining up, so we unrealize first, and then
destroy the popovers.
Also, make _gtk_window_remove_popover unrealize the popover,
for symmetry with _gtk_window_add_popover.
This should fix
https://bugzilla.gnome.org/show_bug.cgi?id=724921
Dragging windows was not working on widgets in the titlebar
region unless they had the window-dragging style property
set. Fix this by looking at the region for motion notify
events as well as for buton press events.
Try to do a better job of keeping example content
from being too wide. It is often rendered as <pre>
text so the only time we can wrap it is in the source.
It is best to full break lines at all punctuation and
to try to keep the width under 70 chars or so.
Heavy duty can prevent this idle function from being called before
the window is destroyed, so make sure that the source is removed
when the window is finalized.
https://bugzilla.gnome.org/show_bug.cgi?id=723771
Since realize does a lot of the heavy lifting of setting up
csd, we have to re-realize the window if we go from no-custom
titlebar to a custom titlebar or vice versa.
https://bugzilla.gnome.org/show_bug.cgi?id=722919
When gtk_window_set_titlebar is called, we need to set up
client-side decorations properly, and the easiest way to do
so is to realize the window again. Really, you should call
set_titlebar before the window is realized.
https://bugzilla.gnome.org/show_bug.cgi?id=722919
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
When all popovers are removed on destroy(), if a popover is nested into
(eg. with relative_to within) another popover, the removal of one can
lead to the other being removed while the hashtable is being iterated,
which would lead to undefined behavior in further iterations.
Then, use a GList to store popovers, iterating can be made more resilient
on these situations, and unless on pathological cases there's not going
to be as many of those popovers as to cause performance decreases at the
times those are iterated.
