Re: [wmii] Stacks

> One of the reasons I ended up trying groups is that
> the stuff in each group is just "most commonly
> related". So for example, the windows that show output
> images and graphs under "experiments" are things that
> I often want to look at together when I change the
> algorithm & rerun the experiment. Likewise the source
> code windows under "classifier" are windows I often
> want to look at together when I'm changing the source.
> But sometimes I want to view one of the source code
> windows in the classifier group along with the windows
> visible in the experiments group to try and figure out
> which artifact of the code gives those results.
> Likewise lots of other cases where I want windows
> mixed between groups on screen at once. What's useful
> about being able to make all the windows in a group
> visible at once is that once I've finished with a
> mixed setup I can go back to one of the setups with
> just the windows in a given group visible very
> quickly.
In acme you accomplish most of this with dir windows + guide files.
For each project you usually will have a directory, where right
clicking on any file will plumb it an open it no matter what it is,
then you usually have a guide file for various 'recipes' with often
used commands which will produce output into a +error window as
needed. There is also the tag bar for commands more closely associated
with a single window, and one can 'Dump' the current acme state which
can later be restored with acme -l. It's usual to dump whatever setup
you have for a certain project to recall it later.

But all this is a compromise and there is a price: acme is not a 100%
general purpose window manager and needs to interact closely with the
file system, this is not a big deal in Plan 9 because the file system
is dynamic and rather abstracted, and because plumbing makes
interaction from/to acme smooth and painless.

> As I understand pages, they're designed for a more
> long-term division and this sort of thing mixed thing
> is more difficult. (Ie, a window can only be on one
> page at once, so you those no quick way to
> "temporarily" put a window onto a different page, then
> put it back where it came from when finished.)
Ok, let me propose an embarrassing idea: what about window 'tagging'
(ie., associate a set of tags with each window)?

To be honest I have no clue how it might work in practice (maybe a
list of names in the tag? too space wasteful) And then you would need
a way to list all the windows with certain tags, maybe a mechanism
similar to the 'detached virtual page' but with one virtual page per
tag? This might even be able to replace the static concept of pages
and instead just have 'dynamic pages' where all the windows with the
same tag show up, hence allowing a client to be in more than one page.
But I can't think of any sane UI for this, and it probably complicated
things way too much for little or no gain.

And this probably would be quite hard to make work at the wmii-level,
specially given X limitations. At the acme level it seems more
feasible, but then it seems to buy you very little over the current
system and the complexity and how the UI changes might look like is
not clear to me. Maybe an area for further UI research, but certainly
not before wmii-3 is out and completely finished and polished, and
then there are many much more important things to deal with rather
than keep fiddling with the wm.

>
> Anyway, it's not a perfect idea but I do find it
> useful in practice,
I think it would be cool if you could use wmii as a base for further
research in this area, but we should keep the main wmii-branch as
stable and simple as possible. And garbeam should stay away from any
of this research, otherwise wmii will never be in a usable finished
state and he will just keep playing CADT with wmii for ever, and I
think that two years is way more than enough and wmii-3 has a chance
of being 'done' and good enough to not need any more big changes.

uriel
Received on Thu Mar 02 2006 - 15:04:00 UTC