A dream for future NLS support in the RCP framework

One of the bigger jobs we are involved in right now, is for a Nordic bank with branches in all the Nordic countries. As the application we make must be deployed in all of these countries, we will have to translate all the relevant text from labels, buttons, view titles, perspectives, menus, etc, etc.

We haven't experienced serious problems with the translations themselves... But, then again, this is an area, where we could dream of some better support from the RCP framework. Unfortunately, the support we are looking for, does not seem to be possible in the current framework.

Basically, we want the business side of the bank - who set the original requirements for the application - to provide the translations for the different languages, as they should know better than the individual developers... This in itself is not a problem and can be accomplished via some of the tools from the babel project along with fragments...

But we would also like to allow the business side to make changes in the translations in a very easy way in the running application: when they see a text they don't like, we want them to press a key-combination (ALT-CTRL is used in an older Swing based application) and then click on the item they want to change. This will then drop them into a special editor where the translations for all the supported languages are shown and can be changed. When they have made the proper change, the differences are stored back into a database, from which new fragments are generated automatically...

In order to implement anything like this, we first of all need the NLS key for the text of the item in question as well as the resource name with the translations.

But, currently, all the translations in the registry - e.g for commands and views - are resolved when the plugin.xml files are read into the RCP application... After that no trace can be found of the original NLS keys and thus it is impossible to implement anything like the above.

I have spent some time look at the code that handles the translations and I cannot find a very easy solution without making changes to too many things in the framework. Changes are needed

• in the registry reader
• in IContributionItem code for commands (for menu and toolbar items)
  
• in the current Presentation API implementations (for view names)

plus some new easy to use support for labels, buttons, sections and the like...

So, this is a wish for e4, I guess...

I'm pro-cloning - sort of

Begin at EclipseCon is hard work! To follow all the tracks I would like to, I will have to clone myself a couple of times!

At any one time there are at least 1-2 tracks with good serious talks on subjects I find interesting, there are plenty of people I would like to talk with, lots of coffee I need to drink, quite a few exhibits I would like to visit.... While I'm at it, I could use a couple of me's to relax while the others work, so I'm not to tired in the evening, when the official program is over and we all begin on the more informal networking....

Building a local Eclipse user group

If you consider starting an Eclipse user group or a an Eclipse society, then this Eclipse '08 BoF might just interest you. Building a new local Eclipse community is not exactly rocket science, but it does take some work from a few dedicated souls.

In this BoF, we will talk about how to build interest for a local community, tips for events, how to get sponsors for the events and similar essential user group stuff.

One hope is that we might be able to setup series of similar events in a region - e.g. Europe - where we can get companies to show they stuff multiple times... This makes it easier for us and likely more interesting for them as they get a bigger audience...

At the end of the meeting we should hopefully setup a mailing list or similar to help exchange ideas for events in the future as well.

Eclipse RCP Training in Copenhagen and Stockholm

As already announced on Eclipse.org, we will now start another round on Eclipse RCP Training all over the world.

I'm happy to say that The RCP Company will also participate this time with training in Copenhagen (May 19-22) and in Stockholm (June 2-5).

The training includes all the essential knowledge to properly develop an Eclipse RCP based application based on Eclipse 3.3 (Europa). The subjects include:

• Introduction to RCP
• RCP Application lifecycle
• Internal structure
• Workbench
• Publishing
• Plug-ins
• Contributing to Workbench
• Introduction to SWT
• Introduction to JFace
• Views
• Commands and Actions
• Editors
• Wizards
• Help
• New and Noteworthy Features of Ganymede (also known as Eclipse 3.4)
  

You can register online - via the links above - or directly with The RCP Company. The training is offered for the special event promotional price of €1200. There is a 10% discount if you register before March 31, and an additional 5% discount if you register 3 or more employees from your company.

Eclipse 3.4M2 Released

Eclipse 3.4M2 has been released. The Microsoft Windows edition is available for download from eclipse.org. Same goes for RCP SDK.

As usual you can also find information about the major change in New and Noteworthy.

As we develop as lot of stuff based on RCP and therefore use the PDE extensively, we really like the new plug-in spy. We hope the next releases will see more handy usability enhancements like this. The new editor template support - used for the new SWT expansions - are real time saves too. Making a new template is not all that easy though... maybe something can be done about that?

