On Tue, Aug 27, 2019 at 11:47:25PM +0100, David Edmundson wrote: > set_reactive > > Everything about this part makes sense. > +1 > > > ----- > > move request + moved > > Concept of having explicit updating makes sense. > Might be worth considering calling it xdg_popup.reposition as > xdg_toplevel.move is very different
"reposition" sounds like a good name, thanks! Maybe it should be "repositioned" too then. > > Would it be valid to re-use the same positioner object each time? I think so. A positioner is just a dump container of numbers and what not, and when it's used, the contents are copied. Whether the client want to reuse or destroy should be fine IMO. > > Could we repurpose wl_display.sync as an alternative for the moved > signal? Simply for code re-use. I don't think so; the sync is replied to immediately by libwayland-server, while a move may go through various hoops before being processed. > It slightly reverses the logic, but after your callback a client knows > it definitely has the latest configure event for your move request. The problem is consecutive reposition requests, where the compositor may ignore one if another came after. Tying it to the configure_ack serial helps dealing with all that. > > ----- > > sync_with_popup > > In example A > > --> xdg_toplevel.configure(200, 600) > --> xdg_popup_surface.configure(3) > <-- xdg_popup_surface.ack_configure(3) > <-- xdg_popup_surface.sync_with_popup(xdg_popup) > > Should this be xdg_toplevel_surface? Yes, indeed. Well spotted. Jonas _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
