Hyprland Specific Foreign Top-level Manager

[caffineehacker]

Description

What's the opinion of creating a Hyprland specific Wayland protocol for a foreign top-level manager? Right now both the wlr and regular extension lack a lot of detail about Windows which can only be gathered via the socket. Unfortunately, the socket isn't a great avenue for every detail change and the window address there is not comparable to the wlr id (although I can link it to the regular ext protocol, that isn't guaranteed to always work).

I'm happy to put in the work to make the protocol definition and plumb it to the right places since I think it could be quite valuable. The plan would be to have a top-level object with all the same properties as hyprctl clients shows with the added benefit of foreign keys to the monitors. We may also need a workspace protocol in the future if this works well. Since these would be a private hyprland protocol it would be easy to add and remove fields / actions / events.

[vaxerski]

what would be some examples of usage that both these managers lack that a vendored protocol would allow?

[caffineehacker]

zwlr_foreign_toplevel_manager_v1 lets us do the following:

• Get title, app_id, output enter / leave, parent change, and closed
• Get notified when there are status changes to toplevels
• Can activate a given toplevel

ext_foreign_toplevel_list_v1:

• Get title, app_id, identifier, and closed
• Associate the identifier with the window address (implementation detail of Hyprland, but it works) so you can use these events to keep track of windows acquired from the socket clients command
• Get notified when there are status changes to toplevels
• Cannot activate a toplevel

Hyprland sockets:

• Some events, largely returning windowaddress and missing significant pieces of information
• Requires regularly polling with the clients command to get the full details
• Can only be associated with events from wayland protocol by using implementation details inside of Hyprland's code

What I'm trying to do and why I'm finding it difficult:

• I want a task bar with only the windows on that monitor and sorted by workspace (the hard part). Optionally with just the windows in the workspace. I also want the application icon which requires the initial_class and / or class property from the client.
• • I can do this with a combination of initially querying clients and then associating events from ext_foreign_toplevel_list_v1 with those from clients. Some of this can be done by listening to the socket events, but many events have incomplete information or require re-querying all clients to actually know what is going on.

Proposed interface would be an extension like ext_foreign_toplevel_list_v1 which explicitly calls out " This protocol is intentionally minimalistic and expects additional functionality (e.g. creating a screencopy source from a toplevel handle, getting information about the state of the toplevel) to be implemented in extension protocols.". The top level object would support all of the same information available about a client from the socket clients command with the added benefit of using the same object ids as other Wayland protocols (e.g. zwlr_output_head_v1 for the outputs). Ideally there would also be a workspace protocol for indicating workspaces that exist and which one is active so that id could be referenced from the workspace value of the top level as well.

If we go this route, one choice will be whether we purely extend ext_foreign_toplevel_list_v1 by making a protocol that takes an ext_foreign_toplevel_handle_v1 and gives back a hyprland_foreign_toplevel_handle_v1 which has the Hyprland events or if we want a new hyprland_foreign_toplevel_manager_v1.

I know there is probably a lot of opinion over whether the socket or the wayland protocol is likely better or more efficient way of communicating, but the clear delineation of data and the easier to use model of a wayland protocol makes that a better choice in my opinion, but I'm happy to hear other opinions.

[vaxerski]

meh, dunno if this is that needed.

[caffineehacker]

Given I'm willing to do the work and the maintenance should be pretty low, what's the risk?

Also, what's your opinion on having the draft ext-workspace-unstable protocol implemented (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40)? Having an object oriented interface is significantly better than using the sockets for communicating and understanding the state of the desktop.

[vaxerski]

it used to be implemented but was dropped. It also doesn't work very well with how we use workspaces.

Given I'm willing to do the work and the maintenance should be pretty low, what's the risk?

Sure, but this discussion should take place in a draft MR to hyprland-protocols