-
Notifications
You must be signed in to change notification settings - Fork 29
Virtual desktop protocol #10
Comments
My gut reaction to this protocol is to be cautiously optimistic, emphasis on cautiously. I think a good protocol for this may be hard to write.
I'm not sure that it makes sense for the sake of GNOME-like paradigms to make workspaces always a child of an output. Even sway may eventually provide config knobs to change its behavior in this way (you can already hack it together). We should make workspaces a standalone concept that can optionally have any number of outputs associated with them.
Change, yes. Create, not so sure. We should also consider the possibility of one output having several visible/active outputs. Swaybar also needs to be able to distinguish between hidden, visible, focused, and focus-inactive workspaces. |
Absolutely. But the benefit would be great. I think we all want to have modular desktops where we can choose the components that work best for us. We never had a thriving bar ecosystem on X11 so I'm motivated to give it a shot.
This is a good idea. I don't want to prescribe any design for compositor workspace functionality. Maybe a many-to-many relationship between workspaces and outputs would be flexible enough to accommodate whatever people may think of.
Yeah, maybe make these properties of the desktop. We can bump the protocol if someone thinks of something new and not everybody needs to support everything. Focus-inactive workspace is derived from the focus order though I think. |
We also have another distinction: empty/non-empty. And what would be the semantics of "create", switch to a formerly empty, but existing workspace, or create a completly new workspace? |
Sway destroys empty workspaces but I acknowledge the need for this feature |
Just to clarify one point: workspaces are a subset of tags. A client can exist on multiple tags, but a client can not exist on multiple workspaces. This shouldn't affect this proposal though. I like the idea. If you want a reference implementation in Way Cooler though it will have to wait at least until after exams (which are in two weeks from now) and after I put in enough work to get tags (and keybindings...) working in Way Cooler. |
Btw, if anyone wants to take this up, go ahead. I have other wlr projects going on I can work on. |
KDE discussion on this matter https://phabricator.kde.org/T4457#64699 |
Addresses github issue swaywm#10
Addresses github issue swaywm#10
Somewhat resuming the conversation on grids from the pull request thread, I think re-introducing the idea of "workspace groups" as I originally put in the pull request (but removed as not strictly necessary) might be a good idea, and might make some things much clearer about how a protocol can map to the various concepts in the different compositors that we would like to cover. So, here are some definitions that I am hoping cover as much as possible, including the concept of "workspace groups".
But there is no reason to preclude the same output being in multiple workspace groups, either. And, there is no reason to prevent two workspace groups having identical sets of outputs. This is the only strict difference from not having workspace groups at all: without explicit workspace groups in the protocol, the client can only infer them by which workspaces have identical sets of outputs assigned to them, and so 'different workspace groups but with the same outputs' would not be possible. While I like workspace groups existing explicitly because it makes things much clearer, it also means that workspace groups have identity distinct from the set of outputs they are attached to, which makes them more flexible. Flexible for what? Who knows!
Other than uniqueness within a workspace group, that each dimension's index is a uint32, and a comment that the coordinates are by convention to be treated as representing [x, y, z,...] coordinates for the purpose of the client representing them graphically, there is no restriction on them, they need not be contiguous or bounded or anything. I think this is adequate for both gnome-shell and wayfire at least, and may not be relevant for others, but it is optional so they can just skip it. A question: Should compositors that wish to number workspaces without the geometric interpretation use 1D coordinates? Or should workspaces additionally have a
I'm interested in which workspacey paradigms exist in compositors that are not covered by this. I think it matches what I know of GNOME and KDE, and I'm pretty sure it matches Wayfire if wayfire works the same way as compiz does with workspaces. I am less familiar with the tagging, so if the |
Despite being initially confused by the notion of workspace groups, I now see that they simplify the problem. So +1 from me. |
Looks like it also would want to know about 'urgent' workspaces. If the foreign-toplevel-management protocol grows |
Any updates here? |
Hi @Anakael, there is a requested change in my pull request here yet to be made. If you are interested in in implementing that change I'd be happy to give you push access to the fork the PR is coming from. Let me know! Otherwise, I've said I would make that change but I haven't gotten around to it yet. That's the only outstanding work on the protocol I'm aware of, otherwise I think we are waiting for someone interested to implement the protocol in a compositor as a test to see if it makes sense. edit: There is also this comment from @ammen99 proposing some changes |
I have started to implement the protocol here: https://github.com/ammen99/wlroots/tree/wlr-workspaces It contains several fixes to the protocol, and of course a lot of the code needed in wlroots. I plan to finish the wlroots part this week, and then I have to do:
I am also not sure what the rules for inclusion in wayland-protocols are, iirc we may need a few more clients and compositors which have support for the protocol for it to be merged. |
Depends what the namespace is. For the ext namespace only a single client and compositor implementation is required, so the requirements are not higher. Though, I don't think a dummy example client is enough, we'll need a real-world client. |
@ammen99 Can I contact you to ask some questions how foreign toplevel manager works? |
@Anakael yes, feel free to ask me questions. Do you have IRC? You can find me at #sway-devel (or #wayfire) |
So, "move" workspace logic can be made by "remove" + "add"? |
Yes, that's how it can be done. |
@ammen99 does it already work? If yes I'd really like to implement such a protocol into my compositor. |
I have open pull requests: I hope there won't be many changes requested in reviews, but I am basically waiting for a thorough review to move forward with final renaming. |
ok i'll wait then until it is merged |
wlr-protocols has migrated to gitlab.freedesktop.org. This issue has been moved to: https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issues/10 |
Nearly every window manager has a concept of a "virtual desktop" in their operation.
i3 has the concept of "workspaces" and Awesome has "tags" which are nearly identical concepts. Each output has a currently active workspace that has its own set of visible windows, and inactive workspaces that are hidden. Many workspaces can exist on an output and each output has its own set of workspaces. Outputs can switch workspaces independently of each other.
Xfce and Gnome have "virtual desktops". There is a single set of virtual desktops for the whole screen. This nomenclature comes from the
_NET_DESKTOP_*
EWMH root window properties and client requests.I would like to support both paradigms if possible.
The goal of this protocol is to support out of process bars that can be run on any window manager. This was never possible on X11 because EWMH only supported the "virtual desktop" paradigm.
Required of the protocol:
List all of the workspaces for each output.
This is to display the workspaces on the bar and their active status.
A way to request a change in the active workspace or a create a new workspace
A bar might request this when the user interacts with the bar like clicking a button. The compositor should be able to deny the request.
Workspaces on multiple outputs at once
This is to support the traditional virtual desktop paradigm. This might require desktop status to be double buffered to support changing workspaces on several outputs at once.
The first target compositors are sway and way-cooler.
Let me know if you have concerns. If you like the idea, I'll write some XML.
The text was updated successfully, but these errors were encountered: