Cycling - Tiling vs Floating workspaces

[rmt]

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]

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]

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]

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.