A lot of how I try to think about window manager type
stuff comes from saying "how do I work in the
real-world on a desk, and how might that translate
into computer terms?". Keeping this in mind might help
see the approach I'm coming from.
--- Uriel <lost.goblin_AT_gmail.com> wrote:
> The Sort command in acme is quite handy for this,
> and also use columns
> to group related windows.
One thing I'm experimenting with in Medea & my hacked
Ion3 is allowing windows to be grouped into sets
assigned a string label (eg, "experiments",
"classifier", "gui", ...) and then having a WM command
to "make visible all windows in group 'x'", which is
doing something similar. And that helps me a
reasonable amount.
> I still think that no GUI will ever scale well to a
> extremely high
> number of elements (eg., >100), but stacks of tag
> bars scale much more
> and better than tabs ever will.
Yes, that's probably true in general.
> A solution is (once more) a textual interface with a
> specialized
> language, see the sam language which has various
> operations to iterate
> over sets of files making managing huge amounts of
> files much more
> practical.
The kind of thing I'm thinking about is: if I'm
working on a calculation or algorithm on my desk in
the real world I may have five--ten pieces of paper
with writing on them, maybe one--ten printed out
papers and maybe even a book or two open. If I decide
I want to check an equation from "the paper on density
estimation" I know (without becoming too conscious of
it) where I last put it; maybe it was in that pile of
three or four papers in the upper right hand corner,
so I have to flick through the papers until I
recognise the general layout and I have it in my hand
to look at.
What's interesting about the above sequence is not
that it's hyper-efficient, but rather what I DON'T
have to do. I don't have to think: that's a paper in
pdf format, so I have to go through "pdf object
inspection mode" to look at it. (That's be analogous
to focussing the pdf reader and searching for it in
"Previously opened files" menu.) Likewise, I don't
have to think "it's exact title was 'New perspectives
on density...', so scan down the list of files for N,
now make sure I get that one and not 'New
perspecitivity relations in multi-camera...' "
A sort of equivalent of the real world approach is the
"expose" facility in OS X. From other people I've seen
using it, this works quite well where you've got very
visually distinct windows -- analogous to the
differently formatted papers in the real world -- but
it falls down for stuff like source-code windows where
everything looks the same.
Still, I'm idly trying to find a better answer...
> Still acme stacks are the best compromise I can
> think of for a window manager.
>
> (Also if your project has more than a dozen files,
> you are probably
> doing something wrong, if there are more than 30
> files you have to
> edit at one given time, something is seriously
> wrong)
Let's agree to differ on the question of whether there
can be approriate cases when a given program's source
can comprise more than 12/30/whatever files.
One point to note however is that I'm not necessarily
actively editing each file, they're files which I
might need to edit or look at (to read comments
surrounding a function, etc.). I personally tend to
always load every file in a project into the editor
I'm using on start-up rather than try and select the
minimal required set. I'm typically only looking at
four--six on-screen at any one time, and I'd guess the
active set rarely rises above 12--15. However, making
the WM the process that selects what's visible on
screen (rather one layer of wm and on-top of that
application -- eg, editor, browser,... -- specific
layer) does raise the question of which choosing
mechanism is best for the user. (Note this isn't
necessarily just source code -- it could be pdf
documents, web browser windows, graphs, etc.) So I
think that a good research area is what form of choice
mechanism works best for the user (and I say research
because I don't know what the answer is! ) and this is
orthogonal to the issue of whether source code
directories should be very small.
cheers, dave
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Received on Wed Mar 01 2006 - 22:59:27 UTC
This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:00:28 UTC