ratpoison-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mike Meyer
Subject: Re: [RP] Patch for frames et al...
Date: Thu Nov 8 00:28:03 2001

Doug Kearns <address@hidden> types:
> On Sun, Nov 04, 2001 at 07:08:20PM -0600, Mike Meyer wrote:
> > Doug Kearns <address@hidden> types:
> > > On Mon, Oct 29, 2001 at 08:22:38AM -0600, Mike Meyer wrote:
> > > > There's also a "place" command, that takes two arguments. The first is
> > > > what would be used by select to choose a window, the second is what
> > > > would be used by selectframe to choose a frame. The selected window is
> > > > opened in the selected frame. If it was open in another frame, the
> > > > "next" window will be opened in that frame if possible. If there is no
> > > > "next" window, the frame will be blanked.
> > > I was initially surprised that the 'place' command changes the current
> > > frame to that specified as the the second argument.
> > > What is the rationale for this behaviour ?
> > 
> > It was duplicating my actions in doing that kind of thing.
> > 
> > What behavior did you expect - and why?
> Well, I would have thought that your current frame remained unchanged
> and next window became the current window.

I think you're missing some of the possibilities of place, because the
behavior you described could lead to the current window not being in
the current frame :-). It sounds like you're using it as a "put the
current window in another frame" command, which I can see would also
be useful.

Just to be clear on this, there can be as many as four different
windows and three different frames involved in a "place": the current
window (1) and frame (i), though place may not deal with them
directly; the placed window (2) and the frame (ii) it started in; the
frame (iii) that window (2 again) is placed in and the window (3) that
occupied it before the place; and of course the next window (4).

What you're saying is that focus should stay in frame i and window 4
should become current. That only works if frame i and frame iii are
the same, because window 4 is going to open in frame iii. Frame i
(Window 1) can be either of frame ii (window 2) or iii (3), but it
doesn't have to be either of them.(*)

> That just seems more natural to me. You're really performing two
> operations with the current implementation - a 'place' and then a
> 'focus*'. I think these should be separate operations.

It should be straightforward to create two new commands that front end
for place, giving:

"push frame" - Shorthand for "place current_window() frame", except
               focus stays in the current frame.
"pull window" - Shorthand for "place window current_frame()".

Those are probably more useful than place in interactive use, as place
was meant for scripts to solve the "How do I script window X into
frame Y" problem.

While I'm asking, note that it would be pretty simple to make window 3
- if it actually exists - the "next" window before selecting the
window to open in frame iii in the place mechanism. That would make
the push and pull commands "exchange" commands - "exch" and
"exchframe" - with the next window opening in any frame that wound up
empty afterwards.

I like the idea of "pull window" enough that I'll problably do
this. Wether it's the push/pull names and behaviors or the exch[frame]
ones doesn't make much difference to me, and is easy to change later.

        <mike

*) [Monotone voice] The story you have just read is true. Only the
   numbers have been changed to protect the innocent.
--
Mike Meyer <address@hidden>                     http://www.mired.org/home/mwm/
Q: How do you make the gods laugh?              A: Tell them your plans.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]