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

[Ryan Yeske]

Mike Meyer <address@hidden> writes:

> 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.

True, to a point.  We are not writing a WM for all people though.  The
Right Thing is a perfect balance between all of the forces acting upon
the thing in question.  The forces in this case being (off the top of
my head): the focus on keyboard usage; the behaviour patterns of the
*typical* user group; the current state of the code; the current
design; and the most important underlying philosophy of ratpoison: put
the burden of managing windows on the Window Manager, not the user.

The solution finds the best balance among of the above principles or
constraints is the Right Thing.  We may argue whether or not there are
more "forces" or what weight should be given to each of the forces.
 
> > 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.

I agree, mostly.  However, I'm not convinced that ratpoison should
worry about "incredibly complicated things".  The core of the
ratpoison philosophy (as I understand it) is that software should
strive to cut the fat, so to speak.  Not just in the wm, but in all
areas of software and, in particular, human-computer interaction.

I should probably say more about what "cut the fat" means.  Well, as I
see it, there is a tendancy for software to become more complex in
response to more complex demands of both 1) the users and 2) other
complicated software.  There are other reasons for increase the
complexity of software, but I don't think those reasons are relevant
here.  I would argue that a to a large extent, the complex demands of
users can be explained in terms of existing complicated software.  So,
without knowing exactly what you meant by "incredibly complicated
things", I am going to assume that the motivation for doing these
complicated things comes from demands imposed by the other software
you are using.  The question then is, what do you gain from using this
complicated software?  Do you need to use it?  If so, should the
problem be solved by complicated other software, or by simplifying
existing software?  I believe the latter route should be taken.  My
belief is that spreading the complexity to other peices of software
will lead to infinite madness.

> 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).

Depends how you look at it.  The way I see it, it does one thing,
namely it goes to the window you select.  You can take two paths to
get there, but that isn't exactly the same as saying it does two
different things.

I would say most of the time, if I "select emacs" I want to have
ratpoison do whatever it takes to get me to that window without me
having to think about how to get there.  If that means changing frame
focus, fine.  If it means swapping out my current window, fine.  This
behaviour only becomes a problem when I want to maintain a certain
window/frame layout (read: manage windows).

> 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.

And I would say: I don't want it to work that way.  You have "solved"
a non-problem, IMO.
 
> 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.

All of these discussions really lead us to the point where we have to
say: we need a highly customizable (programmable) WM.

Ryan