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

[Mike Meyer]

Ryan Yeske <address@hidden> types:
> 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.

I'm not sure I understand that last one. How does RP help remove the
burden of managing windows? Maybe there's a paper on the philosophy
that I've missed.

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

Let me clarify: it should be possible to do "incredibly complicated
things" so long as doing them doesn't add noticable fat anywhere else.
In particular, if it breaks the simple things that users are used to,
then it's probably a bad idea.

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

Your assumption is wrong. The "incredibly complicated things" could
involve nothing more than xterms. It's not quite that simple, but all
the tasks at hand could be done in xterms instead of the tools I'm
using - just not as well - without changing the things I want to do.

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

To quote Tom Lehrer: "When correctly viewed, everything is lewd".

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

It also becomes a problem if the frame you're currently in is to small
for to use emacs in. You have to change frames in order to use emacs,
there's just no way around it. Having a command that takes you to a
frame big enough for emacs only if emacs is visible leads to
surprising - and useless behavior. Having a simple command to get to a
frame suitable for emacs - which the frames patch provides - means I
can go there and then get emacs, no matter where it is.

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

That's a good argument for having both. The change in bindings means I
no longer get surprised by select - because I never use it. I consider
that solving a problem. If you're never surprised, then it's not a
problem for you.

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

All open source window managers are highly customizable; it's just
that cc is a clumsy customization tool. Is that why there's interest
in a LISP version?

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