Special workspace -> normal workspace

Ricing
, ,
1

I am considering putting my file manager on a dedicated special workspace. But I want the files I open via the file manager to open on the normal workspace underneath the special workspace. Is that possible?

2

I’m not sure if you could do it when opening the window because I don’t know how file managers open files usually, but you could try setting up window rules for either whatever opens your files, or everything other than your file manager to not open in your special workspace.

3

Thanks, I’ll give that a try.

4

And the result is bizarre. Here is what I did:

hl.window_rule({
    name = thunar_rule,
    match = {
        class = "negative:thunar"
    },
    workspace = "special:thunar[false]"
})

And files I open from thunar do not open in the special workspace. Just what I wanted. But when I toggle the special workspace with thunar again, the document (a pdf for example) disappears, nowhere to be found on any of the workspaces. Then when I open another file from thunar, that document appears and the first document reappears too. As if what is opened from thunar on the special workspace somehow remains connected to it.
Thoughts?

5

That’s the weirdest thing I’ve ever heard happen. Try and find out where the file goes (after it disappeared) with hyprctl clients, it should tell you the workspace it’s at.

6

Probably I need to try your case, but I’m using nemo should not be a big difference. But configuring it with window.open or window.open_early should do it. I will update this later.

Reference : Expanding functionality – Hyprland Wiki

did I just figured it out ? One of the example is

hl.bind("SUPER + X", function()
  local w = hl.get_active_window()
  if w ~= nil and w.title == "htop" do
    hl.dispatch(hl.dsp.window.float({ action = "set" }))
  else
    hl.dispatch(hl.dsp.window.float({ action = "toggle" }))
  end
end)

and my own keybinding

hl.bind(mainMod .. " + SHIFT + 0", function()
	local active_workspace = hl.get_active_workspace().id
	hl.dispatch(hl.dsp.window.move({ workspace = active_workspace }))
end)

But now can we do it like this

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

I have tested this it works, I’m pretty sure you are good with my keybindings than that hl.on :face_with_peeking_eye:.

At one point I realise making use of tables and comparing over for loop is the best choice.

7

It’s even stranger than I thought. A document I open from thunar with these settings ends up on workspace -97, special:thunar[false]. when I toggle thunar, the document disappears, but it is still listed as being on workspace -97, special:thunar[false]. Then if I toggle my terminal, which is on its own special workspace, that too is listed as being on workspace -97, special:thunar[false], and: the document reappears too, behind the terminal. Meanwhile, thunar remains on its own workspace -98, special:thunar.

8

Thanks, Sanjay. I’m not a hyprland expert, but do I understand correctly that you used your keybinding to move windows opened by nemo from the special workspace to the workspace underneath? And that the new hl.on automatically moves any window opened by nemo to the workspace underneath?

9

can you try removing the windowrule and only try with what I suggested. both of them may not play well together. u don’t need to remove blur effects, but the part which you describe workspace. i.e workspace = x

I’m on hl-git. Also double check the configs for duplicate entries, this you may not be aware but I have spent days for just figuring this out, just check for duplicate lines.

10

Marvelous, that works. Thank you so much. So in the hl.on, the second initial_title and class refer to the window opened from nemo (or thunar in my case)?

11

you can use hyprprop or hyprctl clients to figure this out open a thunar window in special workspace and then use hyprprop to get it’s properties. observe what properties are unique to it, also the hl.on applies to windows after creation and moves it comparison with nil is to avoid error.

few of them I can guess

  • workspace
  • initial_title
  • title
  • class

in the rule I’m explicitly saying that if the given window isn’t belongs to given set of properties of a windows please move them to workspace below it, whenever it is created. I tend to understand it in that way. hope this is helpful.

I just found out that adding a nill condition for w is preffered if it gets exited. i.e w ~= nil