I don't understand "distracting" - it lasts 0.35 seconds.
It's not like watching The Matrix. Seriously, what do you mean 
by "distracting"? What is it interfering with? It does not 
bother me.

What it takes to get a preference added is a good rationale,
or new information people hadn't thought of before. There's discussion 
in the resolved bugs as you say (maybe you want to link to them in
this bug), that discussion has to be addressed.

Increasing volume or frequency of requests isn't really relevant 
to whether something is added.

Is this a preference on Mac or Windows? How do they address the same 
issue?

> I don't understand "distracting" - it lasts 0.35 seconds.

No, it lasts nearly a second on my machine.  And anything > 0 secs is
distracting to me.  I'd appreciate it if you could just take my word
for it instead of asking for a scientific explanation  of what
"distracting" is and why I find it to be so.

> It's not like watching The Matrix. Seriously, what do you mean 
> by "distracting"? 

I mean that it bugs the hell out of me to sit there and watch the
animation, when I don't need it.  Every time I see it I say to myself
"there's that damn, pointless, useless, should-be-configurable
animation".  I like a nice, clean, crisp response from the UI - just
do what I asked, no need to give me feedback.


> What is it interfering with? It does not bother me.

If it bothered you, you'd change it and commit the change, I'm sure. 
Are you writing this code just for yourself or for others?  If the
latter, why can't you just accept on good faith the feedback that you
get on this subject?


> Increasing volume or frequency of requests isn't really relevant 
> to whether something is added.

That's not the perspective I'm arguing my point from.


> Is this a preference on Mac or Windows? How do they address the same
> issue?

I don't know, I don't recall (it's been awhile).  But I'm pretty
certain on Win2K that there were either NO minimization animations or
you could configure them into the closet where they belong IMHO.

And why compare this to Windows?  What's next - fade-in desktop
context menus that you can't turn off?  Clippy?

Sorry to sound so strident but turning off animations in your UI is
NOT what I would call a frill feature.  It's doubly frustrating to see
this on Linux which has a history of being unencumbered by this kind
of fluff.  I'm bewildered why you're so resistant to supplying an
option to TURN THAT OFF when others have already supplied patches to
achieve this.

I'm asking for rationale, not rants.

Since somebody asked, here's some background info on the other 'Big
Two' desktops:

- Win XP: gives you no control at all over the 'minimize' effect
(which 'shrinks' the title bar into the taskbar), it's always on.  The
main difference from metacity is that the window isn't unmapped until
after the effect is finished, although I'd have thought that would
make it feel less snappy than metacity... but it doesn't. The effect
itself is too quick to time manually, but it feels fractionally
quicker than metacity's on my 1GHz PIII laptop.

- MacOS 10.1 : doesn't let you switch off the minimize animation
either as far as I can tell (and gives you the option of a
launch/restore animation into the bargain), but does give you a choice
of two different ones-- Genie and Scaled.  Again, too quick to time
manually, but Genie felt about as fast as XP's,and Scaled slightly
quicker, on the G4 in our lab.

We could always change the timeout, it's just a #define to 
0.35 right now, could make it whatever seems appropriate.

OK, that did get a bit ranty -  I'll trim:

1) The animation itself is distracting, and the fact that it can't be
turned off is frustrating.

2) The ability to turn off animations isn't a frill feature;  the
animation itself is more frilly than the ability to turn it off.

3) There is already code available to achieve this.

1) I still take to mean that we don't have the animation good enough; 
it's too ugly or too slow. Since other OS's have non-configurable 
animation and everyone uses those fine. We should work 
on the animation more if it's bad, not turn it off. It has 
an important usability function.

2) is just restating the original claim, not adding rationale.

3) isn't really relevant, if there wasn't code I could write it 
in 15 minutes anyway. It's about maintenance and encouraging 
the right UI direction.

Most users won't find a preference, and moreover most users benefit
from the animation.

