Re: A slick feature

[raster redhat com]

On 24 Feb, Richard Rose scribbled:
->  Hi there,
->  
->  I'm new to Gnome (ok, let's be honest, I've d/l'ed it at work, but not 
->  actually loaded it on my machine at home, due to lack of space), but I 
->  have a suggestion, which I'd like people (preferably developers in 
->  general) to look at, and make comments on, and if the idea seems 
->  feasible, I'll post it to the development list, as an entry for the 
->  wish list.
->  
->  The idea is this:
->  When an application is minimised, with this option selected, it fades 
->  to glass.

this is up to the WM only and not gnome. (nb - you havent tried the
translucent move mode in E have you? :) you're just begging for eye
candy here).

->  The way I envisage it working is like this.
->  When an application minimises, the root window passes a structure to 
->  the WM containing a reference to itself, it's children, and the colour 
->  palette it's using. The WM calculates a set of colours fading roughly 
->  down to the colours from the section or root window behind it are 
->  calculated, and the colours are rapidly reassigned, making the fade 
->  effect. The intermediate colours can then be dumped, leaving you only 
->  with the original colours saved somewhere, and the root window colours, 
->  which is what can be seen through the lost-focus objects. To make it 
->  "glassy", the edges of each widget inside the window, and the window 
->  itself would have to have a light grey/white border.
->  
->  This feature could realistically only be implemented in 24bpp or 
->  higher, I think, due to the number of colours that may be needed, but 

actaully try tanslucent move.. you'll be surprised - ti works in 8bpp,
15bpp, 16bpp and 24bpp :) - what you want isnt possible because the Wm
can't get all the framebuffer data under the window to be able to fade
it to that color (this is the way X works).

->  if anyone thinks it can be done with less bpp, please voice your 
->  opinion, and preferably with a reason. A way to optimise the routines 
->  would be to save the colours needed when the objects lose focus, as 
->  they will only be brought back into focus or killed afterwards. If they 
->  are killed, then the colours can be dumped, if the are to be brought 
->  back into focus, then they will not have moved, as they would have had 
->  to get the focus back to have moved. Once the object is in focus, then 
->  you can safely dump the extra colours. Again, if RAM is excessively 
->  plentiful, the extra colours can be saved until the object is actually 
->  moved, saving calculation time if the object isn't moved.
->  
->  In my opinion, this would be *very* nice, but I can see that there 
->  would be problems with it. For example, what if you run out of colours? 
->  What if you are copying text from one window/application to another? To 
->  overcome the second problem is quite easy. This feature could be 
->  implemented as an alternative to the minimise styles that are already 
->  present.
->  
->  Comments/suggestions? I'm sure that's what the list is for.
->  
->  Richard Rose  -  Network Consultant  -  Zen Internet
->  Richard.Rose@zen.co.uk
->  
->  
->  

-- 
--------------- 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 Enlightenment   http://www.rasterman.com/

              \|/ ____ \|/  For those of you unaware. This face here is in fact
	      "@'/ ,. \@"   a Linux Kernel Error Message.
	      /_| \__/ |_\
		 \__U_/