GNOME Bugzilla – Bug 757474
[rfe] Add option for automatic GtkPopover placement
Last modified: 2016-07-22 20:14:07 UTC
Currently developers have to set a GtkPositionType to make a GtkPopover be placed correctly. This is unintuitive (GtkPopupMenus used to auto-place correctly). The default (GTK_POS_TOP) sometimes is a bad choice. See e.g. these bugs: https://bugzilla.gnome.org/show_bug.cgi?id=756976 https://bugzilla.gnome.org/show_bug.cgi?id=728859 In some cases (imagine a GtkPopover on some object in a GtkScrolledWindow) it is impossible to statically code the position property. Thus many applications will need to add their own code to calculate correct GtkPopover placement. This increases Gtk usage complexity. Can't GtkPopover have some code to solve this problem in Gtk?
you are using wayland, I assume ? gtk does have code to place popovers only where there is enough room. Under X, popovers can't extend beyond the toplevel, so we use the toplevel size for that determination. Under Wayland, they can extend beyond the toplevel, and we should use the monitor geometry to make that determination. But that information is not available to Wayland clients.
(In reply to Christian Stadelmann from comment #0) > Currently developers have to set a GtkPositionType to make a GtkPopover be > placed correctly. This is unintuitive (GtkPopupMenus used to auto-place > correctly). The default (GTK_POS_TOP) sometimes is a bad choice. See e.g. > these bugs: Agreed, that's an historical artifact, as popover was a private object that was later made public, and all uses back then were GTK_POS_TOP. It's too late to change that unfortunately. Those bugs are quite unrelated though: > https://bugzilla.gnome.org/show_bug.cgi?id=756976 This is only an issue in Wayland, the application has no notion of global window positioning nor distance to screen edges. There's protocol under way covering that aspect, but until then we don't have a way to fix, short of retrofitting the same restrictions we have on X11 (where the popover can't be larger than the parent surface in any direction). > https://bugzilla.gnome.org/show_bug.cgi?id=728859 The positioning problems in bijiben come from the WebKit API not offering the possibility to obtain any x/y coordinates from the selected text, GTK+ will not be involved at all in the fix to this bug. > > In some cases (imagine a GtkPopover on some object in a GtkScrolledWindow) > it is impossible to statically code the position property. Thus many > applications will need to add their own code to calculate correct GtkPopover > placement. This increases Gtk usage complexity. > Can't GtkPopover have some code to solve this problem in Gtk? As Matthias said, there is anywhere else than wayland, because we have constraints to honor there, first the opposite side will be tried, and then the alternative orientation. Still, we still need to start off a given position, which I don't think we can infer or guess.
Yes, I am using Wayland. Thanks for the hints. On Gtk+Wayland you still know the position a mouse event has relative to the window, right? Can't you create a GtkPopover, get its size and check if that fits into the window?
yes, there may be room for a 'prefer to stay inside the window' option, under wayland.
(In reply to Matthias Clasen from comment #4) > yes, there may be room for a 'prefer to stay inside the window' option, > under wayland. I'd vote for only checking the opposite position though, or falling back to the original position after trying the 4 orientations. With the current !wayland impl I'd say we may end up with a less desirable final position if the popover doesn't fit in any way.
Created attachment 316624 [details] [review] popover: Make it possible to constrain to toplevel Under X11, popovers are always constrained to the toplevel window. Under Wayland, they aren't. This commit adds a property that allows to explicitly constrain popovers to the toplevel, giving them the same behavior under Wayland as under X11.
irc review: make it opt-out instead of opt-in.
Attachment 316624 [details] pushed as e626038 - popover: Make it possible to constrain to toplevel
*** Bug 758721 has been marked as a duplicate of this bug. ***
*** Bug 758664 has been marked as a duplicate of this bug. ***