GNOME Bugzilla – Bug 622249
Move Tweener.slowDownFactor into St
Last modified: 2010-06-21 14:20:46 UTC
Dumping to bugzilla. Globals in shared code are obviously pure evil - the only (pretty lame) excuse is that St is explicitly limited to shell-internal use.
Created attachment 164186 [details] [review] Move Tweener.slowDownFactor into St It has probably crossed the line to evil by a mile or so, but here it is: a Tweener.slowDownFactor replacement used by all animations without exception.
In this case it would probably make more sense to move the parsing/setting into shell-global.c or gnome-shell-plugin.c (whereever we call st_widget_set_default_direction() from?) and have tweener.js just read it.
oh, also, there's apparently equivalent functionality in "upstream" tweener (gjs's module) now so we should probably use that rather than our own adjustment of the timeline
(In reply to comment #2) > In this case it would probably make more sense to move the parsing/setting into > shell-global.c or gnome-shell-plugin.c (whereever we call > st_widget_set_default_direction() from?) and have tweener.js just read it. Mmmmh - environment.js? If moving into C I'd irrationally prefer gnome-shell-plugin.c over shell-global.c. (In reply to comment #3) > oh, also, there's apparently equivalent functionality in "upstream" tweener > (gjs's module) now so we should probably use that rather than our own > adjustment of the timeline Apparently setTimeScale works "the other way round", e.g. setTimeScale(2) will double the speed, while slowDownFactor = 2 will cut it in half. So does it make more sense to keep the current behavior and adjust the parameter to getTimeScale, or to switch to "upstream" behavior altogether?
(In reply to comment #4) > > (whereever we call > > st_widget_set_default_direction() from?) > > Mmmmh - environment.js? Indeed. Sounds good. > Apparently setTimeScale works "the other way round", e.g. setTimeScale(2) will > double the speed, while slowDownFactor = 2 will cut it in half. So does it make > more sense to keep the current behavior and adjust the parameter to > getTimeScale, or to switch to "upstream" behavior altogether? I did it this way because it's more natural to use integers for the normal case, and the normal case is slowing things down, not speeding them up.
Created attachment 164189 [details] [review] Move Tweener.slowDownFactor into St (In reply to comment #5) > I did it this way because it's more natural to use integers for the normal > case, and the normal case is slowing things down, not speeding them up. Makes sense.
Comment on attachment 164189 [details] [review] Move Tweener.slowDownFactor into St > start : function() { >+ if (St.get_slow_down_factor() > 0) >+ Tweener.setTimeScale(1 / St.get_slow_down_factor()); presumably by putting it in start() rather than init(), it makes it so that calling St.set_slow_down_factor() from lg still works? Oh, I'm pretty sure Tweener.slowDownFactor is documented on live.gnome.org, which will need to be updated.
(In reply to comment #7) > presumably by putting it in start() rather than init(), it makes it so that > calling St.set_slow_down_factor() from lg still works? Yes. > Oh, I'm pretty sure Tweener.slowDownFactor is documented on live.gnome.org, > which will need to be updated. Done. Attachment 164189 [details] pushed as 35764fa - Move Tweener.slowDownFactor into St