Thus if the pref is a workaround for a bad animation, I don't want to
add it. That means the 1% of users who are technical will use the
workaround, and the other 99% of users are stuck. I want the 1% of
technical users to use their technical skills to fix it for everyone.
If they won't fix it for everyone, they should have to live with it,
just like everyone else.

If it's as hard to live with as people say, then it's not OK 
to inflict it on 99% of users.

In short: preferences should never be an "unbreak my application
please" button. The app has to work by default.

> I still take to mean that we don't have the animation good enough; 
> it's too ugly or too slow.

That really isn't the point IMHO.  Countering requests for a
preference to turn animations off with an offer to make animations
really good makes no sense to me - that's the answer to a different
question.  People who dislike animations don't want really good
animations, they simply don't want to see them at all.  

> Thus if the pref is a workaround for a bad animation, I don't want 
> to add it. That means the 1% of users who are technical will use the
> workaround, and the other 99% of users are stuck. I want the 1% of
> technical users to use their technical skills to fix it for 
> everyone. If they won't fix it for everyone, they should have to 
> live with it, just like everyone else.

It's not a workaround.  It's a feature in its own right - an important
one for a window manager, I think - and is only incidental to the
quality of the animation itself.  

Here is my basic point: I don't buy that if you took 20 users who had
never seen a "disable animations" preference, and had them use a
system with unobtrusive, quality animations, that they would
spontaneously ask to be able to turn the animations off. I couldn't
even remember if XP _had_ animations, and I've used XP some, and in
theory I should be sensitive to these things since I implement stuff
like that. 

Anyway, would it be hugely harmful to add just this? Most likely not.
Would it be hugely harmful to add a _bunch_ of stuff like this? Yeah.
It rapidly leads to UI-which-is-union-of-all-historical-UIs-ever.

In any case, the stuff on the GNOME2.x milestone is what I want to fix
for now. We can reconsider this topic someday when the fundamentals
are in better shape.

One short comment:

I basically agree with havoc, only really justifiable reason to
include such a pref imho, is for users on slow machines. In this
minute case it might be reasonable to have such a preference for
speedups, but on the other hand do users of slow machines really
expect to be able to use gnome in general. I have to admit gnome2 on
my p450 (hardly a speed monster by todays standards) does seem pretty
zippy, so i'm not sure if this point even matters hmmmm...did i just
waste everyones time???

> Here is my basic point: I don't buy that if you took 20 users who 
> had never seen a "disable animations" preference, and had them use 
> a system with unobtrusive, quality animations, that they would
> spontaneously ask to be able to turn the animations off. I couldn't
> even remember if XP _had_ animations, and I've used XP some, and in
> theory I should be sensitive to these things since I implement stuff
> like that. 

That's why it's a preference.  I (and anyone who dislikes animations)
could not care less what you (or anyone who does like them) thinks
about them, what makes a good animation or a bad one, etc.  It's a
preference.


> Anyway, would it be hugely harmful to add just this? Most likely 
> not.  Would it be hugely harmful to add a _bunch_ of stuff like 
> this? Yeah. It rapidly leads to
UI-which-is-union-of-all-historical-UIs-ever.

I don't believe configurability is bloat.  It's an essential feature
that allows the user to configure the software to accommodate the way
he works.

I believe the approach you're taking will lead to a mediocre window
manager that will be generally tolerated by the inexperienced user,
barely functional to more experienced users, while being perfection
itself to an extremely small minority.  I would be totally cool with
that if you were writing this software for your own personal use or
the personal use of a few guys working on the project, of course, but
we're talking about the default window manager for Red Hat Linux.


> I basically agree with havoc, only really justifiable reason to
> include such a pref imho, is for users on slow machines. 

No, the justification is that all kinds of people - hopefully a whole
lot more than currently do so - are going to be using Red Hat Linux as
a desktop operating system, and they have different needs and desires
than yours.  Ideally the software should accommodate those needs.

