Animations are an integral part of most modern UIs, including many “web 2.0″-applications and websites. (Just watch carefully when opening google.com.) They have become so common that we even subconsciously miss them if they aren’t there. The transition between two states of an UI should never be sudden, but gradually (albeit quickly), as we are used from real life. If done right, this increases usability without attracting too much attention or slow down the user. Ideally one isn’t even aware of the effect, it only feels more organic and natural.

Therefore we now integrated the core functionality needed for such animations into RAP. Since the existing client-implementation of RAP was not written with such a feature in mind, it was considerable effort to do this without changing much of the existing code. And for the same reason, there are currently some limitations on what we can do with this feature. However the groundwork is done, and we hope to expand on that in the future.

Just like with gradients and rounded borders before, you can expect the number of supported widgets and effects to grow. You should keep in mind though, that this feature is meant only for subtle animations that seamlessly integrate into the UI. We can and will not turn RAP into some kind of multimedia powerhouse where everything is moving all the time.

For now, “Button”, “Menu”, “ToolTip” and “Shell-DisplayOverlay” each have one effect that can be enabled. This is done using RAPs CSS-theming, not Java, as this kind of animations are mainly eye-candy and don’t add any functionality. The syntax for this is based on a small and easy-to-use subset of the CSS3 working draft for animations. For example:

Button[PUSH] {
  animation: hoverIn 350ms ease, hoverOut 600ms ease-in;
}

This generates a faded hover-effect for buttons.

Animations work on all browser supported by RAP, but might not run smoothly on very old machines. They will be part of the upcoming 1.3M7 build. To see what we can do for now, check out the new “Theming”-Page in our examples-demo.

Tags: eclipse rap, new and noteworthy, rap, theming

Last week I introduced you to the idea of a RAP protocol (bug 311355). This week I want to provide you with further information about how such a protocol can work. First of all we need to take a closer look on the current situation. RAP is divided into two parts. On the server side runs OSGi, RWT-Server and the application bundles. On the client side runs the RWT-client (JavaScript) to render the UI in a browser. The cool thing about this is that we can provide the SWT API on the server side to make single sourcing possible. For this reason we need to keep both sides, server and client, in a consistent state.

RAP already reached this consistent state with a fast and reliable solution. But the solution has one drawback. It couples the client and the server to each other. Currently the server sends JavaScript to the client. This JavaScript will be evaluated on the client side. With a protocol we need no JavaScript within a message. Therefore no evaluation is needed to bring the client in a consistent state. This makes the debugging of messages much easier. Another benefit of the protocol is that we don’t need to generate valid script code on the server side anymore.

To realize the protocol a well formed message will be needed. To create such a message we need to abstract the described situation. The described RAP scenario is nothing else than synchronizing widget trees. Take a look at the picture above to understand what I mean with “synchronizing widget trees”.

But what should a message provide to keep two widget trees in a synchronous state? To answer this question I already analyzed the JavaScript responses from RAP. The result is that a message should be able to hold three different kinds of information:

• Meta: Every message needs meta information which describe the current request/response. For RAP this message part can hold information about the current request count or the settingstore.
• Device: As you probably know, RAP is multi user aware. Therefor every user gets a new instance of Display. The display marks the root node of every widget tree. So, the display is always the same while a user session exists. As a result of this, display information are needed on every request/response. With display information I mean information e.g. about the focused control or mouse coordinates.
• Widgets: With widgets I mean information that are widget relevant.

I think the most interesting of these three message parts is the widgets part. The whole synchronization process should be modeled by this part. To do this, the widgets part must be able to represent seven different tasks:

