Here are three recent developments from Eclipse Riena, that you may otherwise have missed:

• Version 3.0 announced – we have updated the development plan, skipping the 2.1 release and shooting straight for a 3.0 release next June (Eclipse Indigo). While we strive to keep the bulk of the APIs unchanged, this move will grant us the flexibility to carefully introduce changes needed to support Eclipse RAP.

You can read the full announcement here.

• Riena goes to the Web – We are excited about having all of Riena run on Eclipse RAP and are stepping up the effort.

In the last two weeks we have ported and committed the Riena Navigation to RAP. Thanks to recent improvements in RAP this was a breeze! We also have an automated build for this second platform. Lastly, we have worked to eliminate all compile errors when building against RAP. This should make further development more straightforward.

If you want to follow the effort add yourself on Bug 302893 and read the ‘Riena on RAP‘ page on the wiki.

• Riena at Eclipse Summit Europe - Riena committers are participating at the ESE, November 2 – 4 in Ludwigsburg. We have proposed following talks:

• Riena on RAP (Running Riena in the Web)
• Riena on e4 aka “RCP 2.0″
• SWT on Qt
• Tutorial: dynamic UI – from domain model to RCP app (Riena+Modelling+RedView)

If you are interested in any of these topics: please follow the link and leave a short comment. This will help the organizers decide which talks to approve. Thanks!

Tags: eclipse summit, events, rap, riena, talks

Here are the slides from my “Eclipse RAP – What’s new in Helios?“ talk, which I gave at the Bay Area Demo Camp in June. They capture the most interesting novelties of the RAP 1.3 release. You can find even more details in the full release notes.

I want to thank Oracle and AvantSoft for hosting and organizing the event.

If you are interested in future Eclipse events in the Bay Area, please take a moment to join the Bay Area Eclipse User Group on Meetup.com

Tags: democamp, events, rap, slides, talks

Here is a question that I got on a post about detached views:

“How can I detect that a View has been detached from the main window? I would like to adjust the view’s behavior in that case.”

There is no API to obtain that information directly. However it is possible to do this with a few tricks:

1. detached views have an empty window title (i.e. shell.getText().length() == 0)
2. when a view is detached resize events are fired

Armed with that knowledge we can detect that a view is detached / reattached. The snippet below shows how (tested on windows).

PS: Our eclipse support helps developers use their time efficiently by providing prompt answers to questions like this one.

Tags: detached views, eclipse ui, tips

Here’s a nice addition to Riena’s TableRidget: you can now mark a table-row as incorrect.

This is done with an RowErrorMessageMarker. When hovering over the marked row, the corresponding error message will be shown in a tooltip.

IMarker marker = new RowErrorMessageMarker("An error message...", zorro);
tableRidget.addMarker(marker);
// to remove:
tableRidget.removeMarker(marker);

Full snippet here. This is shipping with the upcoming Riena 2.0 M6.

Tags: eclipse ui, riena, swt, tips

“Can you help me use shared libraries with Eclipse CDT, managed make and cygwin?“, I was asked yesterday. Read on for a list of common pitfalls and detailed instructions.

The instructions are based on the latest CDT release (Galileo) and cygwin (make 3.81, gcc 3.4.4). They are applicable to CDT’s managed make projects (that means CDT generates a makefile to build project).

The Pitfalls

It turns out that using a shared library on Windows is not as straight forward as you think. There are several pitfalls waiting for the unaware to fall into:

1. Recent versions of cygwin’s make insist on cygwin-style paths instead of windows paths (/cygdrive/c/foo instead of c:\foo). CDT is not picky about this and will generate an incorrect makefile, if you use workspace relative paths:

make all
example.d:1: *** multiple target patterns.  Stop.

The solution is to use absolute cygwin paths, such as: /cygdrive/c/workspace/mymath