Incidentally - why look to Windows and Mac for clues on how to write a
window manager?  There exist far better models among X window managers
 anyway.  I'm not talking about monstrosities like Enlightment.  Take
a look at IceWM (which I'm going to reinstall shortly).  Efficient,
unobtrusive, highly configurable, highly useful.  And a window manager
like that needn't be confusing for newbies - just configure it with a
sedate set of initial preferences and let the more adept find the
prefs on their own.

FWIW, as you continue on your effort to arrive at the mathematically
perfect, static feature set for the perfect, nonconfigurable window
manager, I leave you with this thought:

You're not setting up a still-life photograph, you're designing a tool.

Created attachment 11641 [details] [review]
Allow animation to be disabled or changed via a gconf key

I'm sure there are reasons to have this patch or not to have this
patch.  But since I wrote it, I figured I'd include this in the bug.

This patch adds a gconf key which allows you to select from the list
of animations that metacity supports, and allows you to disable them
entirely. 

The default is the "wireframe" animation style which will (as is
current behavior) fall back to the "root" style of animation if there
isn't support for it in the X server.

I could imagine an argument that since animations in metacity are
still a little immature, the default should be "none" for now until
they are better developed.

Its hella annoying on my remote X display. Its easily >= 1 sec, and it
gets worse if something else is happening at the same time on the
lowly X server machine that I have.

Please.

The enlightenment minimise animation feels A LOT faster and
sleeker than metacity. One of the best things is that the lines
are a lot thiner making it less obstructive.

Havoc/all:

There is actually a general accessibility requirement to be able to
"turn off all animations" on a desktop.  Exactly which dynamic display
features are covered by the blanket term is unclear, but I would think
that many (but not all) users of accessibility-related technologies
would prefer turning animation off.  The requirement definitely
applies to things like animated gifs, spinners, etc., to any
resize/move feature that generates multiple 'moved' notifications, and
also to anything that causes onscreen "flashing".  I don't know
whether the graphics in the metacity launch feedback or resize stuff
are "blinky" enough to fall afoul of that last requirement, but it may
be safer to leave the option open.

regards,

Bill

There's no flicker, move notifications, or blinky/spinny stuff here.
(If there is, it should just be fixed, cf. discussion on
desktop-devel-list of possible animation improvements.)

I'm much more inclined to follow a desktop-global "no animations" flag 
than to provide specific per-animation tweaks though.

The word "animation" is awfully vague and global; if I move a window, 
that is something moving on the screen; is that an animation? Should
the window just vanish while I'm moving it? Is the mouse cursor an
animation?

An animation is not "anything that moves," and failing that
definition, we need to be more precise about what "no animations"
means. If there were a desktop-global flag, how would we know which
items-that-move to affect?

I have some impression that the line is between either between 
flickery moving and nonflickery moving, or between things that 
are bad on slow displays and things that aren't. So perhaps 
we should have global slow_display and no_flicker flags rather 
than talking about animations.

Not that any user likes flicker, even if it doesn't give them 
seizures...

For me "no animation" means the absolute minimum visual feedack for
some specific action. 
In the case of minimizing the window its already there - the window
disappears from the screen, the taskbar icon changes state.

Is a bit perplexing for me how you refute "distracting". Its simply
_distracting_ - no-needed visual feedback that many people find
annoying. Its in the same league as distracting sounds.

>Its simply _distracting_ - no-needed visual feedback 
>that many people find annoying

I won't dispute that some people find it annoying in it's current
guise, but I will argue against your comment that it's "not needed" :)

When we originally usability tested GNOME, in the days when it had no
minimize animation, many people who came from other UNIX desktops such
as SGI and CDE couldn't work out where their windows had gone and how
to get them back.  As far as they were concerned, they had just
disappeared.

The cause of this problem, of course, was that they were used to
desktops where windows minimize into icons onto the desktop, rather
than onto a panel.  For those people, the animation is an important
visual cue, at least until they get used to GNOME's little
peculiarities :)

