Re: [RP] dockapps

[Trent Buck]

Quoth Cameron Patrick on or about 2004-07-10:

> Nifty!  I've have thought that the window numbers used by fdump and
> frestore wouldn't be stable though...  The main problem that I can see

Frame numbers are definitely not stable on multihead displays.  When
frestoring, frames get the number they had at dump time, unless a
frame with that number already exists, in which case it gets the first
unallocated number, starting at 0.

All frames on the current head are removed before frestore starts to
parse its input.

> with it is that 'C-t Q' does the wrong thing.  You could solve that by
> binding C-t Q to an frestore I suppose (though it wouldn't do /quite/
> the same thing).

Which is why you wrote the xinerama patch, right? :-)

> > all the stuff along the bottom of the screen is in its own group, so
> > as not to interfere with the normal ratpoison goodness going on in the
> > large frame.
> 
> I'm not too fond of groups in general but this sounds like a
> pretty good use of them.
> 
> This post reminded me of an idea of mine that I've been meaning to
> post to the mailing list.  I think it would be useful, at times, to
> glue together a bunch of frames into a single window (from the
> perspective of :windows, :next, :prev, :select etc).  So I could have,
> e.g. a few xterms tiled and sitting next to each other, and that would
> be just one window that I flick through with 'C-t n' but I could use
> the usual frame commands to select a particular xterm.  :windows might
> hypothetically show
> 
>   0*xterm
>   1-xterm, xterm, xterm
>   2-XMMS, XMMS Playlist
>   3-Mozilla
> 
> That would save messing around with fdump/frestore (which I don't
> like, partly because they're broken w.r.t. xinerama and I haven't

Not anymore.  See
http://yoyo.its.monash.edu.au/~trent/src/ratpoison/fixes.patch for the
fix.  (Two operations were the wrong way around.)

> bothered to fix them yet -- because I don't like them, and so it goes
> :-P). This might also be yet another way of making the Gimp more
> usable under ratpoison.
> 
> It would require introducing 'nested frames' of some sort, which would
> be tricky.  I'm not sure quite what the best way to handle this would be.

TreeWM does this.  Perhaps it has useful code?

I suggest the way to think about this is to have a 'dereference' and,
er, reference? operations for framesets or windowsets.  Then
everything else acts as normal, but only upon the current `layer' or
`level of focus'.

The way we split frames leads logically to a binary tree structure
(probably it would simplify code for resizing, etc, though I haven't
looked at it), and nesting would evolve automatically.  But I suspect
that LISt Processing is something you'll have a hard time dragging
developers away from :-)

-trent
-- 
It's not video games' fault that it's fun to kill people.