GNOME Bugzilla – Bug 92867
track a global disable animations xsetting
Last modified: 2008-06-29 22:00:55 UTC
This is my second piece of code ever so please tell me now what I've done wrong. see you, Chris
Created attachment 10979 [details] [review] patch. just a patch.
Please ignore the first two line of the patch, they're trash. see you, Chris
I wonder why the <short> and <long> descriptions are not shown in gconf-editor. see you, Chris
Thanks for the patch, I'm still not a big fan of this feature; maybe we could speed the animation up a little bit by changing the #define for its duration.
reopened. Havoc: Do you like the way we solve the problem? regs, Chris
This is a duplicate of bug 80509. See also discussion in bug 95777. I'm adding the patch keyword to this bug so it's easier to find, should anyone decide they want the patch later. *** This bug has been marked as a duplicate of 80509 ***
Created attachment 12671 [details] [review] Revamped the patch. Now reads the global animation key (see #98426)
This patch is going to get lost on a closed bug, it needs to be on an open bug. For now I'm just lazily reopening this one. metacity tries to avoid reading gnome global settings directly, see: http://mail.gnome.org/archives/wm-spec-list/2002-November/msg00049.html there are various ways to set it up, needs sorting out. Does the panel now toggle/follow this global setting?
You also need to be able to disable animations in GTK, so I would suggest an xsetting (and metacity could track that).
Created attachment 18391 [details] [review] New patch against HEAD. My approach is the same, except that we now have some defs to make the beast GNOME-independent.
That's not quite what I meant - the way it should work is similar to how the double click time setting currently works. i.e. there's a gtk patch first.
*** Bug 118814 has been marked as a duplicate of this bug. ***
The reduced_resources patch on a branch in cvs and in current Red Hat beta packages also disables animation as a side effect. (Though it's total bullshit since the animation uses no measurable CPU...)
The animation does, however, interfere with other windows' display. That's not total BS, Havoc.
For what, half a second? And only when you minimize a window? Don't be so melodramatic. If your application doesn't redraw in response to an expose event then you need to rewrite it.
Purely saying that the animation is not a performance concern, and thus it doesn't make a lot of sense that I lumped it into the reduced_resources setting.
*** Bug 124321 has been marked as a duplicate of this bug. ***
$0.02 from someone who would've filed a bug on this if it didn't already exist: Regardless of the actual resource usage (which, I'll admit, is probably negligible) the animation can create the perception of slowness or unresponsiveness, especially on a system with limited video memory or CPU where the user expects such slowness already. Unfortunately, telling users "it's all in your head, it doesn't really interfere with anything" isn't a very useful response, so it'd probably be a good idea to allow some of this eye candy to be turned off.
*** Bug 134029 has been marked as a duplicate of this bug. ***
Notes: Changed to GNOMEVER2.7 keyword. Added PATCH and bugsquad keywords. Changed to high priority for better visability
Slight update: #142582 was closed. GTK+ guys don't seem to like that kind of xsettings. Is it reasonable to track GNOME's GConf key if it's available? My 2nd patch contained that bit. Note that metacity wouldn't depend on GNOME then, it would just optionally check for the key being set (/desktop/gnome/interface/enable_animations). regs, Chris
Ping. #142582 was reopened.
Comment on attachment 18391 [details] [review] New patch against HEAD. My approach is the same, except that we now have some defs to make the beast GNOME-independent. This uses a gconf key; need to use the XSetting?
Rob: Aren't they in sync? Or is it just an issue of cleanness?
...turns out that the xsetting hasn't been added yet.
Comment on attachment 18391 [details] [review] New patch against HEAD. My approach is the same, except that we now have some defs to make the beast GNOME-independent. I think the gconf key is fine if that's how gnome is doing it. I don't think the configure check is a good idea, as long as we ensure that when the key is unset (not present) we treat it as "animations enabled" - this means using gconf_client_get_value() so we can detect a NULL value. When doing so be sure to check the type of the value when it's not NULL before treating it as bool. meta_prefs_get_enable_animations() should probably return (!reduced_resources && enable_animations) The places where you're calling get_enable_animations() I would expect to have something about reduced_resources now, maybe we hadn't applied reduced_resources patch when you did this patch?
Remove old target milestones on old bugs; sorry for the spam.
It seems that this feature would be appreciated downstream : https://launchpad.net/distros/ubuntu/+source/metacity/+bug/13189 ;-)
Any progress on this one? Continuing discussion from bug 80509. This one probably needs a new name that is closer to what is being proposed here (gconf key). I'm sorry I can't comment on the patches, not being familiar with the codebase.
bug 444659 may be relevant also
I'll see whether I can get something working for the next unstable release.
*** Bug 452636 has been marked as a duplicate of this bug. ***
*** Bug 502644 has been marked as a duplicate of this bug. ***
After the recent refactor of effects.c, this is actually a good deal easier. FIXED.