search

baskerville / bspwm

A tiling window manager based on binary space partitioning
BSD 2-Clause "Simplified" License
7.77k stars 415 forks source link

Feature Request: Keep workspaces/desktops loaded/drawn #478

Open Nohac opened 8 years ago

Nohac commented 8 years ago

It would be really useful if there was a way to tell a specific workspace or all workspaces to always be loaded (drawn). This is useful for e.g. streaming using OBS, where you want to be able to change workspace but keep streaming a specific program grabbed by window capture (Xcomposite). Currently, the recording will just freeze when your not on the same workspace as the program you want to record. It would also be useful for certain edge cases where some software bug out when you change workspace and it's not being drawn anymore. I have a problem where some games will start consuming 100% cpu on one thread when it's on a different workspace, so having this option would solve that as well (this might be a driver issue). This isn't just a problem with bspwm, but all wm's/desktop environments that have workspaces/virtual desktops functionality.

I know that this is a really specific feature request, so I'm not really expecting anything, I don't even know if its possible to implement due to how workspaces work. I just wanted to throw the idea out there, in case it's not to hard to do.

neeasade commented 8 years ago

So, this would be different from the sticky window flag? which not handled at the desktop level, but with bspwm you can script it up however you would like it to work most likely.

webm: https://u.teknik.io/lrn7y.webm

Nohac commented 8 years ago

@neeasade That is not at all what I meant, sorry for not being clear enough. Let me try to explain it a little better, I've also done some digging in the source so I have some clue on how desktops work now.

I don't want windows to be sticky, I actually want desktops to act exactly as they do now, but I want the windows to be hidden in a different way, a way that still makes them receive painting events etc. it's kind of hard to explain.

Unfortunately, after looking at the source code, I see now that this is a limitation with xorg and the way unmapping works, and I can't seem to find a way to hide windows/nodes within bspwm without using xorgs unmap function.

If bsp had some compositor functionality, this would not have been a problem to implement, as you could just hide the pixmap containing the window and just not call the unmap function.

The only solution I currently see possible is to not call the hide_nodes function within hide_desktop on the desktop I want to "keep in memory" and just move the windows/nodes out side of the monitor (an extremely dirty hack in other words).

So in summary, all I want is to tell a specific desktop (e.g. the desktop I have my games on) to not be unmapped, but still hidden when I change to another desktop.

baskerville commented 8 years ago

dwm uses the dirty hack: it doesn't map/unmap anything.

Nohac commented 8 years ago

@baskerville Lol, I didn't know that, does it actually move the windows out of the monitor? Anyways, would you even accept such an option in to bspwm? Something like:

bspc config -d ^3 no_unmap true

This could even work on single windows/nodes to I guess.

neeasade commented 8 years ago

does it actually move the windows out of the monitor?

Could a possible solution be sticky floating nodes moved outside of desktop view/geometry?

On Fri, May 13, 2016 at 9:58 AM, Jonas notifications@github.com wrote:

@baskerville https://github.com/baskerville Lol, I didn't know that, does it actually move the windows out of the monitor? Anyways, would you even accept such an option in to bspwm? Something like:

bspc config -d ^3 no_unmap yes

This could even work on single windows/nodes to I guess.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/baskerville/bspwm/issues/478#issuecomment-219068454

Nathan Isom Computer Science Kansas State University

baskerville commented 8 years ago

@noh4ck Yes I might do that.

IamCarbonMan commented 6 years ago

Any idea if this can be revived?

agorgl commented 6 years ago

Would like this too, might solve the problems that some 3D programs have (like Unity3D) when changing workspaces back and forth

baskerville commented 6 years ago

You might want to try the hide_by_moving branch.

If I remember correctly, a desktop flickering bug can be triggered when focus_follows_pointer is set.

UltraWelfare commented 4 years ago

Sorry for the bump I wasn't able to find any information about this apart from this thread, is there any way to do this (Record an unfocused workspace while still being rendered instead of being frozen) ?

amosbird commented 3 years ago

You might want to try the hide_by_moving branch.

If I remember correctly, a desktop flickering bug can be triggered when focus_follows_pointer is set.

Is there any reason why this branch never gets merged?

opalmay commented 2 years ago

You might want to try the hide_by_moving branch. If I remember correctly, a desktop flickering bug can be triggered when focus_follows_pointer is set.

Is there any reason why this branch never gets merged?

Applications expect your windows to disappear when switching workspaces. With this branch they move outside the view instead. It might be a non-issue for you or very annoying for example with tint2/latte dock (and probably other docks) windows not in the current workspace are reported as belonging to the monitor on the left. It also unintentionally created a cool sliding animation with jonaburg/picom when switching workspaces which you may or may not like but it's a neat side effect for sure.