GNOME Bugzilla – Bug 142582
Add animation xsetting
Last modified: 2013-02-04 02:35:14 UTC
Metacity and others display animations. Some people don't want this. Therefore we should have an animation xsetting. regs, Chris
Created attachment 27734 [details] [review] Proposed patch against GTK+ 2.4.
The XSETTINGS support in GTK+ is meant for controlling GTK+ features.
The animation in the toolbar should qualify, bug 143648
*** Bug 143648 has been marked as a duplicate of this bug. ***
Here is a list of timouts in gtk which control animation, scrolling and various forms of repeat. Most of these are hardcoded. As billh said, if the resulting timers are actually significant to the user. i.e. does the animation provide information which the user might otherwise miss? Does the timer require the user to take action within a certain length of time? if answer==yes, then it has to be configurable. gtkbutton.c ACTIVATE_TIMEOUT 250 gtkcalendar.c CALENDAR_TIMER_DELAY 20 gtkcalendar.c CALENDAR_INITIAL_TIMER_DELAY 200 gtkcellrenderertext.c popdown timeout 500 gtkclist.c SCROLL_TIME 100 gtkcombobox.c SCROLL_TIME 100 gtkdnd.c ANIM_STEP_TIME 50 gtkentry.c gtk-cursor-blink-time gtkentry.c COMPLETION_TIMEOUT 300 gtkexpander.c animation timeout 50 gtkiconview.c scroll timeout 30 gtkimage.c animation delay time gtklist.c SCROLL_TIME 100 gtkmenu.c MENU_SCROLL_TIMEOUT1 50 gtkmenu.c MENU_SCROLL_TIMEOUT2 50 gtkmenu.c gtk-menu-popdown-delay gtkmenuitem.c gtk-menu-popup-delay gtknotebook.c NOTEBOOK_INIT_SCROLL_DELAY 200 gtknotebook.c NOTEBOOK_SCROLL_DELAY 100 gtkrange.c SCROLL_INITIAL_DELAY 250 gtkrange.c SCROLL_LATER_DELAY 100 gtkrange.c UPDATE_DELAY 300 gtkspinbutton.c SPIN_BUTTON_INITIAL_TIMER_DELAY 200 gtkspinbutton.c SPIN_BUTTON_TIMER_DELAY 20 gtktext.c SCROLL_TIME 100 gtktextview.c gtk-cursor-blink-time gtktextview.c scroll timeout 50 gtktooltips.c DEFAULT_DELAY 500 gtktooltips.c STICKY_DELAY 0 gtktreeview.c open row timeout 500 gtktreeview.c scroll row timeout 150 gtktreeview.c expand collapse timeout 50 gtktreeview.c search popdown timeout 200 Maybe it would be enough to add a setting to control the speed of the various repeat operations (also allow to turn them off completely), a setting to control the speed of scrolling, and a setting to control speed of animations (also allow to turn them off completely). Then apply them appropriately in the cases above. We may also need a few additional parameters for ACTIVATION_TIMEOUT in gtkbutton.c or DEFAULT_DELAY in gtktooltips.c
Marking as AP3 to reflect accessibility impact.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Possibilities, as I see them: 1) make each setting independently configurable, plus add a 'no animations' boolean; PROS: fine control CONS: too many configurations! 2) make everything relative to some magic value, so that times all scale by some factor PROS: easy CONS: simpleminded scaling will result in poor usability for some values 3) provide 4 values for each setting, corresponding to 'no timeout', 'very slow', 'slow', 'default', and use a gconf key to select a "set" of timeouts accordingly. PROS: potentially best usability, simpler config interface CONS: slightly more difficult than #2, and may be difficult or semantically confusing to implement "no timeout" for some settings; 4) group the timeouts into rough categories, for instance "scrolling speed", "autoscroll timeout", etc. and combine to reduce the total number of timeouts to a manageable set. PROS: clean conceptually, best usability w.r.t. configuration dialog, probably best from accessibility POV. CONS: will take more thought to consolidate settings 4)
Created attachment 54231 [details] [review] Implement GtkSettings stuff for button click/repeat delays Attached patch against HEAD was factored out of maemo GTK+, and modified and enhanced a bit. It adds two settings "gtk-initial-timeout" and "gtk-update-timeout" which are used for button press+hold timeouts that work like key press+hold timeouts. I went for default values of 200 for initial and 20 for update, update is used as-is, or multiplied by 5, depending on the use case. The patch also changes two timeouts, namely GtkRange is now 200/100 (was 250/100) GtkPathBar is now 200/100 (was 300/150), it's now the same as GtkNotebook Also, I think the repeat timeout in GtkCalendar (currently 20) is way too fast, but I may miss the reasoning behind the fast repeat rate.
Note that this patch is only a partial fix for the problem described in detail in comments #1 and #5. Also, we need a way to turn off animations altogether. So, please don't close this bug as FIXED if and when the existing patch is applied... Is the patch sufficiently general? Bill
As said, the patch addresses all cases where mouse clicking triggers a repetetive action which has initial and repeat timeouts. Widgets affected are: GtkCalendar GtkNotebook GtkRange GtkSpinButton GtkPathBar
Thanks Michael. How about cases where keyboard action triggers initial and repeat timeouts? Also important are 'animations' for things that don't repeat, for instance expander actions, tooltip popups, etc.
Hm, keyboard timeouts/delays should already be configured for the entire desktop and should be the same for all applications. I didn't care about animation timeouts, since the maemo patch I was starting from addresses button actions only. I don't think that's a big problem since the patch addresses its own class of problems, so could be applied without creating inconsistency.
I am not talking about key repeat here. This bug was/is initially about animation settings. Perhaps your patch should be applied against a separate bug which this one marks as a dependency?
Well not much in this bug refers to animations except the original report. And it has a nice list of timeouts that need to be checked. The patch fixes one class of these timeouts. I don't see the need for a separate bug.
after chatting some with mitch: 1) the timeouts should be renamed to gtk-timeout-initial and gtk-timeout-repeat 2) the patch looks good in how it generalizes delay and repetition timeouts 3) generalizing/exporting the scroll delays still hard coded as factors can be worked on later if neccessary. i.e. given (1) is fixed, the patch should be applied.
Created attachment 54910 [details] [review] Updated patch with renamed properties
Fixed in CVS for the timeouts that determine initial/repeat delays on button_press: 2005-11-22 Michael Natterer <mitch@imendio.com> Made button-press timeouts which work like key repeat timeouts configurable. Addresses bug #142582: * gtk/gtksettings.c: added properties "gtk-timeout-initial" and "gtk-timeout-repeat" which defalt to 200/20 (ms). Use the values from GtkSettings instead of hardcoding them (the repeat value is either taken as-is for fast repeat or multiplied by 5 for slow repeat). Changed all places to use these two standard initial/repeat timings: * gtk/gtkcalendar.c (unchanged 200/20) * gtk/gtknotebook.c (unchanged 200/100) * gtk/gtkpathbar.c (changed from 300/150 to 200/100) * gtk/gtkrange.c (changed from 250/100 to 200/100) * gtk/gtkspinbutton.c (unchanged 200/20)
Created attachment 55196 [details] [review] Patch from maemo-gtk to disable toolbar animations Attached patch works fine with GtkToolbar, however there are two issues: - it uses a property of its own "gtk-toolbar-animation" where it should probably use a global setting as in attachment #27734 [details] from comment #1 - the user setting should perhaps be overridable on a per-instance basis? I think these two issues need to be resolved before the patch can go to cvs.
i don't think per toolbar animation settings make sense. they are as useless as per text entry repeat rates would be. should we add an animation toggle setting for toolbars only or for all kinds of widget animations? well, some users don't like animations or are confused by them, and on some platforms animations are not suitable due to power or cpu constraints, so being able to switch all off at once will be an improvement in these cases. so the patch should be changed to introduce a global "gtk-enable-animations" setting as in attachment #27734 [details] and at the moment only use it for toggling the toolbar animations. if we figure we need a toolbar-specific or other-widget-specific animation setting later on, we can still add that.
Created attachment 55227 [details] [review] Updated patch using a global settings property
Is the last patch OK to commit?
the patch looks ok to me except for: +#define DEFAULT_ANIMATION_STATE TRUE that definition is useless, the value will be overridden upon the first screen change anyway. provided this is fixed, the patch should go into CVS.
Hmm, we connect three signal handlers to "notify" on settings there now. Might be nicer to just have one signal handler and dispatch on the detail. Or maybe its not important, applications don't usually have hundreds of toolbars, so it shouldn't make a big difference.
Tim thinks its a good idea to consolidate the notify handlers into a single one. Can you do that, Mitch ?
Done. Left the #define there because its value is used twice and it feels cleaner to have it given that settings can become NULL. 2005-12-01 Michael Natterer <mitch@imendio.com> Merged modified patch from maemo-gtk that allows to disable toolbar animations. Addresses bug #142582. * gtk/gtksettings.c: added boolean property "gtk-enable-animations". (patch from Christian Neumair) * gtk/gtktoolbar.c: don't animate toolbar changes if the settings property is FALSE. Replaced the individual "notify::foo" connections to GtkSettings by a single "notify" callback and dispatch internally.
Mitch, is anything left to do on this bug ?
The only other animations that come to my mind are the expanders in GtkExpander and GtkTreeView. They should probably be addressed too. Can you think of something else?
no
Fixed for GtkExpander: 2006-01-12 Michael Natterer <mitch@imendio.com> * gtk/gtkexpander.c (gtk_expander_set_expanded): skip the animation if the gtk-enable-animations setting is FALSE (bug #142582).
Created attachment 57217 [details] [review] Honor gtk-enable-animations in GtkTreeView Attached patch feels simple enough to commit right away, but I refuse to touch GtkTreeView without approval :-)
the patch looks good to me, but since it affects rbnode flags, i want jrb or kris to give the final approval for it.
Looks good to me.
Fixed for GtkTreeView: 2006-01-13 Michael Natterer <mitch@imendio.com> * gtk/gtktreeview.c (gtk_tree_view_real_expand_row) (gtk_tree_view_real_collapse_row): don't animate the expander arrows if gtk-enable-animations is FALSE (bug #142582). The main topic of this bug is fixed now. However there is this nice list of timeouts that need to be made configurable. Should we close this bug anyway?
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
mitch, did we ever fix the too fast key repeats for some things ? I remember federico complained about something, was it the calendar ?
Calendar uses 200/100 ms too now: 2006-07-17 Michael Natterer <mitch@imendio.com> * gtk/gtkcalendar.c (calendar_timer): use 5 * gtk-timeout-repeat, just as many other widgets. Makes the calendar arrow buttons usable for quick month/year skipping (#142582).
Any reason to keep this bug REOPENED?
Yes - the original scope still hasn't been addressed, since AFAIK the settings above are gtk-specific and are not used by metacity and/or other desktop utilities. Since we want this to be available to non-gconf apps, XSETTINGS is a good way to implement it. However IMO the global XSETTING should not be in the gtk+ namespace.
the gsetting that backs the xsetting, org.gnome.desktop.interface.enable-animations, is used by other parts of the desktop. In particular, we are workign on making gnome-shell respect it in 3.8