Toggle special workspaces

[vito]

I haven’t yet been able to reproduce this, but it kinda sounds like you are opening the document on the special workspace.
So when you close the workspace, the document goes with it.
what do you have in your exclusions and launched_from options?

exclusions should be a table of selectors for apps you want to always open in the same special workspace as thunar is on.
launched_from should be the class you want to target for launching apps that should be demoted, in the event you want to restrict the behaviour to only one app. It should either be non-existant (any file manager will demote its launched apps to the workspace below) or ‘class:thunar’ for thunar. (I would have ‘class:nemo’ as i use nemo rather than thunar)
So for your use case, i would suggest:

local demote_opts = {
  exclusions = {
    'initial_title:Nextcloud - Thunar',
    'class:thunar',
  },
  demote_from = 'name:special:thunar',
}

hl.on('window.open_early', function(w)
  require('utils').demote_from_special_workspace(w, demote_opts)
end)

[vito]

@derxen

It turns out that the offending windowrule was the following, which had been suggested to me by Sanjay:

hl.on ("window.open",function()
	local w = hl.get_active_window()
	local a = hl.get_active_workspace()
	if w.initial_title ~= "Nextcloud - Thunar" and w.class ~= "thunar" and w.initial_title ~= nil and w.class ~= nil then
		hl.dispatch(hl.dsp.window.move({ workspace = a.id }))
	end
end)

It makes sure that files that are opened from the special workspace with thunar go the workspace below it. But apparently this conflicts with the toggling of the other special workspace with alacritty. Any idea why? Also, now I need another way to make sure files opened from thunar go the workspace below it.

Earliar quote:

And two window rules:

hl.workspace_rule({ workspace = "special:thunar", on_created_empty = "uwsm-app thunar" })
hl.workspace_rule({ workspace = "special:terminal", on_created_empty = "uwsm-app alacritty" })

Also, i notice you never got a response to why this might be occurring…
I think the reason why that rule was stopping your special terminal workspace from working is as follows:

1. you open an empty special workspace that has a rule stating: if empty, open alacritty.
2. the above rule set to run on window.open sees the launch of alacritty and immediately demotes it as it doesnt match the conditions in the if statement.
3. As the alacritty terminal is moved, the special workspace closes.

This would have all occurred in a matter of milliseconds, so i think that was the cause of your initial issue.

[derxen]

Thanks Vito. Yes, that’s what I have:

local demote_opts = {
  exclusions = { 'class:thunar' },
  launched_from = 'class:thunar',
  demote_from = 'name:special:thunar',
}

hl.on('window.open_early', function(w)
  require('utils').demote_from_special_workspace(w, demote_opts)
end)

[derxen]

About the older solution: yes, I understand! Thanks, that must have been the reason. The function for thunar kicks alacritty off its special workspace.

[vito]

If it continues to occur, try removing the launched_from property, just in case.
so it looks like this:

local demote_opts = {
  exclusions = { 'class:thunar' },
  demote_from = 'name:special:thunar',
}

hl.on('window.open_early', function(w)
  require('utils').demote_from_special_workspace(w, demote_opts)
end)

If for example, you run a bash script, that then launches something, it would not be launched from ‘class:thunar’, and would then remain on the special workspace.
And if you have a rule somewhere that sets thunar to a floating window, that is potentially maximised, then whatever you open that stays on that special workspace, would be hidden behind the thunar floating window, and you would have no access to it until you closed thunar on that workspace.

By removing the launched_from property, it will demote anything except thunar, that is launched from any app in that special:thunar workspace.

[derxen]

Thanks. I’ll let you know how it goes.

[derxen]

It happened again. Opened a file from thunar on its special workspace. The file opens under thunar, but thunar stays (and they’re on all workspaces). Toggling the special workspace makes both the other window and thunar disapear and reappear. When I close thunar the other window remains. So as you guessed they’re both on the same special workspace. I had not touched the windowrules.

[derxen]

Could it have something to do with uwsm? I switched from using uwsm-app back to standard uwsm app and the problem has not occurred again.

[vito]

I’m not sure mate, i have never used uwsm-app.
I have always just used uwsm directly, via uwsm app -- <appname>.
But i guess there’s potential for that to be the case, as i have never been able to reproduce the behaviour you mentioned.

Could be that if you want to use uwsm-app you might need to find out an identifier you can use to target it, and include that in the launched_from via a more general regex style selector.

I personally don’t understand the need for a separate app to do what uwsm already does natively