Re: A Proposal For The Addition Of Color-Reactiveness To The GNOME Desktop
- From: raster redhat com
- To: rlb cs utexas edu
- cc: bjp primenet com, gnome-list gnome org, gnome-gui-list gnome org
- Subject: Re: A Proposal For The Addition Of Color-Reactiveness To The GNOME Desktop
- Date: Wed, 20 May 1998 09:57:01 -0400 (EDT)
On 20 May, Rob Browning shouted:
->
-> I'm not sure what I think of all this, but I do have a couple of
-> comments:
->
-> 1) I think that instead of beacons for the icons, that if you wanted
-> to pursue this, applications should just be allowed to treat
-> their icons as small windows, and should have a good drawing
-> toolkit for rendering into them. For example, why shouldn't an
-> iconized FTP transfer, in addition to having a light indicating
-> the state of the connection, have a small pie chart, numeric
-> display, or other progress meter showing the percent complete?
-> Same thing goes for other apps. An iconized rendering window
-> could show a minaturized version of it's progress so that it
-> would be easy to see how far it's gotten.
->
-> And this is somewhat half-baked, but I had always thought it
-> might be interesting (and really easy if we had display
-> postscript systems) to have some windows just iconify to smaller
-> versions (say %20) of themselves so you could still see what they
-> were doing, even when they were "out of the way". You should
-> even still be able see enough detail to tell when say a long
-> compile in an xterm was finished.
the "icons as windows" system already exists in X and is part of the
basic ICCCM specs.
-> 2) Using the type of strings you describe to represent the color
-> transitions seems like a limiting idea. Off the top of my head,
-> you'd be better off using something like this
->
-> "B=DarkBlue R=Red G=#007700 B 1.0 R 0.2 G 0.5"
->
-> where you define the colors, then use them in an alternating list
-> which contains alternating pairs of a color abbreviation and a
-> time in seconds. This makes it much more flexible (and easier to
-> read) when specifying long periods. It also links the delays to
-> wall-clock time in a very obvious manner, something you probably
-> should do.
->
-> Just a couple of thoughts...
->
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com /\___ /\ ___/||\___ ____/|/\___ raster@redhat.com
Carsten Haitzler | _ //__\\ __||_ __\\ ___|| _ / Red Hat Advanced
218/21 Conner Drive || // __ \\_ \ | | \ _/_|| / Development Labs
Chapel Hill NC 27514 USA ||\\\/ \//__/ |_| /___/||\\ 919 547 0012 ext 282
+1 (919) 929 9443, 801 4392 For pure Enlightenmenthttp://www.rasterman.com/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]