Re: gtk3 public API requests
On 04/05/2018 04:03 AM, Jonas Ådahl wrote: > Is it not possible to some how use a _move_to_rect() API, and use some > hint we can assume means it needs to be movable, and until xdg_popup is > further extended, make the assumption that we should for now use > subsurfaces? I would expect that creating alternate API to say "hey this is movable" and then ensure that gtk_window_real_realize() uses that to ensure a subsurface is used on Wayland would have the same effect. And that is equally okay to me as getting set_use_subsurface(). -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk3 public API requests
On Thu, Apr 05, 2018 at 02:00:09AM -0700, Christian Hergert wrote: > On 04/05/2018 01:32 AM, Jonas Ådahl wrote: > > The reason for moving away from using subsurfaces for various things is > > that they cannot be positioned properly when they extend outside the > > parent window (they tend to sometimes go partly off-screen), and should > > rather use xdg_popup+xdg_positioner instead. > > The problem with that approach, at least if my experience using things > is an accurate representation of the design, is that it's quite > difficult to change or reposition the xdg_popup without first unmaping > the widget. > > For example, imagine a popup that can grow in both directions > horizontally, but stay anchor'd to a position off-center. > > | original size here ... ... | > ++--+---+ > ||dx anchor here| | > || | | > ++--+---+ > | new sizedx anchor still here | > > I've yet to get this to work with the popup without first hiding the > window which gives this really annoying flicker. > > But when using a subsurface, it basically Just Works™. Right. But that is something that should be fixable by improving what xdg_popups can do, i.e. make them movable. By using subsurfaces, you'll forever be stuck with partly-off-screen bugs. Is it not possible to some how use a _move_to_rect() API, and use some hint we can assume means it needs to be movable, and until xdg_popup is further extended, make the assumption that we should for now use subsurfaces? Jonas > > -- Christian > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk3 public API requests
On 04/05/2018 01:32 AM, Jonas Ådahl wrote: > The reason for moving away from using subsurfaces for various things is > that they cannot be positioned properly when they extend outside the > parent window (they tend to sometimes go partly off-screen), and should > rather use xdg_popup+xdg_positioner instead. The problem with that approach, at least if my experience using things is an accurate representation of the design, is that it's quite difficult to change or reposition the xdg_popup without first unmaping the widget. For example, imagine a popup that can grow in both directions horizontally, but stay anchor'd to a position off-center. | original size here ... ... | ++--+---+ ||dx anchor here| | || | | ++--+---+ | new sizedx anchor still here | I've yet to get this to work with the popup without first hiding the window which gives this really annoying flicker. But when using a subsurface, it basically Just Works™. -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk3 public API requests
On Thu, Apr 05, 2018 at 01:25:04AM -0700, Christian Hergert wrote: > Hey everyone, > > I'm lobbying to make 2 functions public API in the stable branch (3.x) > that would help me be able do some fancy things in Builder/Dazzle (which > I can make work fine on Xorg already). > > If there are objections, I'd like to hear from people so I can find a > way to make forward progress. > > The functions I'd like to see made public: > > - gtk_window_set_use_subsurface() > - gdk_window_move_to_rect() > > The Gdk function is currently accessible if you're compiling Gtk since > it can access the private API vtable. Widgets like GtkMenu use this to > do positioning. It didn't make it to public API in time for 3.22, but > had we continued to do a 3.24, it seems likely that would have happened. > > The gtk_window_set_use_subsurface() is basically only useful when on > Wayland, but it helps ensure that we get a subsurface for transient > popup windows. I'm open to other ways to solve the problem, like > GDK_WINDOW_SUBSURFACE, if they allow me to ensure that my window is > backed by a subsurface on Wayland. For the gdk_window_move_to_rect() I think making it public is a good idea, and it has been requested before on behalf of Firefox[0]. The gtk_window_set_use_subsurface() however, I'm not so sure about. Eventually I want to move away from using subsurfaces for things like tooltips (anything that will extend outside the parent window really), and while I haven't investigated further whether this is possible on gtk-3, exposing _set_use_subsurface() might hinder such improvements. The reason for moving away from using subsurfaces for various things is that they cannot be positioned properly when they extend outside the parent window (they tend to sometimes go partly off-screen), and should rather use xdg_popup+xdg_positioner instead. Jonas [0] https://bugzilla.gnome.org/show_bug.cgi?id=791845 > > Again, this API is available internally to Gtk so widgets like ComboBox > can use it, but if you're not a GtkWidget, you're outta luck. > > Thoughts? > > -- Christian > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