Thanks, Calum, I think I understand the rationale  but as I said I'd
like to strive(have the option) for "no animation" - the minimal
needed visual feedack.  And in this case its already there, the window
is no longer on the screen(the window got minimized)  the taskbar icon
changed state (I know where "it went").  The latter is arguably less
distracting than the animation.

basically:
- the proposed patch answers the needs of many people
- it actually uses an already existing "theming mechanism" for this thing
- its use actually removes some codepaths, thus reducing the
possibilties of bugs.
- destributors are still able to do what they want with this depending
on their audience.

Sorry if somebody felt unnecessary flooded. I think the resistance to
accepting this pref is going a bit over the top.

Here are some ways to move this bug up in the priority queue:

 - actually help me with some non-prefs-related issues 
   on the GNOME2.x milestone

 - implement some of the suggested animation improvements

Here are some ways to move it down:

 - post any <aol>, ping, or rant comments

;-)

The resistance to this pref is starting to take on a twilight-zone
quality IMHO, but anyway -


> I'm much more inclined to follow a desktop-global "no animations" 
> flag than to provide specific per-animation tweaks though.

What's the rationale for that?


> If there were a desktop-global flag, how would we know which
> items-that-move to affect?

I agree - per-animation preferences would make more sense.  Whether or
not to make a particular animation a preference should probably depend
on user feedback in bugzilla  :-)


> The word "animation" is awfully vague and global; if I move a 
> window, that is something moving on the screen; is that an 
> animation? Should the window just vanish while I'm moving it? 

When moving a window, an indication of the window border is essential
to completing the task.  You have to know where the window will end
up.  This is not the case with the minimization animation.  As someone
mentioned, the change in taskbar state is sufficient.


> Is the
> mouse cursor an animation?

Is it?


> When we originally usability tested GNOME, in the days when it had 
> no minimize animation, many people who came from other UNIX desktops
> such as SGI and CDE couldn't work out where their windows had gone 
> and how to get them back.  As far as they were concerned, they had 
> just disappeared.

That's why this is an on/off preference issue, not an animation
quality issue.  These people need it - they should have it; but the
presence of any animation will be totally useless and distracting to a
large number of other users.  These users should be able to turn it off.

I really think it's that simple, without digressing into a discussion
of animation quality.

To answer the question if Windows provides this functionality, here 
is the menu path in Windows XP:

My Computer --> Properties --> Advanced --> Performance
   --> Settings --> Animate windows when minimizing and maximizing

For some people, the window animation on minimize may be helpful...
for a while, until they are used to the way GNOME works. For some
people, who like visual flash, the animation is "cool" (and I'll note,
this is how Havoc refers to it in his comments in the code... which
may provide some insight to the resistance he is raising against
adding this preference).

For me, and a lot of other people, animations of this nature are
simply visual clutter and an unnecessary impediment to getting things
done. Window animation, menu slides, menu fades, "smooth" scrolling
and other things of that sort which Windows has become full of lately
introduce non-essential visual effects which by their nature also
introduce delays in the user's interaction with the interface.

In the case of metacity, it introduces a >= 0.35 second delay in
minimizing the window, instead of it being instantaneous (it also can
leave visual artifacts on other windows, such as the Anjuta splash
window). A third of a second is a long time to the human brain,
especially when compared to no time at all. I've already made the
decision to get that window out of the way. I don't want to wait for
it get out of the way, I just want it gone. I usually have something
else that I want to do after that window is out of the way, and having
to wait for it is annoying and frustrating.

You can reduce the animation time, but reducing it to anything more
than an insignificant amount of time (say, < 0.05 seconds) would
result in the animation being useless to someone who actually needs
it, or unsatisfying to someone who wants it for esthetic reasons.

