Connecting/disconnecting a monitor destroys persistent workspaces set by plugins

[zjeffer]

1. Load a plugin that creates workspaces and sets persistency to true on them (not in the config but directly on the CWorkspace object)
2. Connect or disconnect a monitor (or use hyprctl to create/remove a virtual output)
3. Upon connecting, all persistent workspaces will be destroyed (on every monitor)

My logs when disconnecting HDMI-A-2: persistent-workspaces.log. It should keep workspaces 1-10 persistent, but it destroys all workspaces except for the ones that weren't empty. 11-15 belong to HDMI-A-2 so they can be destroyed as the monitor is removed.

This started happening after #11239 or the commit mentioned in this discussion: #11210

More info: zjeffer/split-monitor-workspaces#200. Apparently it also happens when locking/suspending the system.

[vaxerski]

this is expected, the system now rechecks persistent workspaces every time the state might have changed. Check ccompositor::recheckpersistentworkspaces or something I am on phone and holiday

[zjeffer]

I see, it's here:

Hyprland/src/Compositor.cpp

Lines 3189 to 3206 in 584b844

	if (!pWorkspace) {
	// check non-persistent and downgrade if workspace is no longer persistent
	std::vector<PHLWORKSPACEREF> toDowngrade;
	for (auto& w : getWorkspaces()) {
	if (!w->isPersistent())
	continue;
	if (std::ranges::contains(persistentFound, w.lock()))
	continue;
	toDowngrade.emplace_back(w);
	}
	for (auto& ws : toDowngrade) {
	ws->setPersistent(false);
	}
	}
	}

This is really annoying though because this means that plugins can no longer properly manage persistent workspaces. It now basically has to be done through the hyprland config, but letting a plugin change the config causes the onConfigReloaded callback to trigger, which is also not what I want.

---

I'm still confused that we need a plugin to do the following:

• At startup, make x workspaces per monitor automatically persistent
• Create keybinds to switch to the nth workspace on the focused monitor when for example pressing super + n, (n being a number)
• Connecting a new monitor also automatically creates x persistent workspaces.

This is standard in many other window managers like bspwm, awesome, dwm, etc. but Hyprland requires an external plugin. Are there any plans to add this functionality to Hyprland?

[vaxerski]

No, it's actually simpler than ever before.

It's really simple - just hold a SP to it in your plugin, that's it. Workspaces stay alive when they have a ref.

[zjeffer]

Will they still be marked as persistent, though?
Waybar uses the persistence flag to determine whether to show the workspace, and how it should be styled.

[zjeffer]

Seems to work: zjeffer/split-monitor-workspaces#205

Like I thought, they are marked as non-persistent, but I misremembered how Waybar shows persistent workspaces: persistent styling is done by checking if the workspace is empty, rather than checking the persistent flag, so it works the same. Other apps that do use the persistent flag might break, though.

---

@vaxerski what's your opinion on my other question, about being able to move all this functionality to Hyprland, instead of doing it through a plugin?

[vaxerski]

why? Plugin works well.

[zjeffer]

A couple of reasons:

• It's standard in many wms
• To avoid possible bugs caused by upstream changes (like the bug described in this discussion). If it was part of Hyprland it can be properly tested and have higher quality. Doing it through a plugin always feels like a hack to me.
  • Like i said above, the recent changes in the persistency logic could make some apps that are dependent on the persistency flag break, if used together with the split-monitor-workspaces plugin, as it keeps the workspace alive without it being marked as persistent.
• Better integration with other apps. I put a lot of work in making it work well with Waybar's hyprland/workpaces module without making the user add more configuration. If it was part of Hyprland this wouldn't be necessary at all.
• It's a pretty popular plugin so many people would benefit from this.
• https://github.com/shezdy/hyprsplit also exists and does pretty much the same thing, so this is confusing for anyone who wants this type of functionality. If it was part of Hyprland it can just be a couple of config options instead of having to find some random person's plugin.
• Doing it through plugins means having the user has to run hyprpm update on every update of Hyprland or the plugin. This is the case for all plugins but I only use this one, I can imagine more people only use 1 plugin. I also have to update the plugin's hyprpm.toml file every Hyprland release (which doesn't happen often but it's still annoying).

To be clear, I'm not asking you specifically to implement this. Rather to consider how (on a high level) it could be added to Hyprland, as I think this feature could have quite a big impact on workspace management logic. I'd love to help with the implementation of it where I can.