Ribbon IDE - EclipseCon Slides

I've just uploaded the slides (pdf) from today's talk at EclipseCon. Thanks everybody who attended!

If you don't mind trying an alpha, you can download Eclipse 3.6 M6 with the ribbon here.

The Ribbon IDE - a leaner, modern UI for Eclipse

Here's a short video about integrating the Hexapixel Ribbon widget into Eclipse. I'm working on this over the holidays. It will be available for free under EPL.

If you like this, please vote for my EclipseCon submission.



Don't see the video? Click here.

Riena M5 shipped. Find out more in upcoming talks.

Riena M5 shipped this week.

Never heard of it? -- Riena is an Eclipse project for creating client-side applications. It focuses on providing an end-user-friendly UI, transparent remoting via web-services and more.

Some interesting tidbits from the release notes: 

• Riena View parts can now be used in regular RCP applications

• Navigation supports visible / disabled / hidden modules

• New ridgets for Numeric / Decimal / Date input

You can find more  details in the New & Noteworthy.

Learn more about Riena

If you are curious about Riena here are two opportunities to find out more about this project:

• Attend the Riena Project Update talk at the Eclipse Summit Europe on Nov 19th
• Participate at the Riena Webinar on  Nov 26th

Kind regards,

Elias.

Portland - Eclipse Community Events in November

Here are two upcoming events for Eclipse-heads in the Portland, OR:

• Nov 5th - Lunch 2.0 at the Eclipse Foundation
  
  Grab a lunch with the compliments of the Eclipse Foundation. No coding required ;-). 'Lunch 2.0' is an informal get-together of Portland's tech and creative folks combined with a free lunch. It's a nomadic event, usually spotted on Wednesdays once a month in downtown Portland.
  
  
• Nov 12th - Portland DemoCamp in Tigard 
  
  Peter explains why you should attend a DemoCamp way better than me. Compared to the last DemoCamp in June there's still plenty of space left - both for presenters and attendees. So go ahead and RSVP on the wiki.

Image: (c) Copyright 2007 tseemann/photocase.de

Eclipse Bug Patterns -- The selfish VerifyListener

Here's a bug pattern I ran into the other day. 

Let say we want to create a text field that accepts only digits:

 final Text text = new Text(shell, SWT.SINGLE | SWT.BORDER);

 VerifyListener onlyNumbers = new VerifyListener() {
   public void verifyText(VerifyEvent e) {
     e.doit = Character.isDigit(e.character);
   }
 };
 text.addVerifyListener(onlyNumbers);

A few weeks later the requirements change. We agree that the text field now accepts up to 10 digits. We add another VerifyListener as shown below.

Can you spot what's wrong with this code?

 final Text text = new Text(shell, SWT.SINGLE | SWT.BORDER);

 VerifyListener onlyNumbers = new VerifyListener() {
   public void verifyText(VerifyEvent e) {
     e.doit = Character.isDigit(e.character);
   }
 };
 text.addVerifyListener(onlyNumbers);

 VerifyListener maxLengthTen = new VerifyListener() {
   public void verifyText(VerifyEvent e) {
     String newText = getText(e);
     e.doit = newText.length() <= 10;
   }
};
text.addVerifyListener(maxLengthTen);

The problem

Both VerifyListeners are 'selfish'. They assume that each listener is the only one manipulating the e.doit flag (which has a true value by default). When e.doit is set to false, it blocks the modification of the text widget. 

However, when there is more than one VerifyListener, e.doit might already be false. By ignoring this -- and setting e.doit back to true -- the listeners unintentionally permit operations which would otherwise have been blocked.

The solution

The solution is simple: always add a 'guard clause' to the top of the verifyText() method. It may seem unnecessary now, but you newer know if more VerifyListeners are going to be added to the widget at some point.

 final Text text = new Text(shell, SWT.SINGLE | SWT.BORDER);

 VerifyListener onlyNumbers = new VerifyListener() {
   public void verifyText(VerifyEvent e) {
     if (e.doit == false) {
       return;
     }
     e.doit = Character.isDigit(e.character);
   }
 };
 text.addVerifyListener(onlyNumbers);

 VerifyListener maxLengthTen = new VerifyListener() {
   public void verifyText(VerifyEvent e) {
     if (e.doit == false) {
       return;
     }
     String newText = getText(e);
     e.doit = newText.length() <= 10;
   }
};
text.addVerifyListener(maxLengthTen);

Happy hacking,

Elias

Riena Milestone 4 shipped

Riena M4 shipped this Monday with many improvements.

The most interesting news - aside from the new features - is that we are providing a gradual adoption path for developers working with existing RCP applications. This should make adopting Riena easier, because you can gradually use more and more parts of the framework as you become more confident in it.

Two results of this, which are available in M4:

• You can now use Riena's Ridgets independently of the rest of the framework. The snippet collection shows some examples (more to come).
  
  BTW, a Ridget is a toolkit-independend wrapper around an actual widget. A ridgets offers the most common functionality of the widget together with convenience functions to manipulate markers (warning, error, etc.), validation rules and databinding. You can still access the original widget if necessary.
  


• You use now use Ridgets and the View (=ui) / Controller (=business logic) separation in a standard view part without the rest of the framework.
  
  This is great for people that have an existing RCP application (with a traditional UI) and want reap some of Riena's benefits without adopting its UI paradigm. The org.eclipse.riena.sample.client.rcpmail example shows how. Hint: the classes DefaultSwtBindingDelegate and AbstractRidgetController are your friend.
  

We will be trying out a few more things along this theme ("gradual adoption") on our road to M5, which is scheduled for October 31st.

Showing different images for expanded / collapsed nodes of a JFace TreeViewer

Did you ever want a JFace TreeViewer that shows different icons depending on the expanded / collapsed state of a node? The animation below shows what I mean:

Different images are shown in the tree, depending on the state of each node:

     — collapsed node
     — expanded node
     — leaf node

So here is what you need to do:

1. Create a LabelProvider that returns different images based on the expanded state of an element:
   

   class NodeLabelProvider extends LabelProvider {   
     // ...
     public Image getImage(Object element) {
       Image result = LEAF;
       Node node = (Node) element;
       if (node.hasChildren()) {
         result = viewer.getExpandedState(node) ? NODE_EXPANDED : NODE_COLLAPSED;
       }
       return result;
     }
   }



2. Create a TreeListener to update the image when the users clicks on the plus or minus icon in the tree:
   

   class UpdateIconTreeListener implements TreeListener {
   
     public void treeCollapsed(TreeEvent e) {
       updateImage((TreeItem) e.item, true);
     }
   
     public void treeExpanded(TreeEvent e) {
       updateImage((TreeItem) e.item, false);
     }
   
     private void updateImage(TreeItem item, boolean isCollapsed) {
       Image image = isCollapsed ? NODE_COLLAPSED : NODE_EXPANDED;
       item.setImage(image);
     }
   
   }



3. Tree elements can be expanded/collapsed via Java code by calling methods such as viewer.expandToLevel(Object, int) and viewer.collapseToLevel(Object, int). Remember to manually trigger an update of the element's label (i.e. the image and text) in those cases:
   

     viewer.expandToLevel(node, 1);
     viewer.update(node, null);
   

Download the example project.

Happy hacking,
Elias.