Skip to main content

Can you remove dependency on swing timer?

1 reply [Last post]
Joined: 2006-05-22

I'm using the timing framework for some animated effects in an eclipse RCP application. I'd prefer to not have any dependency on Swing or the AWT event thread. I noticed that the new TimingSource API was added in 0.55. It is a step in the right direction for me but not perfect.

In the animator constructor the AWT event thread is still started and a default swing timer is created.

Can you only start the event thread if a swing timer is created instead of in the contructor of the animator? For example by moving the Toolkit call into the swing timer constructor?

Also can you restructure the code so that the swing timer isn't created until it is needed? For instance you can add a getTimer() method that the code uses to access the Timer (instead of a direct access to the timer variable) and have that method create the swing timer if it has not yet been created.
That is just one possible solution, I'm sure there are others. Perhaps you can inject the default timer if none is set?

Another longer term request would be to repackage the release so that the triggers related to mouse events and focus events are released in a separate jar. That way the core animation release is independent of the underlying UI technology. There could be a swing add on jar and an SWT add on jar.

Thanks for your consideration!

- Frank

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-08-07

Hi Frank,

It should be possible to create the Swing timer lazily, as you suggest. It's just a matter of getting to it, but it shouldn't be that tough. I'll put it on my [event] queue...

I'll have to think more about the Triggers stuff. The eventual goal here is to fold some amount of this stuff, or something very much like it, into the core JDK, to make animations using built-in JDK facilities much easier in general. From that perspective, all of this stuff will be available from the platform, so the fact that a Trigger has any relationship with built-in classes becomes less relevant (I think).

I can try to think about separating it at least in this standalone library case. The one concern I have (apart from the usual "another thing to do" issue) is that I want the API to be as simple as possible. I would rather group the classes closer together than start breaking them into separate libraries. I frankly think that Triggers and PropertySetters are probably more core/critical classes than most of the ones in the current library; the fact that they're in sub-packages already feels weird to me. It's more of a historical artifact, having been developed later than the core package, than a true reflection of utility. Any changes I made to the structure of things, like the one you mention for Triggers, would need to avoid making these core facilities seem like optional extensions.