We look forward to see if M3 is going to bring just as many new exiting features...

Some Differences between IDEs and RCP Applications

One feature of the Eclipse IDE, that most developers seems to like, is the use of perspectives to organize the functionality of the IDE. Perspectives enable you to layout the exact views that is relevant for a specific function or use case. A lot of functionality of the Eclipse platform is used to manage perspectives:

• You can open any perspective in any workbench window.
• You can open any view in any perspective.
• All editors can be shown in all perspectives.
• ...just to name a few features...
  

Where this flexibility is good in an IDE, this is not so in many RCP applications. Here you want a lot more control of the perspectives and the parts that are shown in these perspectives.

The reason for the difference is relatively simple: whereas most developers want to be able to customize their workplace to their specific needs, many enterprises don't want the same freedom for their other office personnel.

Some examples:

• Many RCP applications have multiple workbench windows each with a specific function. Each window might have a number of perspectives, but you don't want to be able to open all perspectives in all windows, only those that are relevant for the specific function of the window. This is not possible with the current perspective chooser - actually it is not even possible to avoid the "open perspective" button or to limit the set of perspectives that are offered in the menu.
• The different perspectives in an RCP application often are much more specialized than in an IDE. E.g. you might have perspectives for contacts, another for mails and yet another for tasks. But there are no way to limit which editors that can be shown in different perspectives. This means the current e-mail messages are shown side-by-side with the open appointments (assuming they both are implemented as editors, which is the "natural" choice). Once an editor has been opened in one perspective, it will be present in all perspectives with an editor area. It might not be too bad for e-mails and appointments, but think of editors with CRM information for different customers and other business specific data...
  
• Again because perspectives in RCP applications are more specific than in an IDE, you also want to limit which views that can be used in different perspectives. But if you want to allow the users to layout the start page (the first perspective), then you cannot limit which views that can be used...

Of cause, all of this can be solved with some custom versions of the relevant RCP actions, but should that really be necessary for all RCP development? Why not make this functionality an integral part of the RCP platform so it is done right and at the same time lower the entry for RCP application development?

Just my input for the upcoming "RCP Experience Workshop" symposium at the Eclipse Summit Europe 2007...

eclipse.dk has been launched

It has taken us some time, but now it is here: eclipse.dk.

Eclipse.dk was created in Marts 2007 as a meeting place for everyone interested in the Eclipse platform.

The purpose of Eclipse.dk is as follows:

1. To promote the knowledge of Eclipse in Denmark.
2. To create networks amongst danish Eclipse-users and developers.
3. To build knowledge on Eclipse in Denmark, especially
   1. In danish institutes of higher education.
   2. Between danish companies developing applications based on Eclipse.
4. Create and maintain a web site on Eclipse for danish users – eclipse.dk.
5. Strengthen the relations between danish and international Eclipse-users and organizations.

The eclipse.dk society has members representing not only vendors of Eclipse-based products and services, but also users of the platform and representatives from institutions of higher education.

On 31. August, Eclipse.dk will have its first major arrangement with a focus on Eclipse 3.3.

To join the eclipse.dk society, use this page.

Please note that the web site is in Danish (almost only).

And the great release wheel starts another turn

Another turn of the great release wheel has just ended successfully with the release of Eclipse 3.3 (Also known as Europa)... and the next turn starts immediately (to be named Ganymede)

The first mile stone, Eclipse 3.4M1, has just been released and it already has several new noteworthy items - see Eclipse 3.4 M1 - New and Noteworthy. My personal favorite is the "Extract Class refactoring", which will extract a number of member variables from an existing class into a new class. It forms a very good basis when an internal 1-to-1 relationship should be changed into a 1-to-n relationship.

If you want to know what is planned for Eclipse 3.4, you can look at the plan for Ganymede (alternatively here) and some of the sub-plans: Team, Text, JDT Core, JDT Text and JDT UI, and others... if you can find them yet. Note that these plans are not expected to become final before late August.

If you want to download Eclipse 3.4M1, use this link - with the new download structure of Eclipse 3.3 it can be a little difficult to find the download pages for specific releases.