On my desktop, this is no longer an issue, because I wrote a patch for
metacity that adds the gconf bool setting to turn it off. If I have
to, I will maintain this patch in future releases on my own desktop.
I'd rather not have to, and I'm sure the same is true of other people
who've written their own patches too.

The resistance to adding this simple change has reached the point of
absurdity. When you are writing software for an audience (a "user
base" if you will) and a significant number (not necessarily a
majority, just a noticeable fraction) of the audience *strongly*
expresses a desire for a useability change that does not make the
software any less useable for others and is trivial to implement, the
onus should be on the software developer to justify why they should
not implement it (in terms of negative impact on others or on software
performance), not on the audience to justify the change.

In saying this, I am speaking not just from the user's perspective but
from the perspective of a professional software developer with 18
years of experience. You don't blow off the customer. If you do, they
will use someone else's software, and your "cool" features that you
didn't want to change will be left gathering dust on a shelf.

> Here are some ways to move this bug up in the priority queue:
> 
> - actually help me with some non-prefs-related issues 
>   on the GNOME2.x milestone
>
> - implement some of the suggested animation improvements
>
> Here are some ways to move it down:
>
> - post any <aol>, ping, or rant comments

This has obviously become a "control issue" for Havoc.

> - Additional Comments From Havoc Pennington 2002-11-29 12:51 -------

> Here are some ways to move this bug up in the priority queue:
> 
> - actually help me with some non-prefs-related issues 
>   on the GNOME2.x milestone

How about if someone simply offers a fix for the issue at hand (which
more than one person has done) instead of begging your indulgence by
working on stuff that has absolutely nothing to do with the issue at hand?


> - implement some of the suggested animation improvements

What does this have to do with the issue at hand, which is an on/off
pref for window animations?


> Here are some ways to move it down:
>
> - post any <aol>, ping, or rant comments

Frustration is evident in our correspondence because Havoc are acting
irrationally and, it's beginning to seem, with an almost vindictive
obstinance.

> - Additional Comments From Michael Johnson 2002-11-29 11:36 -------
> 
> You don't blow off the customer. If you do, they
> will use someone else's software, and your "cool" features that you
> didn't want to change will be left gathering dust on a shelf.

...as I've already done.  I've removed the GNOME desktop and reverted
back to IceWM.  I like the GNOME desktop but the dumbing-down of the
window manager makes it not worth it.  I'm not just talking about the
animation pref - there is also the fact that dialogs (e.g. Mozilla
dialogs) do not show up in the taskbar, the inability to specify the
layer at which the window is displayed (e.g. "always on top", etc),
and so on.  And given the absurdity surrounding the animation on/off
pref, I hold out little hope of seeing the other issues fixed.

Maybe I'll try agian when Red Hat 8.1 rolls out.

http://pobox.com/~hp/features.html

Anyway, I asked substantive questions in earlier comments on this bug
and on previously-filed bugs on this. No one has answered them.

I'm sorry people didn't want to address the substantive issues, but 
it's not my fault.

I'm going to mark NEEDINFO to make it crystal clear that I am blocking
on the doing of homework. The needed info includes at least:

 - what is an "animation" that needs to be disabled for accessibility   
   or other purposes, vs. just "a thing that moves". Is the 
   dividing line "flicker" or what? I need input from the 
   accessibility team on this.
 - results of experimentation with improving/shortening the animation.
   Has someone actually looked at the Enlightenment code? What does 
   it do? (I think XOR with XGrabServer.) Has anyone tried 
   switching metacity back to that mode? Has anyone tried
   doing the animation with titlebar-only like Windows XP?
 - are we or are we not going to add global GNOME settings 
   for this?
 - if we are, what is the bug number of the control panel bug 
   to implement the global setting and the UI for it?

