When I check TimingFramework project recently, it seems that it is changing (some classes don't exist any more etc.), does it?
What happened to Cycle and Envelope? I liked how they encapsulated common timer settings so I could share them across multiple TimingControllers (or Animators as they are now known). Now I have to set each individual property which seems somewhat of a pain to me.
I liked the Cycle/Envelope classes too because they encapsulated ideas and data that I think make the framework (and core ideas behind animation) easy to understand. However, some user feedback indicated that the extra overhead of simply having more classes to understand wasn't worth the minimal data separation they gave. There's always a tradeoff, I think the current decision (which eliminated two classes) was worth it.
Diod pointed out the home page, where I tried to document the major changes. I also beefed up the javadocs quite a bit (some sample code, etc.), so hopefully there's enough information in there for the intrepid read.
Note that the changes were not all that huge in the end: Cycle/Envelope went away, but those same properties now exist in Animator. TimingController became Animator. timingEvent() now sends only a fraction. KeySplines became an array of Interpolator's (which can be splines, or something more custom). PropertyRange/ObjectModifier merged into the new PropertySetter (easier to create and use). I updated all of the demos (although I'm having a horrid time getting CVS to update the racetrack demos) and it didn't take that many changes.
Chet recently made an upgrade to the project (October 27) that changed a lot of things within the API.
For instance KeySplines has been replaced with a new Interpolator interface. TimingController has been renamed Animator, etc..
You can review all changes made at the bottom of this page (search for "Change Log").. https://timingframework.dev.java.net/
For a project that claims to be [b]the[/b] framework for Swing animations, it's too unstable for too long time. The first java.net article was in February 2005 and it's still at 0.5? No offense, but how about a stable API and a reliable release schedule? This is the only reason i don't use it in Substance animations.
Why does it seem like every question or request from is you so antagonistic? You could ask, you could send feedback, you could actually interact with us, or you could just continue in the same tiresome vein and have a much better chance of simply being ignored.
Sorry, just had to get that off my chest.
The framework has never claimed to be [b]the[/b] framework for Swing animations, but rather [b]a[/b] framework for animating things in general. Hopefully it's far better and more useful than the stuff that's built-in, regardless of what version it actually happens to be.
I arbitrarily picked ".5" last week when I realized it was time to start assigning some version to the changes; previous changes had no version at all. I don't want to take it to 1.0 yet because I'm still playing with the API (and will continue to do so until I feel the kinks are all worked out).
In the meantime, I hope it's usable in whatever form you find it. The main thing to note is that the API may change (hopefully to smaller and smaller degrees as time goes on). But if you like it in its current form, go for it, use it, tell me about problems that you have with it.
The idea behind the project is to continue building in functionality and making the API as simple and useful as possible, with an eye toward hopefully incorporating the parts that make sense into the core APIs. It would be silly for me to lock down the API right now if I think it's not yet done. It would also be silly for me to make no changes until I'm ready to lock things down. I thinkn 9correct me if I'm wrong) that the utility of projects like this is to get real people using it and feeding back input to improve the library. For example, many of the changes I just posted come from feedback from people trying to use it in different situations. There are other features that I have yet to implement that also come from real use cases.
- Sorry the API isn't final yet (but not really)
- Hope the library is useful anyway (some people have found it so)
- Send in feedback on what you like, what you don't, and what you'd like to see
Message was edited by: chet
Sorry for sounding like that. Here is how i see it.
The project has been more than two years in development, and still no stable API / no stable release. Specifically for Substance, currently i have over 180 calls to the animation layer in various UI delegates / listeners. You wouldn't really expect people to be happy to change all those places every few months, right? Perhaps it's OK for a small demo with 2-3 calls, but not for a serious project that uses a lot of animations.
Another thing concerns the implicit messages sent in various forums / threads / blogs. For example,  assumes that the animations in SwingX painter layer will be done using the TimingFramework. There will be a whole chapter in the Filthy Rich clients book  about it. Romain's presentations use it for the various animation effects. [b]Which is all perfectly OK but[/b]:
Once again it is not stable (not the implementation, but the API itself), so how do you expect people to start [b]seriously[/b] using it (not playing / demoing) in the its current state? Is this the reason that it's not used in Mustang WindowsLAF to emulate Vista animations?
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.