• Construction: When a widget is created on the server side it should be created on the client too.
• Destruction: When a widget is going to be disposed on the server it should be disposed on the client too.
• Synchronization: Ever user action has a status change as a result. This changed status need to be sent to the server. On the other side, server widget status changes should also be sent to the client.
• Eventlistener: With RAP we live in a distributed environment. As a result of this every event on a widget provokes a request to the server. Currently only events of interest will be sent to the server to keep the count of requests as minimal as possible. To perceive this the server needs to inform the client widget if it should send requests for some kind of event.
• Events: When an event needs to be send to the server, the event order matters. E.g. if an widget has two listeners for mouse and selection events it’s important to send the correct event order to execute the correct server code. In the example the right order is: mouse-down, selection and finally mouse-up.
• Methods: Sometimes it’s necessary that the server executes a method on a client widget. Widgets are just objects on the client side.
• Scripting: I think a protocol messages should be able to contain native code, e.g. JavaScript code. This will speed up a migration phase because hybrids are possible. With a hybrid I mean a RAP client which listens to protocol messages but also allows to evaluate JavaScript.

I would like to know what do you think about the described message content. I think the described content should cover a whole synchronization scenario. Maybe you have some ideas about speed up things or make them more clearer? I think the next step on the way to the protocol is to model an example message and to choose the messaging format. I will keep you up to date about the progress.

Tags: eclipse rap, protocol, rap

Tags: eclipse rap, protocol, rap

Finally the voting process for this years Google Summer of Code is over and they announced the accepted students. I’m really happy that so many interesting proposals got trough and really looking forward to see the outcome of all the student projects.

Here is the full list of the proposals that got accepted for 2010.
Improve Eclipse Git integration
Student: Dariusz Luksza
Mentor(s): Matthias Sohn

WAR deployment for RAP/Equinox based applications
Student: Holger Staudacher
Mentor(s): Ruediger Herrmann

