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