2. The compiler and linker will not find the header files / library unless you set the appropriate parameters. The compiler needs an include path (-I). The linker needs the library name (-l) and library search path (-L). These settings are scattered in two places in the project properties. Their location is not obvious for a first-time user (details below).

3. When launching, Windows will not find the shared library (.dll) and greet you with the error pictured below. Unix users might try to set the LD_LIBRARY_PATH, which has no effect on Windows. The solution is to append the directory containing the .dll to the PATH (MSDN Article). Restart Eclipse for the changed PATH to take effect.

The remainder of the post walks you through the process of creating and using a simple shared library with cygwin and CDT.

Creating a Shared Library with CDT

Follow these instructions to create a shared library project with CDT.

1. File > New > Project > C Project > Next. Project name: mymath. Ensure “use default location” is checked. Note the location: c:\workspace\mymath — we’ll need it later. Project type: Shared Library; Empty Project. Hit Finish.

2. Create a header file (mymath.h) and the corresponding implementation (mymath.c). The example below provides a trivial function that multiplies two integers:

3. Afterwards save and hit Ctrl+B (or Project > Build All) to build the library. If cygwin is on your path, you should see a “Release” folder in your project containing the file “mymath.dll”.

4. For windows to find the shared library, you need to add the directory containing the .dll to your path. On Vista this can be done via: Control Panel > User Accounts > User Accounts > Change my environment variables.

5. Exit and restart Eclipse after changing the PATH. Otherwise the changes will not be picked up.

Using a Shared Library with CDT

Follow these instructions to use a shared library in a “managed make” CDT project.

1. File > New > Project > C Project > Next. Project name: example. Project type: Executable; Empty Project. Hit Finish.

2. In that project create a file named example.c with the following content:

3. Save and hit Ctrl+B to build the project. The second line will have an error: “mymath.h: No such file or directory”. We now have to adjust the compiler and linker settings so that the mymath.h / mymath.dll files are found during the build.

4. Select the “example” folder in the Project Explorer. Select “Project > Properties” from the menu. A dialog comes up. In the tree on the left open: “C/C++ General > Paths and Symbols”. In the “Languages” list, pick “GNU C”. Then hit “Add”. Enter the cygwin-style path to the “mymath” project: /cygdrive/c/workspace/mymath

Caution: When entering the path, don’t use the “Workspace” or “File system” buttons because the resulting path will not be compatible with cygwin’s make.

5. In the same dialog select: C/C++ Build > Settings in the tree on the left. In the “Tool Settings” tab find: “Cygwin C Linker > Libraries”. Hit the “+” icon in the “Libraries” section and add the name of the library: mymath

Caution: if your shared library starts with lib, omit the ‘lib’ prefix (i.e. libfoo becomes foo)

Hit the “+” icon in the “Library search path” section and add the path to the folder containing the shared library: /cygdrive/c/workspace/mymath/Debug

Hit OK.

6. You will be asked to rebuild the project. Answer “Yes”, but for some reason this will not rebuild your project. Hit Ctrl+B to rebuild. The error will go away.

Note: ignore the “unresolved inclusion” warning. It seems that CDT has trouble resolving cygwin-style paths. The generated make-file however will work as expected.

7. Select “example” in the Project Explorer. Right-click > Run As > Local C/C++ Application. At this point you see the result of the multiplication on the console. That means that the shared library was found and used successfully:

Kind regards,
Elias.

Tags: cdt, cygwin, tips, windows

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).

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: eclipsecon, rap, riena

Let’s assume for the moment, that in an alternate reality I can travel back in time to 2008. Once there, I meet a bright bunch of people that work on something called e5 (executive summary.odp). My summary:

“the runtime platform that is simple and appealing to _____ application developers”

Here’s what I would say to them:

e5 should take risks

When I became interested in Eclipse it was cool and disruptive. A real game changer. It is now the established tooling platform and understandably locked into perpetual refinement mode (Entrenched Player’s Dilemma). Make sure that e5 is equally game changing. Otherwise we are setting ourselves up to be disrupted.

