![star leaf fringed in moon gate [─► this sweetgum leaf was before erroneously starred as a maple leaf ◄─]](http://farm2.static.flickr.com/1283/994941366_2f4aa29b4e.jpg)
GNOME bug 105188 suggests that prelighting– lighting up buttons when you hover the mouse over them to confirm that it’s okay to press them– should fade in from the non-prelit state. This was originally said to require a change to the theme format, but in fact I can’t see that it does: any theme which defines a prelit state for buttons can fade gently from one to the other.
Perhaps there should be an option to turn this on, or perhaps it should just be the default way to behave and stay there.
Photo © quapan, cc-by-nc.
You’d want a theme format-change so that the theme could specify the fade delay – some themes might want the change to be instant, some (perhaps more organically styled) themes might want the delay to be long. Some themes that are emulating some specific look might want to copy a specific delay.
There should probably be a gconf maximum-fade-length as well – I recall playing with a version of Opera that had a half-second fade-in prelight effect on toolbar buttons, and found it incredibly annoying and frustrating; possibly because the animation kept pulling my attention away from whatever it was I was trying to do.
A final thought: Mac OS X is very careful in the use of fading animations in its interface; in particular, menus fade out when you’ve chosen a menu-item but they do not fade *in* – they just appear instantly. This makes menus feel to use, but still looks good. It might be worth having separate ‘prelight fade-in time’ and ‘prelight fade-out time’ settings.
If there was to be any fading by default, I’d suggest fading out on mouse-out, rather than fading in on mouse-over… you want immediate, snappy feedback when you mouse over something, a ponderous fade-in could make things feel slow and imprecise.
(IIRC this is how the tooltips behave on the Mac dock, for example.)