These are not hoops to jump through. This is homework that should be
done. Otherwise I don't know what the config key is called, whether 
X properties are involved, which things the config key affects, 
where the UI is, etc. Doing this homework would probably take a couple
hours, while writing the patch is probably a 10-minute job. This is
why writing the patch is not really what I need.

Every not-providing-needed-info comment posted scrolls up this comment
which lists the needed info. And thus makes the info less likely to be
provided. So don't post comments unless they address some of the 
interesting questions.

Both the other issues you mention have been or are being addressed,
btw. I did the homework and patch for one and I've gotten some decent
help on the other.

Bugs are addressed when people do the work. The work is not just the 
patch. It's determining and communicating what the patch should do.

Havoc, should this be closed now that wireframe mode is in?

> Havoc, should this be closed now that wireframe mode is in?

if "wireframe" means anything other than the ability to turn off the
animation completely, i'm against closing the bug.

> what is an "animation" that needs to be disabled for accessibility  
> or other purposes, vs. just "a thing that moves".  Is the dividing 
> line "flicker" or what? 

when you drag a window, the outline is displayed because you need that
information to complete the task.  a moving mouse cursor is necessary
because it helps position the cursor and indicates the position of the
cursor once it comes to rest.  the utility of these "movements" are
never diminished over time.

the window minimization animation's sole purpose is to indicate to an
abolute GUI neophyte "where the window goes" when it's minimized.  for
a huge number of users - basically anyone who's ever used a GUI with a
taskbar before, which is in excess of 98% of current desktop computer
users - they are never useful because they already know this.

for the remainder, window animations are useful exactly once in their
lifetimes - the first time they minimize a window and wonder where
their application window "went".  

thereafter, window animations are a distracting waste of time, and to
me and many others, an annoyance.  it's roughly equivalent to never
being able to turn off Clippy.


> I need input from the accessibility team on this.

how can i contact the accessibility team?


> - results of experimentation with improving/shortening the 
> animation.

having experienced this animation on other window managers and other
OS's, the results of my experimentation are: any noticeable animation,
no matter how unobtrusive, is useless, distracting, and annoying.


> are we or are we not going to add global GNOME settings for this?
>
> if we are, what is the bug number of the control panel bug 
> to implement the global setting and the UI for it?

presumably these are questions that are asked after the question of
whether the inability to disable the animation is in fact a
shortcoming in the software to be fixed.  is this the case?

cc'ing bug to accessibility folks

> I'm going to mark NEEDINFO to make it crystal clear that I am 
> blocking on the doing of homework. The needed info includes at
> least:
>
>   - what is an "animation" that needs to be disabled for 
>      accessibility or other purposes, vs. just "a thing that moves". 
>      Is the dividing line "flicker" or what? I need input from the 
>      accessibility team on this.

The full text of the Section 508 rules from the United States 
laying out the accessibility requirements for acquisition by Federal 
agencies can be found 
at: http://www.section508.gov/index.cfm?FuseAction=Content&ID=12

Subpart B contains the technical standards, and specifically 
subsection 1194.21 describes the standards for "Software applications 
and operating systems".  There are two paragraphs in 1194.21 that 
mention animations: 

  1194.21(h) When animation is displayed, the information shall be 
displayable in at least one non-animated presentation mode at the 
option of the user.

  1194.21(k) Software shall not use flashing or blinking text, 
objects, or other elements having a flash or blink frequency greater 
than 2 Hz and lower than 55 Hz.

The first one - 1194.21(h) - is primarily aimed at (a) screen reader 
use with "old-style" screen readers that hashed bitmaps and associated 
names with them [unnecessary in our API-based accessibility world], 
and when thinking about sprite-style animation; and (b) users with 
other visual imairments for whom animation might be sufficiently 
jarring that it impeeded their ability to focus on other aspects of 
the GUI - again sprite-style animation was what was in mind here.

The second one - 1194.21(k) - is explicitly about not triggering 
animation-related siezures.  This one is so important that any 
animation within the refresh period *must* be turned off by default.  


