Re: [RP] Patch for frames et al...

[Mike Meyer]

Ryan Yeske <address@hidden> types:
> Mike Meyer <address@hidden> writes:
> > Ryan Yeske <address@hidden> types:
> > > I knew we should have never added split screen :)
> > Yeah - you attract people who want to use it like an X window manager
> > and not a clone of screen :-).
> The fact is we have split screen and people find it useful.  We *do*
> need a way to make it work Right.

Yes, but "work right" may not be the same thing for all people.

> > I was about to explain how my vision of a framed window manager should
> > work, and how that differed from the behavior that ratpoison has -
> > which might help explain where this is coming from.
> > 
> > I think that each frame should act like an invocation of
> > ratpoison. Once a window is opened in a frame, it stays in that frame
> > until the user *explicitly* moves it. If I do "other" in one frame, I
> > get the other window for that frame. If I then go to another window
> > and do "other", I don't get the window I just hid in the previous
> > frame, I get the "other" window for *that* frame. Likewise, "next" and
> > "previous" walk through a list of windows associated with *that*
> > frame, not all the windows.
> 
> OK, lemme make sure I'm reading right:
> 
> frame "Bob" has windows "b1", "b2", and "b3".
> frame "Mary" has windows "m1", "m2", and "m3".
> 
> If I am in the "Mary" frame, I can cycle between (and only between)
> "m1", "m2", and "m3" with the usual rp commands next, prev, and other.
> If I want "Mary" to show "b1", I have to somehow move it from "Bob".

Right.

[Discussion of restrict deleted.]

> Are the above suggestions compatible with your vision?

For the most part. Moving windows between frames should be simple.
The idea is not to make things incredibly complicated, but to make
incredibly complicated things possible without making simple things
any harder.

Since we've cracked the door on the window/frame interaction, let me
slam it open with by pointing out some of the things that happen in
window/frame interaction in rp that are simply bad design.(1)

The "select" command does one of two things. That, by itself, is a bad
thing - it means that the user has to stop and think about which of
those two things are going to happen, and deal with it. Or deal with
it when the "wrong" one of the two happens.

Anyway, "select" either opens the selected window in the current
frame, or moves the focus to the frame that that window is currently
open in. The latter is the second bad thing - the focus should only be
moved by an explicit act of the user, never as a side effect of some
other actions (2).

Both problems can be changed by having select always open the selected
window in the current frame. Select would then have one action, and
focus would never change. This is basically the "pull" command
discussed here earlier, which my windows/frame menu and
"ratpoison-get-a" scripst now and if I could figure out how to rebind
"'" in .ratpoisonrc, I'd rebind it to pull.

Come to think of it, that may be the itch that I was really trying to
scratch. I still like the idea of each frame having it's own "other"
window, but that's a minor detail more than anything else given
select.

        Thanx,
        <mike

1) I'm using Jef Raskin's "The Humane Interface" as a reference for
good design. Jef Raskin made his mark by designing the Mac interface.
In his book he recants some of the truly bad things about the Mac UI,
most notably "click to type" and the overuse of icons.

2) RP get accolades by finding a third interaction mode between the
mouse and the active window by ignoring the mouse. That has the same
problem that "click to type" does, in that there can be two points of
activity, which is one more than most people can handle. But never
mind that now.

--
Mike Meyer <address@hidden>                     http://www.mired.org/home/mwm/
Q: How do you make the gods laugh?              A: Tell them your plans.