Skip to content

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

outfoxxed
Copy link
Member

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.

@outfoxxed outfoxxed mentioned this pull request May 23, 2025
@JakeStanger
Copy link

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 get_pair requests, allowing the client to obtain the pairs only as needed. Something like:

<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.

@outfoxxed
Copy link
Member Author

My concern with this implementation is that it would still require a client to keep hold of a map of all the pairs.

I don't think thats a particularly large issue, as most of wayland requires clients to track a lot of state.

At the risk of complicating the protocol, perhaps it would be better structured as a couple of get_pair requests, allowing the client to obtain the pairs only as needed.

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.

@JakeStanger
Copy link

I don't think thats a particularly large issue

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.

Comment on lines +52 to +54
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.
Copy link

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

Copy link
Member Author

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.

Comment on lines +79 to +80
<arg name="ext_toplevel" type="object" interface="ext_foreign_toplevel_handle_v1"/>
<arg name="wlr_toplevel" type="object" interface="zwlr_foreign_toplevel_handle_v1"/>
Copy link

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)

Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants