Re: RFC: Popovers

[Carlos Garnacho <carlosg gnome org>]

Hi again,

2 more notes,

* The changes on the branch look much better with he patch at
http://pastebin.com/70q9NcFh , due to the class name change.

* Jasper on IRC pointed out that on wayland subsurfaces are a very good
fit for this, and he's indeed right. I do think an API like the proposed
one has a better path forward when GDK gets to expose subsurfaces,
compared to the "popover as GtkWindow subclass" one.

Cheers,
  Carlos

On mié, 2013-11-13 at 20:58 +0100, Carlos Garnacho wrote:
> 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
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list