Stop ignoring various crossing events from grabs:
Enter events with type GRAB/GTK_GRAB/GTK_UNGRAB/STATE_CHANGED:
Ignoring these events was added as a workaround for synthesized
events not having the right coordinates (see bug 555109) but
now they do have the right coordinates. (see bug 704456)
Leave events with types types GTK_GRAB/GTK_UNGRAB:
Ignoring these events was added because since we were ignoring
the enter events as above, ignoring the leave events meant we
could lose the prelighted row in a grab-triggered leave/enter
pair. (See bug 653676. It's also now impossible to
reproduce the leave events that were reported in that bug as causing
problems.)
Leave events of type GRAB.
Ignoring these events was added without a ChangeLog entry in 2001,
possibly to keep the prelight from flashing when activating menus.
But ignoring these events could lead to stuck prelighting, and we don't
do it for any other widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=726209
The bug this patch is fixing is that currently if you have a GtkPopover in
clicking off the popover to dismiss it on a GtkTreeView (which triggers
a synthetic enter event on the GtkTreeView) will leave the GtkTreeView
in a confused state until the user moves the mouse again.
That doesn't make sense.
And it causes issues, because when holding down the tab key, we
show/hide a lot of windows and cause a lot of map/unmap events that
stall the event pipeline.
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
eb1ab0dac2 removed support for authentication
based on crypt()-hashed passwords but it didn't remove the header.
Finish up with the removal.
This allows the broadway backend to build on FreeBSD (which has no
crypt.h).
https://bugzilla.gnome.org/show_bug.cgi?id=726149
And let GtkPopover use it as its GtkAccessible implementation, this
accessible sets the POPUP_FOR relationship to the relative-to widget,
and keeps track of changes there.
https://bugzilla.gnome.org/show_bug.cgi?id=725864
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
window->x / window->y are in "root window coordinates", e.g. relative
to the topmost toplevel. However, the coordinates in get_xdg_popup are
relative to the passed-in surface, so we need to do the reverse
translation here.
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
We have a hack in the XSETTINGS code to substitute gtk-xft-dpi
with gdk-unscaled-dpi unless the screen has a fixed window scale,
in which case we just use gtk-xft-dpi.
But if the screen is changed to have a fixed window scale, then
the substituted value of gdk-unscaled-dpi will stick around until
the next (coincidental) change to XSETTINGS. To fix this, force
an immediate reread of the XSETTINGS property when
gdk_x11_display_set_window_scale() is used.
https://bugzilla.gnome.org/show_bug.cgi?id=725754
It may be unusual, but handlers of day-selected may want to transfer
focus somewhere else, without getting it reset back right after by/to
the calendar. This makes popovers demo work on the calendar again, for
one...
Make the popover temporarily undo the GTK+ grab, so it remains modal
to its window, but does not attempt to steal focus on other non-modal
windows that get the focus.
This was most confusing with keyboard navigation, as the focus would
remain stuck on the popover, and not move to the newly focused window
after the popover was dismissed. It didn't have as much effect on
pointer operations as only the first click would be consumed in order
to hide the popover.
There are early returns in this method before the completion timeout
is set later on, so set the source to 0 to avoid trying to remove it
later again.
https://bugzilla.gnome.org/show_bug.cgi?id=725824
