[Top][All Lists]

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

Re: [RP] dockapps

From: Joe Corneli
Subject: Re: [RP] dockapps
Date: Sat Jul 10 20:29:23 2004

   Joe's idea is to associate each window list (group) with a set of
   frames, rather than one frame or all frames.


Basically what this amounts to is multiplexing the RP world as we
know it, and providing appropriate commands for interaction between
parallel worlds.  Or virtual desktops if you prefer this more
traditional jargon.

   So you can, for example, have four wmfoo dockapp windows
   associated [with a] pair of frames.  At any time, two wmfoo
   clients are visible in separate frames.  next/prev in those two
   frames will cycle within the wmfoo list (group).  next/prev in
   any other frame[set] will cycle through a different list, which
   does not contain the four wmfoo clients.

   Am I still on the right track here?

I think you've captured what I was saying, after I made one
important edit to what you said.


You currently have it set up so that wmfoo-client-1 and
wmfoo-client-2 are visible on screen.  You can move between frames
with :fselect or :focus, and you can choose which window is active
in the current frame with :next &c.

Or you can type :wfnext and then you might have a situation where
you have


Now, at first when I was reading what you wrote, it sounded like you
were talking about having two (or more) different windowframes
onscreen at the same time -- e.g. something like



This is a perfectly acceptable idea, but I didn't have this in mind.
I was thinking there would be one windowframe onscreen at a given
point time.

I'm not at sure that you _were_ talking about having two
windowframes on at once -- but when you said "in any other frame
[...] cycle through a different list" it seemed like a very real
possibility that you might have one of these "other" frames onscreen
at a given point in time. (Also you said "at any time, two wmfoo
clients are visible in separate frames" -- this didn't preclude
there being some other clients visible in other frames.)

At any rate, whether or not you meant that there might be more than
one windowframe onscreen at a given point in time, I personally
think _one_ windowframe at a time is sufficient.  Any added
functionality one might seem to get by having more could probably be
achieved using traditional groups:



So to conclude, what I meant is that _every_ frame that is onscreen
is uniquely associated with the current windowframe; every window
that is onscreen is associated with the current windowframe (but not
necessarily uniquely, i.e. they could be associated with other
windowframes as well), and some windows that are not onscreen can be
associated with the current windowframe as well.  Every _other_
frame is, according to this definition, _not_ onscreen.  If this is
what you meant by "other frame" then you were exactly on track with
what I was saying. If not, I hope I've made what I was saying more

There still seems like plenty to sort out vis a vis the exact
relationship of groups to the windows, frames, and windowframes, but
let's leave that for a later time.

reply via email to

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