>I'm running the experimental color-X kit on (what I now know to be =) a
>16MHz 030...  I run fvwm2, and have had two compiles running, a povray
>render going, a digital clock and an xload in the corner going at the same
>time.. and its really not *that* bad..  (just don't solid drag whole
>windows, for goodness sake)

Just don't drag a window at all :) The redraw on windows is terrible. See if
you can run Nedit while you do what you're describing and type something
without losing your mind.

>Great idea!  About color-ls, though:  I compiled and patched gnu ls to do
>color and can say from experience: even on a small dir, color lssing is
>2-3 times slower than without.. (without being ls -F)  *However*, gnu ls
>*without* color runs, on large dirs, 2-3 times *faster* than the default
>netbsd binary distribution.. go figure!  (And, according to 'time', it
>uses about 1/10 the system resources)

I can't see how this can slow things down much. All ls has to do is when
it outputs files is send out a vt100 code to change the color to the file
color and when it outputs directories send out a vt100 code to change
the color to the directory color. The obvious optimization is to scan the
dir before hand and findout where blocks of colored text are and then
send the code out before the block. They must be sending out the vt100
code everytime. If you're using a vt300 or something to view the colored
text then I can imagine why it's slowing down your ls.

Of course, color isn't the only thing dt would have to offer in this mode.
I'd also like to add dynamically loadable keyboard maps and fonts. However,
this is all rather in the distance since I have to finish the video driver
first.


_______________________________________________________________________
 Michael Zucca - mrz5149@rit.cs.rit.edu - http://www.rit.edu/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
_______________________________________________________________________