At the EclipseCon 2008 we committed a “strategic sin”. We agreed that e4 would be compatible with 3.x. This limited the potential for e4 by forcing it to be something that is “in the box” vs. “outside the box”.

(taken from Death by risk-aversion by Kathy Sierra)

For e5 to be successful it needs to take risks. I don’t think that we need a better tooling platform. We already have a very good one with 3.x. And it’s still improving and not going away. Instead we need a runtime that provides something unique and remarkable. It must kick-ass in a new way.

e5 needs a driver

If you try to be everything to everybody, you will at best be mediocre at everything. e5 should be laser focused on being the best runtime for ___________ developers.

People tend to avoid specialization. It is perceived as a risk. However, if you ask a marketing person he / she will tell you that specialization is good. It’s your way to get noticed. It’s your foot in the door. You build a niche, become unbeatable and expand. Eclipse 3.x first became the tooling platform of choice, then client platform of choice for Java devs, then the modeling technology of choice for Java devs.

Unfortunately e4 lacks a driver that would help it specialize and focus. A driver, like the JDT was for the Platform. As far as I know, there is no major product build on top of e4. I believe that the current e4 (Feb 2010) is not yet appealing enough for web development or client development. It will not lure web-side Java developers away from Spring / J2EE / GWT. Or client-side Java developers away from RCP. Or Javascript folks away from jQuery / Prototype / Dojo. Or Rubyists away from Rails.

It is hard to pick the right driver. I don’t want to attempt providing an answer and limit your thinking. But feel free to share your thoughts in the comments.

e5 must be easy to learn & master

If you believe Eclipse 3.x is easy to get into, attend a beginner’s training. You will see how experienced Java developers struggle with the learning curve. And it’s not becoming easier with e4.

That is a problem, because it limits the mass appeal of Eclipse as a runtime solution. If you think it is a popular runtime, go to a Java User Group and see how few of the people who use Eclipse have written a plug-in for it.

It is in our human nature, that we tend to take the path that has the least resistance (read: easy) not the path that offers the most rewards (read: complex technology).

For e5 to be broadly successful it must kick-ass AND be easy to learn & master.

Looking forward to your comments,
Elias.

Tags: e4

I have been playing around with e4 (M3+Integration) today and so far I’m not impressed. I’m keeping an open mind, and may change my opinion at a later time.

At the moment however,  I would dare to say that e4 might be the “Windows Vista” moment for Eclipse. High hopes, but at the end of the day not groundbreaking enough to be interesting for a wide audience of developers (=regular java devs, web devs)

There are some things I like a lot and would like to see in 3.x, such as:

• CSS theming
• trident animations
• getting rid of the *Advisors

The biggest drawbacks in my opinion:

#1  NOT simpler,  just different

From my POV app development is still too complex for the avarage developer.  Here is why:

• Using dependency injection via annotations instead of having interfaces / abstract classes makes it very hard for beginners to figure out how to write classes. It is not obvious what annotations are available at any given point (@Inject, @PreDestroy, etc). The type hierarchy does not help for finding similar implementations – since there is no hierarchy
• The e4 workbench designer for the workbench model (.e4xmi) is nice, but unstable (failed to load my simple example). Editing the .e4xmi by hand or a tree-like emf editor is cryptic and less user friendly than the plugin.xml editor
• The plugin.xml is still necessary. So with the .e4xmi file we now have two .xml files that are relevant. I would like to see just one or none.
• Still too many technologies to master: Extension Points, OSGi, Workbench Model, EMF, Annotations, SWT, JFace.

“Simplify the programming model” is stated as e4’s first objective (e4-summary.odp), but  I don’t think this is true at present.

#2 Still big and intimidating

I often hear the Eclipse is big, bulky and intimidating. The Eclipse e4 download packs 230 MB and all the UI clutter we are used to – but many newbies find confusing.

#3 No killer feature

