baskerville / bspwm

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

Feature request: Minimize (hide) and "maximize" #229

Closed TiZ-HugLife closed 8 years ago

TiZ-HugLife commented 9 years ago

Hi there. I tried out bspwm inside of Xfce4 sometime back and found the tiling experience to be quite nifty. There were a few problematic details that really turned me off from continuing to use it, though. Namely, it was impossible to minimize or hide windows. They did not respond to wnck requests from either Namebar or DockbarX, and there was no bspc command I could use to do it that I could see in the manpages.

Unless there's something fundamentally wrong with my workflow that I'm not presently realizing, I can see many reasons I'd want to hide a window without closing it. Could you consider implementing such functionality?

Close requests from DBX and Namebar were honored. Maximize requests weren't honored either, yet bspwm already has a feature that is basically equivalent. Could maximize requests simply result in toggling monocle mode with the target window focused?

Stebalien commented 9 years ago

Minimize: Don't. Just move (or move the window) to another desktop. If you really want to, you can use xdo to hide/show windows but there really isn't a reason to do this.

TiZ-HugLife commented 9 years ago

Moving a window to another desktop doesn't seem like a real solution to me; it just seems like condemning one of my desktops to being a clutter space when a perfectly good paradigm exists that would prevent me from doing that.

xdo as a workaround might work as long as clicking on the dbx icon to reshow the hidden window actually works. I may test it out for curiosity, but I'm not feeling particularly encouraged by the response here.

Stebalien commented 9 years ago

No! The idea is that when you start working on a new task, you switch to a new desktop. Each desktop contains the set of windows relevant to an on-going task. I currently have firefox open in desktop one, vim on desktop two where I'm working on a personal project, two terminals on desktop three where I'm grading, and Pithos on desktop 10 (music). For small, I have a drop-down multiplexed (with tmux) terminal that I show/hide with a hotkey.

Minimization is an artifact left-over from the days before multiple desktops and, IMHO, needs to die (GNOME3 tried to kill minimization but I don't know if they were entirely successful...).

TiZ-HugLife commented 9 years ago

Hmm. Music is one of the use-cases where I normally like to minimize. Put on my playlist/radio station, minimize, then bring it back up only to change. Switching to another desktop to control my music player doesn't seem especially intuitive to me, however it also makes sense to me when you describe the notion of concrete tasks. Like, that's something I already use my desktops for with Xfwm4, but I don't presently think of "listening to music" as a task. I'll try doing it this way to see how it feels to me before I take the plunge again.

I'm going to hazard a guess that triggering monocle mode in response to a maximize request is also an unwelcome feature. It really seems like tiling is an all-or-nothing lifestyle. "You do everything our way or you don't do it at all."

Stebalien commented 9 years ago

For music, try the auto_alternate setting. This lets you switch to a desktop and back with one hot key. One of the problems with minimizing is that it often requires a mouse to use properly and many tiling window manager users avoid mice as much as possible.

I'm fine with putting windows into monocle mode on maximize however, to do this correctly, we'd (by we I mean @baskerville) need to implement per-window monocle mode. I also worry that some windows might request to be maximized on start (however, bspwm could always have an option to ignore this).

TiZ-HugLife commented 9 years ago

I'm not sure it would be necessary to do per-window monocle mode. I think it'd be intuitive enough for maximize requests to just go into monocle mode on that workspace, and unmaximize requests to just leave monocle mode.

baskerville commented 9 years ago

If bspwm had tags, then it would be possible to hide/show a group of windows.

However, implementing tags properly would require to store the state of each node of the layout tree for each tag combination. It would also require to have one tree per monitor...

pickfire commented 9 years ago

Some applications would work better if there are tags such as uzbl-browser so it would not be ugly to switch between multiple desktop.

sabrehagen commented 8 years ago

+1 for @TiZ-EX1's request. i have a day to day use case for it, likewise being my media player.

AtzeDeVries commented 8 years ago

I've been thinking about minimizing also. I've figured you could create it yourself using a set of shortcuts. I did not implement it yet. This is the idea

You could also write a script which lists all windows on the 'minimized' desktop and add functionality to send it to the current destkop...

BrainlessFrog commented 8 years ago

@AtzeDeVries I've written a small script a few times ago which does something similar. Basicly, it use xdo to hide windows, and store them in a temporary text file, which is call later to list/select (with dmenu)/show the hidden windows.

I'm not a professional developer, so it's cerntainly not perfect, feel free suggest improvements.

Link

Edit: I use this script in combination with sxhkd (to hide), and a clickable panel (lemonbar) to list the amount of hidden windows and launch the dmenu selector.

neeasade commented 8 years ago

This is going to be a naive comment about tagging possibilities.

A TODO of bspwm is a zoom feature, which would allow a view point distinct from root node. If this were implemented, I would imagine you could script in 'tagging' by managing your windows/nodes like so:

. desktop node
|
|-- active node tags
    |-- tag1 node
        |-- leaf/window under tag1
        |-- leaf/window under tag1
    |-- tag2 node
        |-- leaf/window under tag2
        |-- leaf/window under tag2
|-- inactive node tags
    |-- tag3 node
        |-- leaf/window under tag3 (not visible)
        |-- leaf/window under tag3 (not visible)

If you were do do the above, you could zoom to the active node tags node, and see the visible tags under those nodes, and then transplant nodes from active to inactive as you wanted. You could script the above behavior with bspc after the zoom feature is added.

xintron commented 8 years ago

Just tested out the latest master (f50f1f9) and the hidden feature (minimize) is very welcome. I did however find an interesting note with regards to querying nodes.

My idea was to implement something similar to how i3 handles hidden windows where if you hide two nodes (1 & 2) and then issue "unhide" it fetches the oldest hidden node (1) and unhides it. You can then repeat this behavior by hiding it again (node 1) and issue a new unhide to get the next node (2).

I started playing around with bspc query -N -n 'older.hidden' but that doesn't work. Listing all windows with .hidden do work and the following does also seem to work older.hidden. Is this intended behavior or a bug and if so, should it be a new issue or simple re-open this one?

baskerville commented 8 years ago

Please create a new issue.

This isn't a bug: I'm currently automatically skipping hidden nodes in all the descriptors (except the path descriptor).

The reason being that bspc node -f {next,prev} is preferable to bspc node -f {next,prev}.!hidden

But it might be useful to allow hidden nodes for the history based descriptors.

It won't work as expected though, because older and newer refer to the history of focused node, not the history of node commands.