2011-09-28 09:16:26 -04:00
|
|
|
// -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*-
|
2009-02-10 11:12:58 -05:00
|
|
|
|
|
|
|
const Clutter = imports.gi.Clutter;
|
2013-01-26 03:41:46 -05:00
|
|
|
const Gio = imports.gi.Gio;
|
tweener: make timeline loop indefinitely
Tweener uses a clutter timeline to manage all active animations
running at a given moment. The timeline is mopped up when no
animations are going any more.
Clutter requires timelines to have a finite duration, but since
animations can happen at any moment, no fixed duration can
accomodate the shell's needs.
To combat this problem, the tweener code picks a relatively
long duration: 1000 seconds. No string of animations should take
that long, so, in theory, that should be good enough.
Unfortunately, this tactic fails, in practice, when the user
suspends their machine, or VT switches. An animation can take
much longer than 1000 seconds (~16 minutes) to complete in those
cases. When the user resumes, or VT switches back the timeline
completes immediately (since it's already late) and tweener
never notices that the timeline stops ticking.
This commit changes the tweener timeline to automatically loop
back to 0 after completing, so that despite its fixed duration
property, it effectively never stops. Since the timeline loops,
its concept of elapsed time no longer increases monotonically,
so we now ignore it and track time ourselves with
GLib.get_monotonic_time().
This partially reverts commit
35764fa09e4341e79732409c4e74c226d19f780f.
https://bugzilla.gnome.org/show_bug.cgi?id=653833
2012-02-16 13:29:46 -05:00
|
|
|
const GLib = imports.gi.GLib;
|
2009-02-10 11:12:58 -05:00
|
|
|
const Lang = imports.lang;
|
|
|
|
const Mainloop = imports.mainloop;
|
2010-05-24 09:48:41 -04:00
|
|
|
const Shell = imports.gi.Shell;
|
2010-06-19 22:16:06 -04:00
|
|
|
const St = imports.gi.St;
|
2009-02-10 11:12:58 -05:00
|
|
|
const Signals = imports.signals;
|
|
|
|
const Tweener = imports.tweener.tweener;
|
|
|
|
|
|
|
|
// This is a wrapper around imports.tweener.tweener that adds a bit of
|
|
|
|
// Clutter integration and some additional callbacks:
|
|
|
|
//
|
|
|
|
// 1. If the tweening target is a Clutter.Actor, then the tweenings
|
|
|
|
// will automatically be removed if the actor is destroyed
|
|
|
|
//
|
|
|
|
// 2. If target._delegate.onAnimationStart() exists, it will be
|
|
|
|
// called when the target starts being animated.
|
|
|
|
//
|
|
|
|
// 3. If target._delegate.onAnimationComplete() exists, it will be
|
|
|
|
// called once the target is no longer being animated.
|
|
|
|
//
|
|
|
|
// The onAnimationStart() and onAnimationComplete() callbacks differ
|
|
|
|
// from the tweener onStart and onComplete parameters, in that (1)
|
|
|
|
// they track whether or not the target has *any* tweens attached to
|
|
|
|
// it, as opposed to be called for *each* tween, and (2)
|
|
|
|
// onAnimationComplete() is always called when the object stops being
|
|
|
|
// animated, regardless of whether it stopped normally or abnormally.
|
|
|
|
//
|
|
|
|
// onAnimationComplete() is called at idle time, which means that if a
|
|
|
|
// tween completes and then another is added before returning to the
|
|
|
|
// main loop, the complete callback will not be called (until the new
|
|
|
|
// tween finishes).
|
|
|
|
|
|
|
|
|
|
|
|
// ActionScript Tweener methods that imports.tweener.tweener doesn't
|
|
|
|
// currently implement: getTweens, getVersion, registerTransition,
|
|
|
|
// setTimeScale, updateTime.
|
|
|
|
|
|
|
|
// imports.tweener.tweener methods that we don't re-export:
|
|
|
|
// pauseAllTweens, removeAllTweens, resumeAllTweens. (It would be hard
|
|
|
|
// to clean up properly after removeAllTweens, and also, any code that
|
|
|
|
// calls any of these is almost certainly wrong anyway, because they
|
|
|
|
// affect the entire application.)
|
|
|
|
|
2013-01-26 03:41:46 -05:00
|
|
|
let animationSettings = null;
|
|
|
|
|
2009-02-10 11:12:58 -05:00
|
|
|
// Called from Main.start
|
|
|
|
function init() {
|
|
|
|
Tweener.setFrameTicker(new ClutterFrameTicker());
|
2013-01-26 03:41:46 -05:00
|
|
|
animationSettings = new Gio.Settings({ schema: 'org.gnome.desktop.interface' });
|
2009-02-10 11:12:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
function addCaller(target, tweeningParameters) {
|
|
|
|
_wrapTweening(target, tweeningParameters);
|
|
|
|
Tweener.addCaller(target, tweeningParameters);
|
|
|
|
}
|
|
|
|
|
|
|
|
function addTween(target, tweeningParameters) {
|
|
|
|
_wrapTweening(target, tweeningParameters);
|
|
|
|
Tweener.addTween(target, tweeningParameters);
|
|
|
|
}
|
|
|
|
|
|
|
|
function _wrapTweening(target, tweeningParameters) {
|
|
|
|
let state = _getTweenState(target);
|
|
|
|
|
2011-02-22 09:25:48 -05:00
|
|
|
if (!state.destroyedId) {
|
|
|
|
if (target instanceof Clutter.Actor) {
|
|
|
|
state.actor = target;
|
|
|
|
state.destroyedId = target.connect('destroy', _actorDestroyed);
|
|
|
|
} else if (target.actor && target.actor instanceof Clutter.Actor) {
|
|
|
|
state.actor = target.actor;
|
|
|
|
state.destroyedId = target.actor.connect('destroy', function() { _actorDestroyed(target); });
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-26 03:41:46 -05:00
|
|
|
if (!animationSettings.get_boolean('enable-animations'))
|
|
|
|
tweeningParameters['time'] = 0.000001;
|
|
|
|
|
2009-02-10 11:12:58 -05:00
|
|
|
_addHandler(target, tweeningParameters, 'onStart', _tweenStarted);
|
|
|
|
_addHandler(target, tweeningParameters, 'onComplete', _tweenCompleted);
|
|
|
|
}
|
|
|
|
|
|
|
|
function _getTweenState(target) {
|
|
|
|
// If we were paranoid, we could keep a plist mapping targets to
|
|
|
|
// states... but we're not that paranoid.
|
|
|
|
if (!target.__ShellTweenerState)
|
|
|
|
_resetTweenState(target);
|
|
|
|
return target.__ShellTweenerState;
|
|
|
|
}
|
|
|
|
|
|
|
|
function _resetTweenState(target) {
|
|
|
|
let state = target.__ShellTweenerState;
|
|
|
|
|
|
|
|
if (state) {
|
|
|
|
if (state.destroyedId)
|
2011-02-22 09:25:48 -05:00
|
|
|
state.actor.disconnect(state.destroyedId);
|
2009-02-10 11:12:58 -05:00
|
|
|
if (state.idleCompletedId)
|
|
|
|
Mainloop.source_remove(state.idleCompletedId);
|
|
|
|
}
|
|
|
|
|
|
|
|
target.__ShellTweenerState = {};
|
|
|
|
}
|
|
|
|
|
|
|
|
function _addHandler(target, params, name, handler) {
|
|
|
|
if (params[name]) {
|
|
|
|
let oldHandler = params[name];
|
|
|
|
let oldScope = params[name + 'Scope'];
|
|
|
|
let oldParams = params[name + 'Params'];
|
|
|
|
let eventScope = oldScope ? oldScope : target;
|
|
|
|
|
|
|
|
params[name] = function () {
|
|
|
|
oldHandler.apply(eventScope, oldParams);
|
|
|
|
handler(target);
|
|
|
|
};
|
|
|
|
} else
|
|
|
|
params[name] = function () { handler(target); };
|
|
|
|
}
|
|
|
|
|
|
|
|
function _actorDestroyed(target) {
|
|
|
|
_resetTweenState(target);
|
|
|
|
Tweener.removeTweens(target);
|
|
|
|
}
|
|
|
|
|
|
|
|
function _tweenStarted(target) {
|
|
|
|
let state = _getTweenState(target);
|
|
|
|
let delegate = target._delegate;
|
|
|
|
|
|
|
|
if (!state.running && delegate && delegate.onAnimationStart)
|
|
|
|
delegate.onAnimationStart();
|
|
|
|
state.running = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
function _tweenCompleted(target) {
|
|
|
|
let state = _getTweenState(target);
|
|
|
|
|
|
|
|
if (!state.idleCompletedId)
|
|
|
|
state.idleCompletedId = Mainloop.idle_add(Lang.bind(null, _idleCompleted, target));
|
|
|
|
}
|
|
|
|
|
|
|
|
function _idleCompleted(target) {
|
|
|
|
let state = _getTweenState(target);
|
|
|
|
let delegate = target._delegate;
|
|
|
|
|
|
|
|
if (!isTweening(target)) {
|
|
|
|
_resetTweenState(target);
|
|
|
|
if (delegate && delegate.onAnimationComplete)
|
|
|
|
delegate.onAnimationComplete();
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
function getTweenCount(scope) {
|
|
|
|
return Tweener.getTweenCount(scope);
|
|
|
|
}
|
|
|
|
|
|
|
|
// imports.tweener.tweener doesn't provide this method (which exists
|
|
|
|
// in the ActionScript version) but it's easy to implement.
|
|
|
|
function isTweening(scope) {
|
|
|
|
return Tweener.getTweenCount(scope) != 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
function removeTweens(scope) {
|
|
|
|
if (Tweener.removeTweens.apply(null, arguments)) {
|
|
|
|
// If we just removed the last active tween, clean up
|
|
|
|
if (Tweener.getTweenCount(scope) == 0)
|
|
|
|
_tweenCompleted(scope);
|
|
|
|
return true;
|
|
|
|
} else
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
function pauseTweens() {
|
|
|
|
return Tweener.pauseTweens.apply(null, arguments);
|
|
|
|
}
|
|
|
|
|
|
|
|
function resumeTweens() {
|
|
|
|
return Tweener.resumeTweens.apply(null, arguments);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
function registerSpecialProperty(name, getFunction, setFunction,
|
|
|
|
parameters, preProcessFunction) {
|
|
|
|
Tweener.registerSpecialProperty(name, getFunction, setFunction,
|
2010-02-02 10:31:38 -05:00
|
|
|
parameters, preProcessFunction);
|
2009-02-10 11:12:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
function registerSpecialPropertyModifier(name, modifyFunction, getFunction) {
|
|
|
|
Tweener.registerSpecialPropertyModifier(name, modifyFunction, getFunction);
|
|
|
|
}
|
|
|
|
|
|
|
|
function registerSpecialPropertySplitter(name, splitFunction, parameters) {
|
|
|
|
Tweener.registerSpecialPropertySplitter(name, splitFunction, parameters);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-05-13 15:46:04 -04:00
|
|
|
// The 'FrameTicker' object is an object used to feed new frames to
|
2009-02-10 11:12:58 -05:00
|
|
|
// Tweener so it can update values and redraw. The default frame
|
|
|
|
// ticker for Tweener just uses a simple timeout at a fixed frame rate
|
|
|
|
// and has no idea of "catching up" by dropping frames.
|
|
|
|
//
|
|
|
|
// We substitute it with custom frame ticker here that connects
|
|
|
|
// Tweener to a Clutter.TimeLine. Now, Clutter.Timeline itself isn't a
|
|
|
|
// whole lot more sophisticated than a simple timeout at a fixed frame
|
|
|
|
// rate, but at least it knows how to drop frames. (See
|
|
|
|
// HippoAnimationManager for a more sophisticated view of continous
|
|
|
|
// time updates; even better is to pay attention to the vertical
|
|
|
|
// vblank and sync to that when possible.)
|
|
|
|
//
|
2011-11-20 12:56:27 -05:00
|
|
|
const ClutterFrameTicker = new Lang.Class({
|
|
|
|
Name: 'ClutterFrameTicker',
|
2009-02-10 11:12:58 -05:00
|
|
|
|
|
|
|
FRAME_RATE : 60,
|
|
|
|
|
|
|
|
_init : function() {
|
|
|
|
// We don't have a finite duration; tweener will tell us to stop
|
tweener: make timeline loop indefinitely
Tweener uses a clutter timeline to manage all active animations
running at a given moment. The timeline is mopped up when no
animations are going any more.
Clutter requires timelines to have a finite duration, but since
animations can happen at any moment, no fixed duration can
accomodate the shell's needs.
To combat this problem, the tweener code picks a relatively
long duration: 1000 seconds. No string of animations should take
that long, so, in theory, that should be good enough.
Unfortunately, this tactic fails, in practice, when the user
suspends their machine, or VT switches. An animation can take
much longer than 1000 seconds (~16 minutes) to complete in those
cases. When the user resumes, or VT switches back the timeline
completes immediately (since it's already late) and tweener
never notices that the timeline stops ticking.
This commit changes the tweener timeline to automatically loop
back to 0 after completing, so that despite its fixed duration
property, it effectively never stops. Since the timeline loops,
its concept of elapsed time no longer increases monotonically,
so we now ignore it and track time ourselves with
GLib.get_monotonic_time().
This partially reverts commit
35764fa09e4341e79732409c4e74c226d19f780f.
https://bugzilla.gnome.org/show_bug.cgi?id=653833
2012-02-16 13:29:46 -05:00
|
|
|
// when we need to stop, so use 1000 seconds as "infinity", and
|
|
|
|
// set the timeline to loop. Doing this means we have to track
|
|
|
|
// time ourselves, since clutter timeline's time will cycle
|
|
|
|
// instead of strictly increase.
|
2009-06-06 13:07:41 -04:00
|
|
|
this._timeline = new Clutter.Timeline({ duration: 1000*1000 });
|
tweener: make timeline loop indefinitely
Tweener uses a clutter timeline to manage all active animations
running at a given moment. The timeline is mopped up when no
animations are going any more.
Clutter requires timelines to have a finite duration, but since
animations can happen at any moment, no fixed duration can
accomodate the shell's needs.
To combat this problem, the tweener code picks a relatively
long duration: 1000 seconds. No string of animations should take
that long, so, in theory, that should be good enough.
Unfortunately, this tactic fails, in practice, when the user
suspends their machine, or VT switches. An animation can take
much longer than 1000 seconds (~16 minutes) to complete in those
cases. When the user resumes, or VT switches back the timeline
completes immediately (since it's already late) and tweener
never notices that the timeline stops ticking.
This commit changes the tweener timeline to automatically loop
back to 0 after completing, so that despite its fixed duration
property, it effectively never stops. Since the timeline loops,
its concept of elapsed time no longer increases monotonically,
so we now ignore it and track time ourselves with
GLib.get_monotonic_time().
This partially reverts commit
35764fa09e4341e79732409c4e74c226d19f780f.
https://bugzilla.gnome.org/show_bug.cgi?id=653833
2012-02-16 13:29:46 -05:00
|
|
|
this._timeline.set_loop(true);
|
2009-06-06 13:07:41 -04:00
|
|
|
this._startTime = -1;
|
tweener: make timeline loop indefinitely
Tweener uses a clutter timeline to manage all active animations
running at a given moment. The timeline is mopped up when no
animations are going any more.
Clutter requires timelines to have a finite duration, but since
animations can happen at any moment, no fixed duration can
accomodate the shell's needs.
To combat this problem, the tweener code picks a relatively
long duration: 1000 seconds. No string of animations should take
that long, so, in theory, that should be good enough.
Unfortunately, this tactic fails, in practice, when the user
suspends their machine, or VT switches. An animation can take
much longer than 1000 seconds (~16 minutes) to complete in those
cases. When the user resumes, or VT switches back the timeline
completes immediately (since it's already late) and tweener
never notices that the timeline stops ticking.
This commit changes the tweener timeline to automatically loop
back to 0 after completing, so that despite its fixed duration
property, it effectively never stops. Since the timeline loops,
its concept of elapsed time no longer increases monotonically,
so we now ignore it and track time ourselves with
GLib.get_monotonic_time().
This partially reverts commit
35764fa09e4341e79732409c4e74c226d19f780f.
https://bugzilla.gnome.org/show_bug.cgi?id=653833
2012-02-16 13:29:46 -05:00
|
|
|
this._currentTime = -1;
|
2009-02-10 11:12:58 -05:00
|
|
|
|
2009-09-01 13:27:31 -04:00
|
|
|
this._timeline.connect('new-frame', Lang.bind(this,
|
2009-02-10 11:12:58 -05:00
|
|
|
function(timeline, frame) {
|
2009-09-01 13:27:31 -04:00
|
|
|
this._onNewFrame(frame);
|
|
|
|
}));
|
2010-05-24 09:48:41 -04:00
|
|
|
|
|
|
|
let perf_log = Shell.PerfLog.get_default();
|
|
|
|
perf_log.define_event("tweener.framePrepareStart",
|
|
|
|
"Start of a new animation frame",
|
|
|
|
"");
|
|
|
|
perf_log.define_event("tweener.framePrepareDone",
|
|
|
|
"Finished preparing frame",
|
|
|
|
"");
|
2009-02-10 11:12:58 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
_onNewFrame : function(frame) {
|
|
|
|
// If there is a lot of setup to start the animation, then
|
|
|
|
// first frame number we get from clutter might be a long ways
|
|
|
|
// into the animation (or the animation might even be done).
|
2009-06-06 13:07:41 -04:00
|
|
|
// That looks bad, so we always start at the first frame of the
|
2009-02-10 11:12:58 -05:00
|
|
|
// animation then only do frame dropping from there.
|
2009-06-06 13:07:41 -04:00
|
|
|
if (this._startTime < 0)
|
tweener: make timeline loop indefinitely
Tweener uses a clutter timeline to manage all active animations
running at a given moment. The timeline is mopped up when no
animations are going any more.
Clutter requires timelines to have a finite duration, but since
animations can happen at any moment, no fixed duration can
accomodate the shell's needs.
To combat this problem, the tweener code picks a relatively
long duration: 1000 seconds. No string of animations should take
that long, so, in theory, that should be good enough.
Unfortunately, this tactic fails, in practice, when the user
suspends their machine, or VT switches. An animation can take
much longer than 1000 seconds (~16 minutes) to complete in those
cases. When the user resumes, or VT switches back the timeline
completes immediately (since it's already late) and tweener
never notices that the timeline stops ticking.
This commit changes the tweener timeline to automatically loop
back to 0 after completing, so that despite its fixed duration
property, it effectively never stops. Since the timeline loops,
its concept of elapsed time no longer increases monotonically,
so we now ignore it and track time ourselves with
GLib.get_monotonic_time().
This partially reverts commit
35764fa09e4341e79732409c4e74c226d19f780f.
https://bugzilla.gnome.org/show_bug.cgi?id=653833
2012-02-16 13:29:46 -05:00
|
|
|
this._startTime = GLib.get_monotonic_time() / 1000.0;
|
2009-02-10 11:12:58 -05:00
|
|
|
|
|
|
|
// currentTime is in milliseconds
|
2010-05-24 09:48:41 -04:00
|
|
|
let perf_log = Shell.PerfLog.get_default();
|
tweener: make timeline loop indefinitely
Tweener uses a clutter timeline to manage all active animations
running at a given moment. The timeline is mopped up when no
animations are going any more.
Clutter requires timelines to have a finite duration, but since
animations can happen at any moment, no fixed duration can
accomodate the shell's needs.
To combat this problem, the tweener code picks a relatively
long duration: 1000 seconds. No string of animations should take
that long, so, in theory, that should be good enough.
Unfortunately, this tactic fails, in practice, when the user
suspends their machine, or VT switches. An animation can take
much longer than 1000 seconds (~16 minutes) to complete in those
cases. When the user resumes, or VT switches back the timeline
completes immediately (since it's already late) and tweener
never notices that the timeline stops ticking.
This commit changes the tweener timeline to automatically loop
back to 0 after completing, so that despite its fixed duration
property, it effectively never stops. Since the timeline loops,
its concept of elapsed time no longer increases monotonically,
so we now ignore it and track time ourselves with
GLib.get_monotonic_time().
This partially reverts commit
35764fa09e4341e79732409c4e74c226d19f780f.
https://bugzilla.gnome.org/show_bug.cgi?id=653833
2012-02-16 13:29:46 -05:00
|
|
|
this._currentTime = GLib.get_monotonic_time() / 1000.0 - this._startTime;
|
2010-05-24 09:48:41 -04:00
|
|
|
perf_log.event("tweener.framePrepareStart");
|
2009-02-10 11:12:58 -05:00
|
|
|
this.emit('prepare-frame');
|
2010-05-24 09:48:41 -04:00
|
|
|
perf_log.event("tweener.framePrepareDone");
|
2009-02-10 11:12:58 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
getTime : function() {
|
tweener: make timeline loop indefinitely
Tweener uses a clutter timeline to manage all active animations
running at a given moment. The timeline is mopped up when no
animations are going any more.
Clutter requires timelines to have a finite duration, but since
animations can happen at any moment, no fixed duration can
accomodate the shell's needs.
To combat this problem, the tweener code picks a relatively
long duration: 1000 seconds. No string of animations should take
that long, so, in theory, that should be good enough.
Unfortunately, this tactic fails, in practice, when the user
suspends their machine, or VT switches. An animation can take
much longer than 1000 seconds (~16 minutes) to complete in those
cases. When the user resumes, or VT switches back the timeline
completes immediately (since it's already late) and tweener
never notices that the timeline stops ticking.
This commit changes the tweener timeline to automatically loop
back to 0 after completing, so that despite its fixed duration
property, it effectively never stops. Since the timeline loops,
its concept of elapsed time no longer increases monotonically,
so we now ignore it and track time ourselves with
GLib.get_monotonic_time().
This partially reverts commit
35764fa09e4341e79732409c4e74c226d19f780f.
https://bugzilla.gnome.org/show_bug.cgi?id=653833
2012-02-16 13:29:46 -05:00
|
|
|
return this._currentTime;
|
2009-02-10 11:12:58 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
start : function() {
|
2010-06-19 22:16:06 -04:00
|
|
|
if (St.get_slow_down_factor() > 0)
|
|
|
|
Tweener.setTimeScale(1 / St.get_slow_down_factor());
|
2009-02-10 11:12:58 -05:00
|
|
|
this._timeline.start();
|
2010-05-09 00:34:15 -04:00
|
|
|
global.begin_work();
|
2009-02-10 11:12:58 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
stop : function() {
|
|
|
|
this._timeline.stop();
|
2009-06-06 13:07:41 -04:00
|
|
|
this._startTime = -1;
|
tweener: make timeline loop indefinitely
Tweener uses a clutter timeline to manage all active animations
running at a given moment. The timeline is mopped up when no
animations are going any more.
Clutter requires timelines to have a finite duration, but since
animations can happen at any moment, no fixed duration can
accomodate the shell's needs.
To combat this problem, the tweener code picks a relatively
long duration: 1000 seconds. No string of animations should take
that long, so, in theory, that should be good enough.
Unfortunately, this tactic fails, in practice, when the user
suspends their machine, or VT switches. An animation can take
much longer than 1000 seconds (~16 minutes) to complete in those
cases. When the user resumes, or VT switches back the timeline
completes immediately (since it's already late) and tweener
never notices that the timeline stops ticking.
This commit changes the tweener timeline to automatically loop
back to 0 after completing, so that despite its fixed duration
property, it effectively never stops. Since the timeline loops,
its concept of elapsed time no longer increases monotonically,
so we now ignore it and track time ourselves with
GLib.get_monotonic_time().
This partially reverts commit
35764fa09e4341e79732409c4e74c226d19f780f.
https://bugzilla.gnome.org/show_bug.cgi?id=653833
2012-02-16 13:29:46 -05:00
|
|
|
this._currentTime = -1;
|
2010-05-09 00:34:15 -04:00
|
|
|
global.end_work();
|
2009-02-10 11:12:58 -05:00
|
|
|
}
|
2011-11-20 12:56:27 -05:00
|
|
|
});
|
2009-02-10 11:12:58 -05:00
|
|
|
|
|
|
|
Signals.addSignalMethods(ClutterFrameTicker.prototype);
|