Theme editor for RAP
Student: Benjamin Muskalla (IRC: benny`work)
Mentor(s): Ruediger Herrmann

Rich Editor For Wiki Markup
Student: Harshana Eranga Martin
Mentor(s): David Green

index based model compare match engine
Student: Stefan Leopold
Mentor(s): Cedric Brun

Restlet integration with Equinox
Student: Rajeev Sampath
Mentor(s): Bryan Hunt

C++ editor enhancements
Student: Tomasz Wesolowski
Mentor(s): Alena Laskavaia

DNS-SD based wide-area ECF discovery provider
Student: Markus Alexander Kuppe (IRC: lemmy)
Mentor(s): Scott Lewis

Hudson Integration for Mylyn
Student: Markus Knittig
Mentor(s): Steffen Pingel

Google Wave ECF provider
Student: Sebastian Schmidt (IRC: sebs)
Mentor(s): Mustafa Isik

Integrate GMF runtime with Mylyn task focused UI
Student: Yongming Luo
Mentor(s): Mariot Chauvin

Congratulations to all the students and a big kudos to the organizers and mentors for their choice. As every year, it is pretty difficult to dismiss so many other good proposals but there were only 11 slots available this year for Eclipse. Looking forward to a great summer!

Tags: ecf, eclipse rap, egit, emf, equinox, gmf, google summer of code, hudson, mylyn, restlet, wave

This year’s Summer of Code application deadline has passed. I want to take the chance and introduce you to my planned project. I think the results will be a great benefit for the community. So, what does RAP/Equinox WAR products mean?

When searching the RAP newsgroup for “WAR deployment” 210 threads appear. The reason for this is that many developers have problems deploying a RAP application. These problems exist because RAP products build on top of Server-Side Equinox. Equinox has special requirements for the deployable archive. To making things easier for beginners and to simplify the deployment process a good approach and tooling is needed. The goal of this GSoC 2010 project is to provide this approach and tooling.

The planned approach is called WAR products. This should be a similar concept as the well known Eclipse product approach to make RCP developers feel at home. The tooling for the WAR products should also be very similar to the existing product tooling. I already talked to Chris Aniszczyk about this project and we both agree not to create a whole new tooling for the WAR products. I think it would be the best to make the existing tooling plugable to reuse most of the components for the WAR product tooling.

How does this fit in the RAP project? Well, I think RAP is probably the biggest consumer of the Server-Side Equinox technology. With this fact it’s in the interest of the RAP community to have a good concept and tooling for users. While doing this project as part of RAP we can easily get feedback from the community. Rüdiger Herrmann, co-lead of the RAP project, already agreed to mentor this GSoC project.

So, wouldn’t it be great to have such a tooling for WAR products? With this kind of tooling we can handle the deployment of Server-Side Equinox based applications the same way as normal RCP applications. The only problem at this point is the project needs to be accepted for GSoC 2010. So, my call to all accepted mentors: Please give the project a good vote. The full project’s proposal can be found at the Eclipse Wiki (Maybe you have some good ideas you want to share?). Thanks in advance for all votes.

Tags: eclipse rap, equinox, rap, soc

Tags: eclipse, eclipse rap, eclipsecon, emf, helios, new and noteworthy, rap, Single Sourcing, talks

Would you like to get an overview of the best features in RAP in 5 minutes?

We just stumbled across this video on YouTube that shows what a modern RAP application can look like (including some new 1.3 features like DnD).

It is stunning that this video presents our vision with RAP much better than we have done it by ourselves so far … and it is always encouraging to see that others are using RAP at this level to create applications that are both technically and visually convincing.

Tags: eclipse rap, rap, screencasts

I’ve spend the last few days adjusting the Ridget layer in Riena, to make it work with Eclipse RAP and Eclipse RCP. We call this process “single-sourcing” (EclipseCon tutorial).

Ridgets wrap around standard SWT / RWT controls to provide additional functionality and a better API. One example that you can see below: Ridgets have “markers”, which tag a control as mandatory, wrong or read-only and change the control’s behavior accordingly.

It’s worth mentioning that all three screenshots run from the same code. The only difference is the target environment used (RAP or RCP).

Ridgets styled with RAP's "business" theme

Ridgets styled with RAP's "classic" theme

Ridgets in a regular RCP application

Once this work is completed the Ridget API will be usable for RAP applications as well.

To stay informed about this effort:

• CC yourself to Bug 302893, and
• come to our EclipseCon talk “Riena 2.0 - New & Noteworthy“

Tags: eclipse rap, eclipsecon, riena

We recently had a workshop on redView with the developers of the project, probably many of you know ekke. We wanted to evaluate it and gain a better understanding if we could use it in the context of a project in the insurance space.

redView looks pretty promising, and although personally I am not a big fan of modeling and code generation there might be a sweet spot for redView for people who have tons of forms to fill in data.

One really nice thing about redView is that they created a detailled install instruction (a yoxos profile could probably help here), and a bunch of demos to get started.

http://redview.wordpress.com/howto/examples
http://redview.wordpress.com/howto/installation/
http://sourceforge.net/projects/redview/files/

P.S: The obligatory question about single sourcing redView has been discussed, and as redView is EMF + Riena it looks feasible to get redViews working in RAP. Even the visual form designer imposes no hurdles that could not be overcome (plain SWT, no GEF).

Tags: eclipse rap, modeling, rcp, riena

The RAP team just announced the availability of RAP 1.3 M5!

If you’re interested in single-sourcing Eclipse-based applications, please give it a try.

In the 1.3 M5 release, the RAP team added more SWT API to make single sourcing existing applications easier:

• Composite#layout( Control[], int )
• MouseEvent#stateMask
• Widget#reskin( int ) and SWT.Skin event
• ImageData
• ImageLoader
• ImageLoaderEvent

The team also added IApplication support which simply translates into one less extension point you have to use to create a RAP application. In the past, RAP had its own entrypoint extension point which performed a similar role to what the application support does in Equinox already.  This should make RAP even easier for RCP developers to get into.

RAP is also taking advantage of the Equinox extension registry is able to handle multiple locales.

So please give RAP a try if you’re interested in bringing your RCP application to the web.

Tags: eclipse rap