Skip to content
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

WLR Workspace manager implementation #805

Merged
merged 13 commits into from
Nov 23, 2021

Conversation

Anakael
Copy link
Contributor

@Anakael Anakael commented Aug 7, 2020

This is implementation of wlr_workspaces protocol from https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40

Sway compositor implementation: swaywm/sway#5597
Wayfile compositor implementation: WayfireWM/wayfire#647

Many options comparing sway/workspaces was omitted like disable-*.
Let me know if they was usefull. By the rest it is drop-in replacement of sway/workspaces.

Scrolling will be introduced in next PRs.

P.S.
Not sure if it works correctly with multiple outputs.

man/waybar-wlr-workspaces.5.scd Outdated Show resolved Hide resolved
man/waybar-wlr-workspaces.5.scd Outdated Show resolved Hide resolved
man/waybar-wlr-workspaces.5.scd Outdated Show resolved Hide resolved
man/waybar-wlr-workspaces.5.scd Show resolved Hide resolved
src/modules/wlr/workspace_manager.cpp Show resolved Hide resolved
Comment on lines 139 to 153
auto WorkspaceGroup::handle_output_enter(wl_output *output) -> void {
spdlog::debug("Output {} assigned to {} group", (void *)output, id_);
for (auto &workspace : workspaces_) {
workspace->show();
}
output_ = output;
}