To my knowledge, nobody in the disability research field has stated 
that the existing window closing animation in Microsoft Windows or 
Macintosh poses an accessibility issue under Section 508, or otherwise 
poses a formal accessibility issue.  I will do further research to 
verify this.

Updating status whiteboard to reflect a11y team's assessment of priority.

What's the current state of the story? Users are still complaining on the
animation - it annoys them. Can it be fixed with another updated patch (people
are ready to submit one) for some gconf key which would disable the animation
completely?

There's a reduced_resources flag now which disables animations among other things.
I don't intend to do anything else, though I'd like to see improvements to the
default animation.

I don't understand how after two years of debate, and nearly 3.5 years down the road from when this bug was first opened, the final fix was something that throws the baby out with the bathwater.

I don't want the minimize animation, but I don't want wireframe windows, either.  Why can I only opt out of them as a couple?

Havoc, you asked for rationale and not rant, and lloyd had provided it:

> the window minimization animation's sole purpose is to indicate to an
> abolute GUI neophyte "where the window goes" when it's minimized.  for
> a huge number of users - basically anyone who's ever used a GUI with a
> taskbar before, which is in excess of 98% of current desktop computer
> users - they are never useful because they already know this.
> 
> for the remainder, window animations are useful exactly once in their
> lifetimes - the first time they minimize a window and wonder where
> their application window "went".  
> 
> thereafter, window animations are a distracting waste of time, and to
> me and many others, an annoyance.  it's roughly equivalent to never
> being able to turn off Clippy.

I wholeheartedly agree with this analysis.  Minimize animations are useful to newbies, not useful to anyone else.

The lack of an ability to disable this animation (_alone_, not in a catch-all flag that enables wireframe drawing, for crying out loud!) is completely absurd.  On my Core Duo 1.6 Ghz machine running an Nvidia graphics card, this animation still feels slow and clunky, and is completely superfluous.

In the future, maybe we'll be able to use compiz and get nice fade in and fade out that works smoothly and nicely.  Even then, I'll still want to be able to disable it, because _it serves no purpose for me, and isn't central to metacity's operation_.

In the GNOME community, we've heard mention of "Nat's Pendulum", referring to Nat Friedman's insistence that the GNOME "usability pendulum" has swung too far in the other direction.  The 3.5 years spent blocking on the inclusion of this simple gconf flag, was, I think, a perfect illustration of what Nat meant.  The fact that the flag still isn't there in the form suggested may mean that the damage may just be permanent in this community surrounding metacity development.

Why must gconf be "usable" too?  Don't give me a "reduced_resources" catch-all flag, but give me separate flags to enable/disable certain animations/effects.  Is this really such a usability disaster, or are you just being a Metacity Naz:  "no fine-grained configuration for you!"

As Jeff Waugh has mentioned, religious usability insistence like that expressed in this thread was enough to send many would-be GNOME users and contributors packing for projects like KDE, XFCE, or even to proprietary platforms like OS X.  The damage is deep and felt.  I lost a lot of faith in GNOME personally because of these issues, and am only slowly regaining it.

Has anyone already written a patch which removes the reduced_resources flag and adds this fine-grained control of the minimize and wireframe animations?  If not, I'll write it and attach it to this issue.

I will _not_ open a new bugzilla bug for this, because I think history is important so that we learn from our past mistakes.

I have not written any metacity code in 2+ years, so I'm really giving you a purely bystander kind of opinion - don't blame the people doing the work these days, they will have their own views.

Reviewing the bug, I'd say comment #27 and #21 are still outstanding. Patches to disable metacity animations if animations are globally disabled for the desktop, or patches to fix the default behavior (other platforms pretty much demonstrate that it can be fixed to 99.9% of the world's satisfaction) would make sense to me. My .02.

Also, you could try Compiz which allows all kinds of tuning of this type of thing.