Have wlroots grow a concept of workspaces

[chrisjbillington]

I'm trying to make a fully-featured traditional window-list/panel/taskbar for wlroots-based compositors using the unstable foreign toplevel management protocol , and one thing I've run into is that there doesn't seem to be a way to distinguish windows on the current workspace/viewport from ones on a different workspace/viewport.

It seems like workspaces/viewports is a concept that wlroots doesn't know about—it looks like the implemtation of them in WayFire is from scratch, though I might be misunderstanding. (the viewporter protocol is completely unrelated to workspaces, right?)

It seems to me that in order to be able to make taskbars like the one I want to make, that will work across wlroots-based compositors, wlroots would need to:

• Have a concept of workspaces like weston's:

A workspace is a list of top level surfaces visible at a time.

• Implement weston's workspaces protocol. Compositors that implement something like workspaces, if they want taskbars to be able to work correctly on them, would need to work with this to set the workspace of each toplevel they are managing, and to set the current workspace whenever they change which one is visible. Then a taskbar app like mine could use the protocol to know what the current workspace is and how many there are.

• Add workspace_enter/workspace_leave events to the foreign toplevel management protocol and send them whenever a toplevel changes workspaces. Then a taskbar app could use these to know which workspace a toplevel is on.

Possible quicker but less feature-complete options might be:

• A new toplevel state to say "on current workspace" meaning that the (top left corner of the) toplevel is within current bounds of the screen. This wouldn't require wlroots to know anything about workspaces., but is less feature-complete because it doesn't allow a taskbar to have say, different sections for different workspaces where it groups tasks together. It would only allow grouping by "current workspace" vs "not current workspace"

• sending an output_leave event when the (top left corner of the) window leaves the bounds of the current screen. Again, this would not require wlroots to know about workspaces - just the window's position, which it already knows. It has the same disadvantage as the above.

It seems like in the long run, a unified concept of workspaces across compositors implementing a common protocol for it would be very useful, though it is perhaps a pretty major task.

Let me know if I've misunderstood something - the weston workspaces protocol hasn't been touched in years, I see little mention of it anywhere, so I'm wondering if it's been superseded by something. Also, there are so many names for workspaces/viewports/virtual desktops that it is hard to google about them. So I might be completely off base.

[ddevault]

This discussion needs to happen here first:

swaywm/wlr-protocols#10

tl;dr: everyone does workspaces differently and this is Very Hard

[ascent12]

(the viewporter protocol is completely unrelated to workspaces, right?)

Yes, wp_viewport is about scaling and cropping client buffers; it's a "viewport" into its buffer. It doesn't have anything to do with its placement.

But yeah, as @ddevault says, it is not easy to do. Many different compositors/WMs have very different concepts of what a workspace is, and how clients may be placed on it. It's not impossible to do, but would be pretty hard; you can give it a try if you want. The weston protocol was only designed specifically for how weston does things, and wouldn't be sufficient here.

[chrisjbillington]

Ah, I didn't realise there was an existing discussion. Well, good to see it's being discussed, but I understand it's a hard problem and probably will not be able to help much myself.

As for asking for an output_leave event when a window leaves the bounds of the current display, (perhaps because it moved to a different workspace) - is it up to the individual compositor to send this?

It seems like compositors probably should send this event if the window moves outside the visible region of an output:

This event is emitted whenever the toplevel stops being visible on the given output. It is guaranteed that an entered-output event with the same output has been emitted before this event.

And this would give me the basic functionality of allowing my panel to only show windows from the current workspace.

[emersion]

It seems like compositors probably should send this event if the window moves outside the visible region of an output

Compositors aren't expected to send leave when a client is hidden on an output. By the way, the client might be visible but still not on the current workspace (e.g. displayed as a thumbnail).

[chrisjbillington]

OK, this is all fair enough. I will wait for progress on the hard problems for now.