[openbox] Using Next/PreviousWindow with client-list-combined-menu

[Clay Barnes]

On 18:52 Thu 07 Jun     , Tore Anderson wrote:
> * Dana Jansens
> 
> >Have you tried the directional focus actions?  They'll let you move
> >around a cluttered desktop with a different perspective.
> 
>   I use those all the time, that's why I wrote them.  ;-)  But they're
>  not always optimal.  I tend to often end up with a stack of Xterms
>  exactly on top of each other - the directional focus actions will only
>  be able to focus one of them (and I never know which one - often enough
>  it's not the one on top of the stack, which is surprising every time).

I year or two ago I argued against window tabs (I'm sure it's in the
archives) but I'm curious whether you think this would alleviate your
issues.  Not that I'm suggesting tabs for OB3, as they don't fit in
the paradigm that it uses (I've refined my theoretical position and I
see certain uses in other window management designs, though.).

> 
>   Also I find myself wanting to go to a window that I can't currently
>  spot.  In that case I usually start out NextWindow-stepping, and if it
>  takes me too long I abort, and open client-list-combined-menu instead
>  and use up/down to get where I want.

Though their motivation was something I disagree on, Apple came up
with the best solution I've seen for this scenario with Exposé "show
all windows." (They base their work on the theory that window
management in any form is complicated and scary for users, and piles of
disorganized windows are the only way to "organize"
applications---even though switching then requires an intellectual
O(n) search every time.)  Perhaps someone could develop a fast, light
all-window preview app to use with OB for this scenario (I'm sure the
OB3 community would balk at adding that much code to the project
itself.) that could then make the focus-change call in a WM-independent
way (I know virtually no X libraries, so I may be wrong about the
feasibility of that).

> 
>   It would be nice if that could be done in one step.  Start NextWindow-
>  stepping, and at the same time look for the window I'm looking for.  If
>  it's a long way until I get there, start stepping faster (or keep Tab
>  pressed).  If it was one of those rare occasions where I have my arm
>  resting on the mouse, I could just use that instead.  I could quickly
>  fly past the non-interesting windows in the list because I've already
>  identified my target.  With the current NextWindow dialog I can't,
>  because I don't know what my target is until I've reached it.

I agree on this point.  It would significantly help to have an option
for showing all names in the dialog.

> 
>   I also sometimes want to go to windows I can't see, and I don't know
>  which desktop it is on.  I've developed a habit to start NextWindow-

[... snip ...]

>  before finding it - should've used PreviousWindow instead, but there's
>  no way to know that until it's too late...
> 
> Regards
> -- 
> Tore Anderson

This brings to mind a longstanding issue I've had---I turn off window
decorations because they aren't useful for me, but without them, I
have issues sometimes using directional focus.  Say I just switched to
a workspace perfectly filled with terminals.  I don't know which is
focused, but I want to get to one on the west edge of the screen, so I
start direction focusing west... but nothing happens.  I check my
finger placement, and when it's fine, I realize that a window on the
west edge is already focused.  Now I have to do a direction focus to
the east to get the highlighting box to show up, then focus back west
before I can start traveling up or down the edge to the application I
wanted (assuming I hadn't just wasted my time because my desired
application was already focused).

That was a very long-winded way of asking for the option to highlight
the currently focused app, even if my direction-focus command hasn't
changed which one it is.


A second issue I now recall is that when I chroot keychains it
would be *really* nice if the dialogs could be made "sticky" in that
whatever was the last shown dialog (like the window-switch) would stay
visible until I un-chroot (or even better hit a dialog clear action).
Specifically, I use a chroot much the same way someone might use the
alt-key in an application switch---they hold alt down and the dialog
stays around so they can choose to continue on in stepping through the
list or release it to leave it.  Think about that in a chroot---the
dialog disappears (unless you add a modifier) and that function is
crippled.

(Speaking of chroots, I would also appreciate an option to set the
text shown in the little dialog (or supplement it) so I can put things
like the "use" of the binding ("Now in Change Window Focus mode") and
the ways to exit it ("Quit with any key on the F* row").)

I know I've added a real laundry list of desired features, but as
chroot is still new, I fear some tweaking in how it works is
inevitable.


Does anyone have comments or suggestions?

-- 
Clay Barnes