RFC: Popovers

[Carlos Garnacho <carlosg gnome org>]

Hey all,

TL;DR: API for popovers is in the "popovers" branch, adds GtkWindow
low-level API, and a GtkPopover widget.

I took some time in refurbishing GtkBubbleWindow so it'd be more
generally useful. In principle it could be desirable to have popovers
not tied to the usual menu grab semantics, and give some more freedom to
regulate its visibility and behavior. The work is at:

https://git.gnome.org/browse/gtk+/log?h=popovers

Playing with this kind of free behavior I realized that using a
GDK_WINDOW_TEMP window is not quite ideal, if a toplevel can be moved
around or unfocused with a popover on it being shown, you get stacking
weirdness, and bursts of sync calls happen to translate things to root
coordinates.

So I've been playing with implementing popovers as GDK_WINDOW_CHILD
windows on the closest GtkWindow, while this seeminly brings some kind
of API overlap with GtkOverlay, I think it could be more widely useful
than just the pointy bubble windows, but also tooltips, text selection
handles, or the treeview search entry, which aren't as excusable popup
windows. So far I could find these advantages in using popovers:

* Results in less sync calls to translate things to root coordinates:
This is specially taxing on text handles, as those stay when a textview
scrolls, causing frequent translation of coordinates. OTOH there's less
visual lagging too as gtk_window_move() might not be honored
immediately.

* Works right away without grabs nor event forwarding, the textview does
some event forwarding hacks in order to ensure the search entry gets key
events, as a keyboard grab is not set in that case. More generally, not
using GDK_WINDOW_TEMP makes grabs much less of a necessity, and if a
modal behavior is desired, it's just a gtk_grab_add() away.

The only wart I actually see is that popovers implemented this way rely
on having enough space on the toplevel window, GtkWindow of course
ensures that those don't fall out of coordinates if there's overflowing
space at the other side, but it won't attempt to expand the window if
there's a lack of width or height. This should be rarely a problem on
most sane UIs though, I could just think of the empathy contact tooltips
of the core gnome apps that could present a problem with this.

But so far, in the branch only GtkPopover uses the GtkWindow popover
low-level API, and there's a gtk3-demo popover demo. Does this generally
sound like an alright direction?

Cheers,
  Carlos