If a customer asked me about migrating to e4 for a product that launches in Q4 2010, I couldn’t really recommend it. At this point I don’t see any “must have“ features yet — especially for the folks that have 3.x apps up and running.

This is bad and a bit of a catch-22 situation:

• Without some “must have”  features people are going to stay with what they already know (3.x) instead taking the risk of using something new
• The longer people wait to use e4 the longer it will take to reach critical mass and a high level of maturity (i.e. most bugs found)

Looking forward to your opinions – especially if you disagree.

Kind regards,
Elias.

Tags: e4

We proudly present Riena 2.0 M5 – the first release in the 2.0 stream.  As you can see by the long New & Noteworthy, we have been very active in last six weeks. Read on for my five favorite new things:

1. Pluggable Marker Decorations

The new BorderMarkerSupport draws red-borders around a widget and replaces the standard ControlDecoration. You can select either error decoration style via the Look-and-Feel settings.

2. Enhanced Master/Details Widget

The Master/Details Widget automatically links a table with the details area on the bottom (or top). It is used heavily by some of Riena’s consumers. As a result we have been receiving good feedback and have added several requested features on this milestone:

• nicer border (includes button area, separates table from buttons with a single line)
• API to participate in the life-cycle (before / after selection, apply, remove, new)
• API to ‘suggest’ a new entry – it will show in the details area and Apply will enable
• API to tweak the margin and spacing of the Master/Details widget

3. Image Button Widget

The SWT Buttons have a system-defined look that is hard to customize (for example the background color cannot be changed). Riena’s ImageButton Widget emulates a button using three images (standard, hover, pushed state).

4. Multiple Default Buttons per Controller

Riena’s Controllers have a new API that supports several default buttons per controller. The default button has a blue glow when enabled. In that state it will automatically be pushed when the user hits ENTER (anywhere).

5. Controller Testing

Controller testing is now very straightforward and has been decoupled from the UI (widgets). Just subclass AbstractSubModuleControllerTest to get started. In addition your controller has to use the new API getRidget(Class, String) instead of getRidget(String). The package org.eclipse.riena.client.controller.test in the org.eclipse.riena.tests bundle has several examples.

Read the New & Noteworthy for additional details on these items.

Tags: helios, milestone, riena

A nice thing about Eclipse PDE is that it has mechanisms to make it very easy for developers to get started consuming your frameworks. Here are two of them.

Target Platform Templates

For runtime projects, such as Riena, RAP and Equinox, the first hurdle a developer faces is to set-up the appropriate target platform. A target platform is the collection of bundles that are available during compilation. Obviously if you ship runtime components they must end up in there to be available for compilation.

You can make this much easier for others by contributing a target platform template to the “New Target Definition” wizard. A developer can then select an entry in the “Template” drop-down and will instantly receive a pre-configured target definition. Much easier and less error-prone that recreating the target definition manually from step-by-step instructions.

Since the target definition’s payload can be provisioned over http, the developer only has to click on “Set as Target Platform” and is done. For details refer to the org.eclipse.pde.core.targets extension point.

Project Templates

Another way to help developers with their first steps is to provide a project template. This hooks into the last page of “New Plug-in Project” Wizard and pre-populates a new project with source code, binary content and appropriate plugin.xml and MANIFEST.MF files.

The templating mechanism has a lot of depth as you can manipulate data-models to dynamically craft the MANIFEST.MF and plugin.xml files. You can also define placeholder variables, such as $pluginId$ and use them in source templates. There are mechanisms to tie these variables to UI elements in the wizard pages. The developer documentation on the matter is somewhat superficial. At the moment your best bet is to check out and study the org.eclipse.pde.ui.templates project from the Eclipse CVS (/cvsroot/eclipse/pde/ui/org.eclipse.pde.ui.templates). It contains the templates that ship with the IDE and therefore plenty of examples. Complement this by reading the specification of the org.eclipse.pde.ui.pluginContent extension point and this introductory article on developer works.

Tags: pde, tips