Cycling - Tiling vs Floating workspaces

BurntSushi / wingo

A fully-featured window manager written in Go.

Do What The F*ck You Want To Public License

1k stars 86 forks source link

Cycling - Tiling vs Floating workspaces #105

Open rmt opened 10 years ago

rmt commented 10 years ago

In my opinion it would be nice to either make CycleClientNext/Prev more lightweight (raise & focus window, border-highlight only) so that it's more like AutoNext/AutoPrev; or make AutoNext/AutoPrev fallback to something sensible on a floating workspace. I'm coming from an openbox background, and find the approach there very intuitive (highlighting the window that you will switch to)

BurntSushi commented 10 years ago

I would very much like to have a border-highlight feature for the CycleClient{Next,Prev} commands. I think to add this, the CycleChoice interface in prompt/cycle_item.go would need to get a CycleUnhighlighted method. Then xclient/prompts.go would need to get some plumbing to add X windows-as-borders when CycleHighlighted is called and destroy those windows when CycleUnhighlighted is called.

sgelb commented 7 years ago

Just selecting the client by adding c.CycleSelected() to CycleHighlighted in xclient/prompts.go works just fine with my setup. Or do i miss something?

sgelb commented 7 years ago

Yes, I did miss some things.

canceling the prompt should be broken. When calling the prompt, I already know that I want to change clients, so I never used that feature.
c.CycleSelected() is called again on the same client when the keys are released. as it is called for each new selection anyway, this may be fine. a cleaner solution is mentioned in the comment for keyResponse() in prompt/cycle.go, setting CycleConfig.AutoChoose = false. But this doesn't seem to be implemented.

I use the prompt for changing clients only, so I don't know if this breaks things in regard of other uses.