The Sort command in acme is quite handy for this, and also use columns
to group related windows.
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.
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.
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)
uriel
On 3/1/06, David Tweed <tweed314_AT_yahoo.co.uk> wrote:
>
> --- Aaron Griffin <aaronmgriffin_AT_gmail.com> wrote:
>
> > On 2/28/06, Nico Golde <nico_AT_ngolde.de> wrote:
> > As for my input - I like the stacking, it's very
> > much like acme.
>
> Another view (probably a lunatic fringe view :-) ).
> Whilst stacking is an improvement on lots of other
> ways of doing window management, one "issue" is
> scalability. If you've got ten windows it then, to
> judge from brief experience with the similar facility
> in acme, it works quite well; if you've got fifty
> windows it starts to become awkward to figure out
> where stuff is. (Apart from anything else, reading &
> searching 50 element lists tends to force my attention
> away from what I'm trying to do and onto the window
> manager.)
>
> (To answer the obvious question, I prefer to have "all
> areas of content as first-class windows", rather than
> having first a true window manager level, then
> application specific multiplexers in the form of emacs
> buffers, firefox tabs, materm tabs, etc. Apart from
> anything else it saves me from having to figure out
> which application is responsible for a given piece of
> content in order to make it visible on the screen;
> instead I just have to find the content in a window
> manager menu/whatever. Consequently, if I'm working on
> a project with 40-odd files I can easily have 50 full
> X windows (most of them not visible at any one time)
> in existance.)
>
> Of course, I don't have a particularly better
> solution. Due to wmii's rapid flux rate recently I'm
> currently messing around with a slightly hacked Ion3
> as a window manager. I've tried some stuff with
> automatically building multi-level menus for selecting
> windows (using some dodgy heuristics based on the
> window name) and, for me personally, it works better
> than the other things I've tried, but it's still a
> long way from perfect. In particular, there's still
> the problem that, due to common parts of file names --
> eg, movementClassifier.cc, movementClassifier.hh,
> movementClassifierModule.cc,
> movementClassifierModule.hh, roleClassifier.cc,
> roleClassifierModule.cc, .... ad nauseam -- picking
> the name you want out of a menu still requires looking
> at menu items that it requires concentration to tell
> apart.
>
> I'd certainly be interested if anyone has any ideas
> for better WM navigation mechanisms when there are
> lots of windows, and I'd imagine that if anyone can
> come up with any good ones it might be of interest to
> Anselm and the other wmii coders.
>
> Anyway, just my 2 pence,
> cheers, dave tweed
>
>
>
> ___________________________________________________________
> NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/
>
> _______________________________________________
> wmii_AT_wmii.de mailing list
> http://wmii.de/cgi-bin/mailman/listinfo/wmii
>
Received on Wed Mar 01 2006 - 02:57:34 UTC
This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:00:20 UTC