auto WorkspaceGroup::handle_output_leave() -> void {
spdlog::debug("Output {} remove from {} group", (void *)output_, id_);
output_ = nullptr;
for (auto &workspace : workspaces_) {
workspace->hide();
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you have multiple outputs you will get this message multiple times. You probably want to do this differently here. You can have a look in the taskbar module, how I handled output_{enter,leave} there. Something similar might also make sense for the workspaces (in combination with an option for all_outputs).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.
Check only equality with the current output since compositor assign outputs to group by self. So all_output parameter isn't actual for wlr_workspaces.

src/modules/wlr/workspace_manager.cpp Show resolved Hide resolved
src/modules/wlr/workspace_manager.cpp Show resolved Hide resolved
Add removing buttons
Adjust handling multiple outputs.
@Anakael
Copy link
Contributor Author

Anakael commented Aug 22, 2020

@l3nkz
Can you review this pull request?

@l3nkz
Copy link
Contributor

l3nkz commented Aug 23, 2020

Sorry! I already looked through your other changes when you pushed the commit and they look good to me now. I have nothing to complain. Your work is a good basis to continue with further enhancements. However, I couldn't test it yet. I am currently not running a self-built wayfire on my machine. I will test it as soon as possible, if @Alexays considers it necessary.

@Alexays
Copy link
Owner

Alexays commented Nov 12, 2021

Code LGTM, once conflicts have been resolved.
@l3nkz can you test to make sure it's work fine :)
Then wel'll merge the PR!

@l3nkz
Copy link
Contributor

l3nkz commented Nov 13, 2021

I will try to make some tests in the next days. Unfortunately not before Monday I think.

@l3nkz
Copy link
Contributor

l3nkz commented Nov 16, 2021

I tested the module yesterday evening with my setup at home (single monitor) and today with my setup at work (multi-monitor) and it looks good to me so far. Four things that I recognized, but which are not a show-killer right now:

  • My WM (wayfire with the wlr-workspaces PR merged) announces the protocol at a different name (zext_workspace_manager instead of zwlr_workspace_manager). But this will probably be sorted out once the protocol is officially merged upstream.
  • Especially in the multi-monitor setup, the workspace bar has a lot of elements. Adding an option to only show the workspace of the current output is probably worth the effort.
  • I would also appreciate an option to only show the (name of the) currently focused workspace.
  • I also in favor of using the same nomenclature for focused in the taskbar and workspacebar. In the taskbar it is called active whereas in the workspacebar it is called focused. Maybe we can change this so that both use the same word to describe the currently used element. I don't mind changing the taskbar accordingly, if we consider focused the better term.

In total, I think the module is great! I am looking forward to use this in my production system!

@Anakael
Copy link
Contributor Author

Anakael commented Nov 16, 2021

@l3nkz
Thank you for feedback!

Adding an option to only show the workspace of the current output is probably worth the effort
I need some time to update patched sway and wlroots to make it works again and test in multi-monitor setup. About option: the protocol introduces "workspaces group" which can be bounded to specific output (or outputs can share the same workspaces), so it should be controlled by compositors (I'm not sure if it implemented in wayfire).
I would also appreciate an option to only show the (name of the) currently focused workspace.
I'll try to implement it in about next two weeks.
In the taskbar it is called active whereas in the workspacebar it is called focused.
Workspace class names was copied from sway/workspaces module in order to be "drop-in replacement". Changing taskbar naming will break existing configurations. So I think dropping "drop-in replacement" concept is better in order to unify names. I'll do that.

@Alexays

Then wel'll merge the PR!
Protocol itself and its implementation for sway still are in MR state. Also, this client implementation here can be outdated from current version of protocol. Should I update this PR now or we can just wait for merging and update it after?

@Alexays
Copy link
Owner

Alexays commented Nov 18, 2021

Then wel'll merge the PR!
Protocol itself and its implementation for sway still are in MR state. Also, this client implementation here can be outdated from current version of protocol. Should I update this PR now or we can just wait for merging and update it after?

I think you can update the PR and merge, in that way we'll avoid merge conflicts in the future.

@Anakael
Copy link
Contributor Author

Anakael commented Nov 23, 2021

I've updated PR accordingly to latest version of protocol.
What updated:

  • Protocol name
  • Class naming

What fixed:

  • Now in one group per output configuration workspaces are only shown only on output they belongs to (unless all-outputs option is set to true)
  • Fix critical error in logs
  • Fix invalid readings in bindings

What added:

  • New states: urgent and hidden (from protocol)
  • all-outputs option
  • active-only option
  • configuration for actions on buttons
  • remove action

As a next step I'll update sway PR with implementation, but this module can be considered as completed.

@Alexays Alexays merged commit 977d21b into Alexays:master Nov 23, 2021
@Alexays
Copy link
Owner

Alexays commented Nov 23, 2021

Thanks a lot!

@Anakael
Copy link
Contributor Author

Anakael commented Nov 23, 2021

I've also added documentation on wiki: https://github.com/Alexays/Waybar/wiki/Module:-Workspaces

@emersion
Copy link

You shouldn't merge this PR at this point, because the protocol hasn't been finalized yet. Waybar may break because of a protocol adjustment.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40#note_1167835

@l3nkz
Copy link
Contributor

l3nkz commented Nov 24, 2021

I think all of us, that worked on the module (@Alexays, @Anakael and me) are aware of the fact, that the protocol isn't stable yet and that we have to adapt the implementation ones the protocol gets finalized. Maybe we can mark the module as experimental, might not work with your WM in the wiki and in the manpages?
@emersion Can we somehow assist you with the protocoel merge request? I am personally very interested on getting this protocol finalized as well as go even further and implement an extension for the foreign_toplevel_manager protocol that we discussed here #762.

@Anakael
Copy link
Contributor Author

Anakael commented Nov 24, 2021

You shouldn't merge this PR at this point, because the protocol hasn't been finalized yet. Waybar may break because of a protocol adjustment.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40#note_1167835

  1. It won't break the whole Waybar. It will break wlr/workspaces module.
  2. Waybar use own copy of protocol, so breaking changes won't break this module immediately.
  3. There were added 2 requests (and only one can be used here) and 2 states in protocol for last 11 months. And it took me less than 40 minutes to adjust implementation to it.
  4. Now, when it merged some of us can use this module (and protocol) every day and it allow us to understand what we need from it.

@Anakael
Copy link
Contributor Author

Anakael commented Nov 24, 2021

Maybe we can mark the module as experimental, might not work with your WM in the wiki and in the manpages?

I've added note about it on page.

@emersion
Copy link

It will break the whole Waybar, and it will disconnect the whole Wayland connection with a protocol error. The copy of the protocol doesn't prevent that.

You can daily use this WIP work by building the unmerged PR.

@Alexays
Copy link
Owner

Alexays commented Nov 24, 2021

@Anakael We should add an experimental flag to enable some modules on Waybar, e.g. this one.

@Anakael
Copy link
Contributor Author

Anakael commented Nov 24, 2021

Ok, I will add.

@AGCaesar
Copy link

Great to see you are still working on this and finished it for the waybar side! Am I right to assume this won't work on sway at the moment because sway is missing the implementation?

@Anakael
Copy link
Contributor Author

Anakael commented Jan 10, 2022

Am I right to assume this won't work on sway at the moment because sway is missing the implementation?

Yes, master is missing of this implementation because protocol is not merged.
If you really want to try it, you can use my WIP branch from here: swaywm/sway#5597

@tamirzb
Copy link
Contributor

tamirzb commented Jan 26, 2022

Hey, sorry to bother you with a noob question, but can you maybe explain why is this needed and what is the different between this and waybar-sway-workspaces? And why would I want to use this and not the sway workspaces module?

@Anakael
Copy link
Contributor Author

Anakael commented Jan 26, 2022

Hey, sorry to bother you with a noob question, but can you maybe explain why is this needed and what is the different between this and waybar-sway-workspaces? And why would I want to use this and not the sway workspaces module?

  1. This one is sway-independent
  2. When it will be fully merged and implemented, it probably be more supported and featured because
    a) more developers can be involved who use other compositors
    b) it will be driven by protocol, not by sway ipc

But as for now this module should be used only for testing purposes.

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.

6 participants