| Re: [e4-dev] Re: Trident (was: animations) |
Timeline fadeInShellTimeline = new Timeline(shell);It uses the Trident capabilities along with the SWT Shell.setAlpha API to fade in the window previously displayed with
fadeInShellTimeline.addPropertyToInterpolate("alpha", 0, 255);
fadeInShellTimeline.setDuration(500);
fadeInShellTimeline.play();
shell.setAlpha(0);My first thought was to provide a Shell extension class that has this built in (by overriding the dispose and open methods). Unfortunately, the Shell class can only be extended in the same package - unlike Swing that lets you extend the top-level window classes. While this seems logical for other tasks, the fade-in / fade-outs of SWT windows need to be explicit. You can find the helper method that fades out an SWT shell (and the disposes it once it reached the alpha of 0) in GraniteUtils.fadeOutAndDispose method:
shell.open();
Hi Kirill,
I did not mean RCP specific. I guess adding OSGi manifests to Trident would be a good start. I am not sure yet, what I would like to add to the contacts demo. Some of my ideas would be:
- Smooth appearing and fading of things like dialogs, views
- Animated Splash Screen
Best wishes,
Kai
From: e4-dev-bounces@xxxxxxxxxxx
[mailto:e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Kirill Grouchnikov
Sent: Samstag, 5. Dezember 2009 06:19
To: E4 Project developer mailing list
Subject: Re: [e4-dev] Re: Trident (was: animations)
Hi
Kai
I am not sure what do you mean by an RCP specific version of Trident. If you
only need the OSGi manifest entries, then let me know what to add. If UI
toolkit support needs to be provided as an OSGi service instead of the current
lookup mechanism (via property files), i will have to defer this to the OSGi
people on this list.
Otherwise, you can just take the latest Trident 1.2dev, take a look at the
bundled samples and the Granite demo, and start playing with it.
Thanks
Kirill
From: "Toedter, Kai"
<kai.toedter@xxxxxxxxxxx>
To: E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Sent: Thu, December 3, 2009 11:36:44 PM
Subject: RE: [e4-dev] Re: Trident (was: animations)
@Kirill @Boris,
I am excited to see this topic going on. As soon as a trident version is available for e4 RCP apps I would volunteer to add some animations to my e4 contacts demo. When doing that I could provide Kirill with concrete feedback.
Best regards,
Kai
From: e4-dev-bounces@xxxxxxxxxxx
[mailto:e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Kirill Grouchnikov
Sent: Freitag, 4. Dezember 2009 06:02
To: E4 Project developer mailing list
Subject: Re: [e4-dev] Re: Trident (was: animations)
Hi
Boris
Thanks for the comments. It looks like we are talking about minor issues - how
Trident is implemented. That's a lot of valid points that we can discuss in
this list or in the project mailing lists.
Looking beyond the technical details of singletons, properties files and the
specifics of constructing timelines, i would like to have some people looking
at the existing samples shipped with Trident and Granite to see how it feels to
a person not deeply familiar with the library. Trident has a few simple
examples - such as animating the FG color of a radio button on mouse rollover,
as well as more complex application such as Granite.
Along the way i have run into a number of limitations in SWT as far as the
animations go. For example, i wasn't able to animate the FG color of a button.
Not sure if this is because of SWT or the native APIs. Another example is in
JFace - wanted to do animations on table rollovers / selections, but seems that
the color provider infrastructure is not dynamic. Once the cell is configured
to use the specific BG color, it cannot be dynamically changed - or maybe i'm
missing something.
What i'm saying is that SWT / JFace might need internal changes no matter which
animation library (third-party or written from scratch) is chosen. As you have
said, it would be great to have a few demos trying Trident and seeing how the
APIs feel, and what limitations in Trident / SWT are found - to get the ball
rolling.
Thanks
Kirill
From: Boris Bokowski
<Boris_Bokowski@xxxxxxxxxx>
To: E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Sent: Thu, December 3, 2009 2:29:06 PM
Subject: Re: [e4-dev] Re: Trident (was: animations)
Hi Kirill,
> * Support for each UI toolkit is less
than 10KB in the final jar. So
> the size shouldn't be a problem.
> * Trident gracefully degrades when the specific UI classes are not
> in the path (specifically relevant for SWT and Android). So you
> shouldn't be getting any runtime exception on missing classes.
Sounds good but I'd still prefer to only have
the SWT support configured. Running less code is a good thing unless you really
need it. For example, we've seen cases where just referencing Swing/AWT classes
ends up starting the AWT UI thread, which I'd like to avoid until you are
actually using Swing/AWT for real. (This is just an example - I'm not saying
that this happens when you use Trident, I haven't checked and it probably
doesn't.)
> If given that you still want to strip away these classes, i can
> tweak the build.xml to produce:
>
> * The full runtime jar
> * The core jar without any UI specific classes
> * "Plugin" jars - one for each UI toolkit
Sounds good (but in which jar would the
trident-plugin.properties file be?)
> About Timeline / SWTTimeline. I wouldn't necessarily want to see an
> over abundance of UI-specific extensions of Timeline classes. If you
> want to remove the declarative mechanism for some reason, you can
> call TridentConfig.getInstance().addUIToolkitHandler somewhere in e4
> / app code. Trident will figure out if the specific timeline needs
> special UI support based on the main object of that timeline.
To explain myself... I have a built-in
aversion against using the Singleton pattern :-), and don't see why it would be
needed in this case if you allowed subclasses like SWTTimeline. But maybe I am
missing something.
> About OSGi support - let me know what entries are required in
> manifest and i will add them in 1.2dev branch.
Thanks! Will send a separate email with
details, hopefully tomorrow.
Boris