-
Notifications
You must be signed in to change notification settings - Fork 0
Add wlr/ext foreign toplevel association protocol. #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
My concern with this implementation is that it would still require a client to keep hold of a map of all the pairs. At the risk of complicating the protocol, perhaps it would be better structured as a couple of <request name="get_pair_for_ext">
<arg name="toplevel" interface="ext_foreign_toplevel_handle_v1" />
</request>
<request name="get_pair_for_wlr">
<arg name="toplevel" interface="zwlr_foreign_toplevel_handle_v1" />
</request> ...and everything else to go with it. |
I don't think thats a particularly large issue, as most of wayland requires clients to track a lot of state.
Since wayland is fully asynchronous you can't do this with objects other than a new_id. Implementing it like this would require a new callback interface that returns the association asynchronously. I'm personally against that. |
Nah you're right, I think I was overthinking it. Had it in my head otherwise, but any reasonable use-case for this protocol is almost certainly already tracking most if not all clients. |
Upon creation of the manager, 'associate' events must be sent for | ||
all existing foreign toplevel pairs. Following creation, an associate | ||
event must be sent whenever a new foreign toplevel pair is completed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps get the client to pass in their ext_foreign_toplevel_list_v1 and zwlr_foreign_toplevel_manager_v1 for which to associate pairs? To cut down on spam
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't really think of a case where you only want a subset of associations, and spam shouldn't be much of a concern unless a user somehow has thousands of windows open.
<arg name="ext_toplevel" type="object" interface="ext_foreign_toplevel_handle_v1"/> | ||
<arg name="wlr_toplevel" type="object" interface="zwlr_foreign_toplevel_handle_v1"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there some race with these objects getting destroyed? (Idk)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
libwayland nulls incoming object references that have been destroyed by the client. Smithay likely does something similar.
This protocol enables clients to match ext and wlr foreign toplevels without relying on heuristics.
It is intended as a stopgap until ext foreign toplevel management is ready.