Java, Mac, Software and other kaos

2011-01-27T23:22:00.000-08:00

I have finally launched a fantastic new workshop on Object-Oriented Analysis & Design.

I call this a workshop, since most of the time the participants are doing the work; in teams busy doing analysis and design, thus applying and internalizing the concepts and principles being taught. Some fundamental OO Analysis & Design skills, including introduction to various UML diagrams, are taught, and then applied on a project.

This workshop starts from the first steps of requirements analysis (we talk about evolutionary requirements) to the Use Case model to the Domain Model to the Design Model, including principles and patterns such as GRASP, DDD (domain-driven design), TDD (test-driven development) and Design Patterns.

Throughout the workshop we apply what we learn in an iterative manner to a single project that we need to analyse and design for.

The few times I have already presented this workshop the participants and me had lots of fun while learning and applying very valuable OO analysis and design skills.

Making Java GUI Development easier

2010-06-09T23:33:00.000-07:00

I’ve been programming in Java for about 13 years now, and I’ve becoming more and more convinced that there should be a much easier way to create GUI applications than writing Java code.

This might sound like a strange statement, especially coming from a huge Java fan like me.

I see teams struggle daily to build GUIs. Not because Swing or SWT/RCP is bad -these are two great UI frameworks- but just because such a lot of code must be written. The code is also not necessarily the most inspiring kind of code; there are only so many ways that you can write data-binding code using JFace data-binding, or do layouts doing GridLayout (try using FormLayout: much more fun).

Good GUI applications are difficult to write (in my view much more difficult than your typical server-side code), but - and this is the thing to think about - about 80% of the code should “just happen”. (Some people might call this the scaffolding code or donkey code).

Over the years I started searching for this elusive technology that will help me make this 80% of the GUI code “just happen”. I want to think about my domain, practice some good domain-driven development, and then blink my eyes and the GUI must be there. Then I can spend the rest of project doing the more difficult 20% of the code...

What an adventure it is to search for this Holy Grail in the software world...

One’s journey will perhaps start off with one of the most obvious first quests to go for (and in some development environments the only available quest...): the visual designer/builder/drag&dropping tool.

A next quest might lead you to the highest peaks of UI DSLs. Technologies like Glimmer, Gryphon, XScalaWT, ScalaSWT, XWT, etc.

No adventure would be complete without a quest into the dungeons of code generation tools, like spring-roo, but for the Desktop GUI world. XText is an exciting project in this and the DSL realm that warrants some exploration.

The deepest of the dungeons might reveal code generators that actually generate XML... perhaps a XML-based UI DSL, like XWT. But XML always begs the question: is it fit for human consumption? What if something does go wrong with the tooling, would you want to go and hack UI code in XML?

Back to the Basics...
In this adventure, as I went from quest to quest in search of that illusive technology, I came to realise: probably the most important part of the GUI development process is a basic foundation of good practices and principles, to be applied no matter what technology you are using.

And the first of these core principles: do not become bogged down with a particular GUI technology.

Java offer a wide eco-system of technologies that play together very nicely. You do not even have to know Java to code great Java-based GUIs. Try out different approaches, different technologies. I know I’ve been playing very hard with various options, so I can avoid working hard writing donkey code.

PS: I’m presenting a one-day workshop on this topic on the 8th of September in Worcester, South Africa (near Cape Town). We’ll look at typical frustrations and issues with GUI development, explore UI DSLs hands-on (yes, even straying away from Java in the process...), play with XText, talk about practices and principles, and generally have a lot of fun.
More info here.

Exciting new Java Courses in South Africa

2010-05-27T04:36:00.000-07:00

I have been doing a lot of work around renewing my Java courses, talking to Heinz Kabutz in Crete, creating a new website.
Why?
Because I realized I have a passion for teaching others how to become great programmers. So am starting to concentrate more on training (while still doing enough real development work to keep the balance).

I am very excited to announce three new open Java courses that are going to be presented in June/July in South Africa by me.

First we have the Java and OO Foundation course, from 14-15 and 17-18 June 2010 (16th is Youth Day), happening in Worcester, South Africa, at our new training facility there. I can recommend this course to anyone starting out with OO and Java. Most of the content comes from my friend Heinz Kabutz’s JavaSpecialist Java Foundation course.

Then we have our first presentation of the Java Intermediate Course happening from 5 to 8 July, also in Worcester. I can recommend this course to developers who are comfortable with the basics of the Java language and OO, and who wants to learn more about real life Java topics like using JUnit, concurrency, generics and annotations.

Finally we have another big first for Africa: the first presentation of the now famous Java Specialist Master Course, from 13 to 16 July 2010. All those Soccer World Cup fans out there: stay a week longer in South Africa and come attend this brilliant course, authored by Heinz Kabutz.

I am extremely excited about our new training facilities in Worcester, which we call “The Loft @ PolymorphHQ”. Worcester is only about 100km away from Cape Town, a very scenic drive over the mountains. I am planning to combine all courses presented in Worcester with a bit of wine-tasting or even game-drive experiences. We are also investigating providing special packages that include accommodation. And we will definitely work in a nice steak and some good red wine with great Java discussions one of the evenings of the course.

I also want to announce our The Loft opening special: if you register for both the Java and OO Foundation (14 June 2010) and the Java Intermediate (5 July 2010) courses, you save R7,000.

I hope to have a lot of great Java developers coming out of Worcester these next few years :-)

No more handles: when the OS intrudes on cross-platformism

2010-05-20T03:19:00.000-07:00

One of my clients recently contacted me in panic: "We get 'No more handles' exceptions in SWT. Help..."

They have a quick big heavy-duty Eclipse RCP app running in their call centre, where a minute downtime can cause thousands of Rands (hmm, that would be thousands of Euros/Dollars as well) financial losses.

Needless to say, this only happens on Windows. Windows limits the number of what they term "GDI handles". These are basically OS handles to graphical objects, like images, fonts, colours, cursors, and GC (as in Graphical Context, not garbage collection)
For more background on this GDI handle problem, read this article.

The important here is: in SWT you as developer MUST dispose all graphical objects yourself, just like working with e.g. file IO or database connections.

In the normal way of working, you would e.g. create a RCP ViewPart, add widgets to it, and then eventually it is closed, and RCP dispose it and all the widgets on it. So for the typical widget, dialog or viewpart you are covered.

However, when you start to instantiate your own Font, Color, Image, GC or Cursor, you need to keep track manually, and call dispose() on the instances.
The best way is to make use of ImageRegistry, FontRegistry and ColorRegistry (look at JFaceResources class for the default registry instances).

In real life, though, we have two big culprits:
1) Developers like to create custom widgets (and yes, sometimes we actually need it as well). This typically entails using a number of these graphics classes, especially the GC class.
A lot of developers then forget to call dispose() on the GC object after it has been used.

2) I find that a lot of people using Eclipse RCP or SWT does not know that they need to dispose these graphics objects, and they also do not use the registry classes. Or they might think they must only do it with Images, Colors and Fonts, and then they creating new Cursor and GC instances all over without disposing it.

It takes only a few of these leaked instances to crash an application over time.

How do I solve it?

I have tried different tools, but found the best tool for me is Sleak.

Basically, you get the Sleak plugin, make it part of your runtime plugins, and then you need to change your perspectives to include the Sleak View as well.
You can get a good tutorial on using it here.

Sleak can take a snapshot of the existing GDI handles that are open, with the option to give you a stacktrace so you can see where each one is created. Then you can open a screen, or perform some actions, and get a difference, which will indicate whether any new handles has been created form the previous snapshop.

Now all you need is some patience, as you'll have to try out various functionality of your application, and find those handles that does not get disposed.

I've sent some fixes to my client, and now only time will tell if I got all those leaks...

[Update 31-5-2010] I have found another tool that I want to play with that will help find these kind of leaks, as well as debug UI layouts: Yari.

experts training experts

2010-05-12T14:41:00.000-07:00

I am very honoured to have been certified by Dr Heinz Kabutz of JavaSpecialists.EU to present his Java Specialist Master course. This is an excellent advanced Java™ course, the best by far (according to my totally objective point of view, and excuse the pun).

We had a great time in Chania, Crete last week diving deep into the realm of Java.

With a bit of planning we (as in my company Polymorph Systems) has launched our new Java and OO training website as well today, to coincide with us being able to advertise the Java Master course in Southern Africa now. Go read there now what this course is about and why you should attend it.

I am extremely excited about presenting this new course, as well as some refactored introductory and intermediary courses on Java as well as Eclipse RCP and RAP.

Too long has training companies in South Africa been getting away with mediocre courses presented by trainers with no real world experience. We are aiming to change that, starting today.

For quality software, one needs quality training.

Training by Coding

2010-03-25T01:01:00.000-07:00

I have been presenting various Java, Eclipse and OO courses for a number of years now, and always tended to allow at least half of the courses’ time to be used doing practical exercises.

This week is the first time I’m presenting a whole new Java learning experience: the students has to build a deliverable, running client-server application that persists to a database in one week’s time, using only Java SE. In this case the students only learned the Java basics the previous week.

And they are enjoying it immensely. And I am enjoying it. This course really is a lot fun.

It also makes me wonder: can’t I somehow combine this with the more theoretical introductory course? The difficulty would be to somehow cover the necessary theory on OO, Polymorphism and the various Java syntax and constructs, while allowing the students to spend at least 80% of the time coding an actual project, applying TDD, deploying deliverable code and learning some tricks and tips a theoretical course would not cover. I even throw in a bit of DDD.

A week would probably not be enough, and then it gets more difficult selling the course to companies, as most companies can’t even spare one week in fear of their project plans being disturbed.

I’m confident that this more practical and more interactive (as in extremely interactive) approach to introductory technical courses are the way forward, and this week proofs it for me.

Keep an eye on this blog as I’ll be introducing changes into my existing Java, Eclipse RCP and OO courses.

And, as always, I am very keen on hearing your thoughts around this.

South Africa Eclipse Expert Group

2010-02-07T22:44:00.000-08:00

Eclipse technologies are not that widely used in South Africa (except for the Eclipse IDE). As a result, there are not many (if any) companies concentrating on building skills in that area. However, an increasing number of local companies are using especially Eclipse RCP to build rich applications with, or introducing OSGi in their architecture (and to code Eclipse properly, one needs to know OSGi).

The Vision

My company recently had the vision to create THE leading Eclipse technologies expert group in Southern Africa. We have been spending more and more time supporting other companies in their use of Eclipse technologies, as well as increasing our portfolio of Eclipse-based projects.

And we're running out of skilled people.

We now started to grow a team of Java developers to become a team of experts on Eclipse technologies, including RCP, RAP, GEF, EclipseLink and OSGi.

The Mission

Our mission for the Eclipse Expert Group can be stated as:

become experts in Eclipse technologies
deliver quality software using Eclipse technologies
provide expert advise and support to other companies that need it
increase the local Eclipse skills by providing training and mentoring
contribute to the Eclipse community by participating in open-source projects

For me this is a very exciting vision.

To the wider Eclipse community out there (of whom very few are based in South Africa) : I want to invite you to provide me with tips, input and advise on growing this team; maybe even come and visit us as part of your next Africa safari, or supply opportunities to do work for you. One never knows, maybe in a few years we'll have some international Eclipse conferences down here :-)

PS: We started on the open-source road by making the commercial version of RCP Toolbox open-source.

Domain-driven UI design

2010-01-19T02:39:00.000-08:00

We have all read and are actively using some sound DDD principles (I hope :-) ).

For some clients I found the approach of discussing the domain model using an ubiquitous language and various diagrams and (perhaps) written documentation just does not work very well. We can have days of workshops with the domain experts, and still, when presenting some iteration of work, the questions and confusion come pouring in.
But that is part of DDD, getting feedback, refining the language and the model, etc.

Now step back a moment, and look a bit differently at solving this communication gap.

We can use UI mockups and prototypes.

There is always the danger of going into too much irrelevant detail too soon, or being side-tracked into application infrastructure, or more work involved in presenting a domain concept on a UI mockup or prototype than with a diagram and descriptive paragraph of text.

However, once again DDD comes to save the day, from there what I call "Domain-driven UI design". What do I mean with this?

We use DDD to design the model, but we use UI mockups, perhaps prototypes as well, as a way of presenting the model we are building to the domain experts, in stead of diagrams or other forms of presenting the model.

These UI mockups still need to strictly adhere to the domain language!

In a project I'm busy with currently, we base all the workshops we have with the domain experts around the UI screens, while still coming back to discussing the domain objects and model while busy with screens depicting those objects.
We still use an ubiquitous language, we still build up a rich domain model, but we use primarily UI designs to present it to the domain experts, because for this specific group of experts that is what they understand best. It is more concrete for them, thus allowing them to give better feedback.

However, it does place a big responsibility on the facilator: he/she must be able to keep the domain discussion from being side-tracked by non-domain concerns that are typically also part of a UI mockup or prototype. At such workshops we do not want to discuss the exact border width to use for checkboxes... (there is a place for such discussions, but not when using the UI as a way to facilitate domain design discussions)

And behind the scenes?

When we go back to our development work, we first update our domain model (wherever that is depicted), then our tests, then our domain objects, and lastly the next round of UI prototype screens and/or mockups. We find that taking the domain model through to the UI level actually help enrich our understanding of it, and ultimately enrich the communication process with the clients, leading to more valuable feedback.

Ultimately good design and good code is mostly about good communication, and using this domain-driven UI design approach has greatly enhanced the communication in a number of projects I've been involved with.

References:
I can really recommend Erik Evan's book on DDD:
Domain-Driven Design: Tackling Complexity in the Heart of Software

Eclipse Tips: Commands

2009-10-06T04:22:00.000-07:00

I recently discovered a nice blog by G.R. Prakash that has a number of posts about the Eclipse Commands API.

Please do yourself the favour and visit the posts below:

Eclipse Tips: Commands Part 1: Actions vs Commands

Eclipse Tips: Commands Part 2: Selection and Enablement of IHandlers

Eclipse Tips: Commands Part 3: Parameters for Commands

Eclipse Tips: Commands Part 4: Misc Items

Eclipse Tips: Commands Part 5: Authentication in RCP Applications

Eclipse Tips: Commands Part 6: Toggle and Radio menu contributions

Eclipse Tips: Commands Part 7: Adding standard commands

I will also be adding some more posts on Eclipse Commands shortly.

Myths of UI Design

2009-08-20T02:05:00.000-07:00

I recently presented a workshop on UI design in the software development world, and as part of the workshop we talked briefly about some common UI Design myths.

I thought it might be useful to iterate some of the myths again on my blog. (You can find the slides of my workshop presentation here). This is from my experience in designing and implementing user interface applications, as a software developer, not a user experience engineer or human-computer-interface expert.

Myth #1: Developers know what users want

One of my favourite comics from www.ok-cancel.com is this one:

Need I say more?

I can also heavily paraphrase Joel Spolsky (from his book "User Interface Design for Programmers") and say that we forget that:
most users cannot read
most users cannot use a mouse
I'm not trying to ridicule the end-user here. (I'm a end-user myself.) Joel explains the much better than me, so grab hold of his book. But what it boils down to is that we need to keep the interface as simple as possible. Users will typically not read long sentences, or even phrases, in a dialog or wizard, or wherever else you display them. A lot of users will also not even read the user manual (I never do...).

We developers are also inclined to think all users have super-duper mouse skills, honed on numerous Dota or Quake3 games, using great laser-mouses on clean desks. We forget that some computers are used in greasy factories or workshops, a lot of cheap inaccurate mouses are being sold daily and everyone does not have nifty 24" or bigger monitors.

Somehow the simplicity thing is very difficult to grasp...

Look at the numerous overly complex, distractingly busy websites out there. Look at all the feature-bloated, monstrous applications we have to struggle with. Because we as developers like to tune our operating systems and play with every setting we can find, does not mean our end-users wants all that choice and features. For them the software is just a tool to get their real work done, hopefully in as simple as possible way.

This does not mean we must make all our software so simple that it does not add value to the user. Some UIs needs to be complex to provide what the user needs, e.g. IDEs. However, these the user will get to know over time, and get to expect how it will behave.
I think the challenge is to find the simplest possible design that provides what the user expects.

Myth #2: UI Design is art, just do what you want

“Art is about freedom, Design is about constraints” is a quote that I read a while ago on a website, but I could not find the quote again. (If whoever wrote this somehow reads this post, please contact me and introduce yourself :-) ).

UI design and implementation is a very creative process for me, however, it is a process that must take a lot of constraints into consideration. One might naively think that you can let your creative side just take over and be totally free with your designs. Unfortunately you will most probably loose all your users along the way; scared away by the radically new ideas and metaphors that you so artfully brought into the software.

Life is at its core a balancing act; the same with UI design. You need to be creative, but you also need to be consistent with what the user expects.

Of course there are always some other less welcome constraints that typically influence a project. You know... lack of money, tyrannical management, looming deadlines, issues with the GUI framework that was chosen, and so forth. These all join together to kill of that spark of creativity... (or sometimes actually ignite it, like a wild animal trapped in a corner).

Myth #3: UI can be left for last

The sad truth in the software development arena is that UI design and implementation somehow gets left for the last minute in many projects out there.

The feeling I get from a lot of companies where I consult or do development is that the user interface part of a project is seen as being inferior to “Server development”. You get The System, where all the experienced developers are being used, and then there is that "little bit off to one side" where some junior code monkeys get dumped to spin out some quick check-boxes.

[Disclaimer: I do not see these guys as junior code monkeys; that is part of the feelings floating around that I observed.]

When I see this, I want to scream (in some cases I do scream): People, ARE YOU MAD! The user interface is the end-users' view of the system. It MUST be professional and conform to there (highly complex, yet simple) expectations, otherwise the whole system will be perceived as a failure. It does not matter if your database can handle 10000 transactions in a second for 100000 users connected simultaneously and compress the data such that each record takes up only 1 bit. If the user interface(s) of the system is lacking, your whole project will be a failure.

I put it very bluntly (you might say provocatively) at the UI workshop the other night: server-side coding is very easy. You design some domain objects and some business logic, and select the framework that ties everything together. There is known input and known logic to get some known output from that.

On the other hand, UI development is extremely difficult. You have two major unknowns:

the user (show me a predictable user)
the windowing system of the OS (Remember: the experienced guys has worked on the kernels, while the UI framework and windowing systems of the different OS's has been build by the new kids on the block...)

What does this mean? Put your good developers on GUI development as well.

OK, before you get too worked up, I have stated it in the extreme above. However, it seems that there is a mental block about this at a lot of companies. Not all companies, no. But a lot.

A lot of successful companies have banished this "server team" vs. "gui team" approach, and actually get their developers to work on all the layers that make up the systems.

I'm going to wrap up this post now, and hope for the same kind of debate I got at the workshop...

CT-SPIN #49: UI Design Workshop

2009-08-11T13:29:00.000-07:00

On 19 August I am going to present what I hope is going to be a fun-filled and enlightening evening workshop on pragmatic UI Design at the Cape Town SPIN group.

We are going to look at UI Design in a hands-on way. So if you are in Cape Town region then, come and pop in:

For more detail, visit this link:

CT-SPIN #49: "Art is about freedom, Design is about

constraints" | Cape Town SPIN

8 Regular Expressions You Should Know - Nettuts

2009-08-11T03:36:00.000-07:00

I recently had to do some regular expression matching against email addresses. This link is really handy:

8 Regular Expressions You Should Know - Nettuts

The bad side of good abstraction

2009-08-11T02:45:00.000-07:00

Good, well-designed abstraction can be bad. Or rather, has some negative aspects as well.

Let me explain.

In most projects I have been involved in some form of abstraction layer was build on top of the libraries and frameworks used. A kind of domain-specific framework.

Typically this layer is meant to make it easier to build the system. The (more experienced/senior) developer(s) would implement this, thereby allowing the rest to work with a limited facade of the lower level libraries. I have also instigated and added to such layers many times; it is especially useful to build a more domain oriented application framework on top of the general Eclipse RCP framework (or Swing, in the earlier days).

If this layer is designed and implemented well, it usually enhances productivity and generally makes everyone feel all happy and content.

After a discussion the other day with a very bright developer, who is still new to Eclipse RCP, I came to realise there is one serious bad issue with this approach: skills development.

This guy has been working on a very complex RCP application, using a lot of the abstracted custom framework and some of the "low level" RCP itself. And then came the day he had to develop an Eclipse RCP app from scratch, in another business domain, without the help of the abstraction layer.

Suddenly he had to start learning a lot of "new" RCP concepts and API. Things that has been hidden (read: encapsulated) away from him until now.

This led me to start thinking about my approach when I mentor or lead teams: I must somehow maintain a balance between this kind of (necessary) abstraction that enhanced productivity, and still allowing the team members to pick up the necessary skills on the "hidden" areas.

Please feel free to contribute your ideas and possible solutions to this balancing game as comments.

One-armed but still typing

2009-07-14T08:10:00.000-07:00

I'm sitting here and typing as fast as I can with one hand.

In my other arm I am holding my newly born baby daughter, now one week old. She has kept us quite busy these last 2 weeks, so my blogs has dried up a bit.

Just some of the things I've been meaning to blog about, and will hopefully find time for soon:

Some exciting happenings on the Java and OO training front in South Africa.
An Eclipse Democamp/ informal conference in Cape Town, RSA
An informal Java conference (or maybe combine with 2), also in Cape Town
A quick glance at Eclipse Pulsar and MJT for developing Java ME midlets
How to integrate J2me-Polish with your Eclipse midlet projects
Further blogs about the Eclipse Commands API
Using AspectJ to get rid of all kinds of listeners and donkey code when implementing GUIs in Java.
and so much more...

But currently I must balance between staring at my daughter, and doing some paying work :-)

Just keep an eye on this space, though.

Java Developer Conference in South Africa

2009-06-18T23:21:00.001-07:00

One thing that I miss a great deal in South Africa is a choice of good Java developer conferences, demo camps, etc. Okay, drop 'good' and replace it with 'any'.

About once every 3 years Sun hosts the Java Dev Days in Johannesburg, and that is about it.

I started thinking it is time to start creating interest in a Eclipse and/or Java conference just before or after the 2010 Soccer World cup here in SA. To boost the numbers of SA developers with the visiting fundis from overseas.

It seems both the Eclipse Foundation and Eclipse Training Alliance would be keen to support an Eclipse focused event. I'm starting to determine the feasibility of an Eclipse-only event in SA.

A great option for the smallish size of the SA developer community would be to combine Eclipse and other Sun-side Java technologies, but would possible politics between the Sun and Eclipse organisations allow this?

It would be great if you can indicate in a comment or tweet me @hermanlintvelt about your interest in such an event, whether you are interested in Eclipse technologies or not and if you are from South Africa or not.

Would be great to hear from you, Herman.

Posted with LifeCast

Eclipse RCP Commands Part 3: visibleWhen and Core Expressions

2009-06-03T08:17:00.000-07:00

This is the third part of my blog series on the Eclipse Commands framework. Please see Part One for an outline of topics covered in the various blogs.

Limiting visibility of Commands

A powerful feature of the Commands framework is that you can declare in the plugin.xml when a Command should be visible (or rather when specific menu contributions should be visible) and when it should be enabled. This is done by using what is called core expressions.

Simple visibleWhen definition

Let us take a simple example first: we want to limit the Annotate eBook command (from the example in Part Two: Quick Review) to only show in the context menu if one item is selected in the view. If no item is selected, or more than one, it must not appear in the menu.

First select the popup:org.eclipse.ui.popup.any?after=additions menu contribution extension element

Now select the Annotate command element, right-click and choose New -> visibleWhen

Set the checkEnabled value to false (setting to true will use the enabled state of the command to determine the visibility)

Right-click on the visibleWhen element, and choose New -> with

Set the variable attribute to "activeMenuSelection". "activeMenuSelection" is a known expressions variable that will get resolved when the platform must populate the context menu. Se the list of other known expression variables.

Right-click on the activeMenuSelection(with) element and choose New -> count

Set the value attribute for count to "1".

We have now set up the context-menu contribution to only show the Annotate command when one and only one item in the view is selected. That was not so difficult, was it? I remember spending hours on creating nice selection behaviour helper classes for IActionDelegate-based frameworks, and still not getting the initial visibility or enabling of the actions in the menus right, due to constraints with that approach.

The menu contributions extension in the plugin.xml now looks like:


   <extension
         point="org.eclipse.ui.menus">
      <menuContribution
            locationURI="menu:file?before=quit">
         <command
               commandId="com.richclientgui.myreader.commands.OpenEBook"
               mnemonic="O"
               style="push">
         </command>
         <command
               commandId="com.richclientgui.myreader.commands.AnnotateEBook"
               mnemonic="A"
               style="push">
         </command>
      </menuContribution>
      <menuContribution
            locationURI="popup:org.eclipse.ui.popup.any?after=additions">
         <command
               commandId="com.richclientgui.myreader.commands.AnnotateEBook"
               label="Annotate"
               mnemonic="A"
               style="push">
            <visibleWhen
                  checkEnabled="false">
               <with
                     variable="activeMenuSelection">
                  <count
                        value="1">
                  </count>
               </with>
            </visibleWhen>
         </command>
      </menuContribution>
   </extension>

Expression Definitions

Before I delve more deeply into even more interesting visibleWhen capabilities, first a very nifty tip on core expressions: it is possible to declare a specific expression definition, and then just refer to that definition from your visibleWhen, activeWhen, etc elements.

We do this with the org.eclipse.core.expressions.definitions extension. To define an expression that checks that only one item is selected:

Add the org.eclipse.core.expressions.definitions extension (click Add... on Extensions tab of plugin manifest editor, you might need to uncheck the "Show only extension points from the required plug-ins" checkbox)

Give a proper id to your definition, e.g. expression.onlyOneItemSelected

Right-click on the expression.onlyOneItemSelected element and choose New -> with

Set the variable attribute to "activeMenuSelection".

Right-click on the activeMenuSelection(with) element and choose New -> count

Set the value attribute for count to "1".

You might have noticed it is the same steps as those followed for a simple visibleWhen definition above.
For those who rather do it directly in the plugin.xml, here is the org.eclipse.core.expressions.definitions extension declaration:


   <extension
         point="org.eclipse.core.expressions.definitions">
      <definition
            id="expression.onlyOneItemSelected">
         <with
               variable="activeMenuSelection">
            <count
                  value="1">
            </count>
         </with>
      </definition>
   </extension>

How do I use the expression definition?

What do you gain with first defining an expression? Well, you can reuse this definition in multiple places in your plugin.xml if you need the same expression, whether it is for a visibleWhen, activeWhen or enabledWhen declaration.

To replace our expression for our context menu contribution with the definition, you simply do the following:

Select the activeMenuSelection(when) element under the popup:org.eclipse.ui.popup.any?after=additions menu contribution's visibleWhen element, right-click and select Delete

Right-click again on the visibleWhen element and choose New -> reference

Set the definitionId attribute to expression.onlyOneItemSelected (i.e. the id of the expression definition you want to use to evaluate whether the menu contribution must be visible or not)

If you run the application now, it should still behave the same as before we used our own definition, but now we are ready for a much more complex playing field. Underneath is a screenshot of how the extension declarations should look in the Plugin Editor.

To infinity and beyond: the power of expressions

We have seen a very basic expression up to now. You should have seen a number of other possible items to choose from when you selected New -> with in the steps above. I list them below. These can all be used to build up complex expressions that gets evaluated at runtime to determine whether a specific menu contribution should be visible or not, if used in conjunction with a visibleWhen element.

Element	Description
adapt	Use to adapt the object in focus (i.e. the object passed to the expression) to the specified type. See Using adapt for more information.
and	AND the results from evaluating the sub-elements
count	Use to count the number of elements in a collection. The value attribute be an integer or a supported wildcard. See Using count for more information.
equals	Use to check equality of the focussed object with the specified value attribute
instanceof	Use to perform an instanceof check on the object in focus. See Using instanceof for more information.
iterate	Use to iterate over a collection, if the focussed object is of type java.util.Collection. See Using iterate for more information.
not	NOT the results from evaluating the sub-elements
or	OR the results from evaluating the sub-elements
reference	This is the element we use to refer to an expression defined under org.eclipse.core.expressions.definitions. The definitionId is the unique id of the expression definition to use for the evaluation.
systemTest	Use to test a system property, where property is the name of the property to get via System.getProperty, and value is the expected value to test against (as String value).
test	Use this element to test the value of a specific property on the focussed object. See Using test for more information.
with	Use to change the object to inspect or focus on to the object referenced by the variable attribute. See the list of available expression variables.
resolve	Resolve does almost the same as with, but it allows the use of a custom IVariableResolver, and passing the specified args as arguments to the variable resolver. More detail might be topic of a future blog post. I must admit, I have never used this one.

Note on String values

The value attribute for the above elements gets specified as some string. Here follows the extract from the Eclipse online help on how that String value might get converted:

When specifying a value to be tested against any of these expressions, the value is assumed to be a string except for when the following conversions are successful:

the string "true" is converted into Boolean.TRUE

the string "false" is converted into Boolean.FALSE

if the string contains a dot, the interpreter tries to convert the value into a Float object

if the string only consists of numbers, the interpreter converts the value into an Integer object
the conversion into a Boolean, Float, or Integer can be suppressed by surrounding the string with single quotes.

Using adapt

Adapt is used to adapt the object in focus (you can see this as the object provided or specified by the parent element) to the type specified its the type attribute. Any sub-elements of the adapt element will be evaluated against the adapted object. Read up about IAdapterFactory and IAdaptable interfaces for more information about adaption.
If the object can be adapted, the adapt evaluate to true. E.g. we can define an expression for evaluating if something adapts to the ICountable interface.


   <extension
         point="org.eclipse.core.expressions.definitions">
      <definition
            id="isCountable">
         <adapt
               type="org.eclipse.core.expressions.ICountable">
         </adapt>
      </definition>
   </extension>

Using instanceof

This is used to perform an instanceof check on the object in focus. We can for example enhance our Annotate eBook menu contribution in the File menu to only display if at least on of the selected items is an instance of java.lang.String (iterate gets discussed here):


   <extension
         point="org.eclipse.ui.menus">
      <menuContribution
            locationURI="menu:file?before=quit">
         <command
               commandId="com.richclientgui.myreader.commands.OpenEBook"
               mnemonic="O"
               style="push">
         </command>
         <command
               commandId="com.richclientgui.myreader.commands.AnnotateEBook"
               mnemonic="A"
               style="push">
            <visibleWhen
                  checkEnabled="false">
               <with
                     variable="selection">
                  <iterate
                        ifEmpty="false"
                        operator="or">
                     <instanceof
                           value="java.lang.String">
                     </instanceof>
                  </iterate>
               </with>
            </visibleWhen>
         </command>
      </menuContribution>

Using iterate

Iterate can be used if the object in focus is a java.util.Collection (e.g. when with is used in the parent element and the variable attribute is set to "selection"). It iterates through the collection, and evaluate the sub-elements against each item in the collection.

The operator attribute can be set to and or or. For and, every item must cause the sub-elements of the expression to evaluate to true, and for or, at least one must evaluate to true.

The ifEmpty attribute can be set to true or false. If true, then the iterate expression will evaluate to true for empty collections, else to false.

See the example under the instanceof section.

Using count

The count element's value attribute can take an integer value as parameter if the collection needs to contain the exact number of items. However, the following wildcards are also allowed:

*	Any number of items
?	Zero or one item
+	One ore more items
!	No items

See our first simple visibleWhen example for usage.

Using test

Test can be used to evaluate the state (i.e. value) of a specific property of the focussed object. The test expression can evaluate to true, false or not-loaded if the property tester (implemented by a Java class) is not loaded.

property	specifies the name of the property of the object to test
args	specifies additional arguments to pass to the property tester
value	the value we expect the property to be
forcePluginActivation	if this is set to true, the plugin that contributes the property tester class will be loaded to enable the evaluation, if it is not loaded yet. However, this loading will only happen if the evaluation context used allows plugin activation. What does this mean: do not depend that when you set this flag to true, the plugin containing the property tester code will actually be loaded.

In a future blog I will discuss how to implement your own property testers; quite a powerful feature. For now, let me just point you to some property testers available for your enjoyment. You can follow the links for the detailed code level information, or else have a look at the Propery Testers section in the Command Core Expressions wiki page for a summary.

PlatformPropertyTester

ResourcePropertyTester

FilePropertyTester

ProjectPropertyTester

ResourceMappingPropertyTester

ActivityPropertyTester

OpenPerspectivePropertyTester

Core Expression Variables

I was planning to list the most common variables available for core expressions here and discuss some of them, but time caught up with me. For now I will point you to:

The Variables and the Command Framework section in the Command Core Expressions wiki page.

The ISources.java file that list these variables.

Note: if you use the selection variable, you need to make sure the View that you are expecting a selection from is a SelectionProvider for the platform by registering it as a selection provider, e.g. by calling getSite().setSelectionProvider(viewer).

Coming soon...

What about enabling and disabling Commands? (enabledWhen, activeWhen)

More on using object properties to determine visibility and enablement of Commands (propertyTesters)

If you don't like XML: how to tune your Commands from the Java side of things (the programmatic approach)

References

Eclipse.org Commands Framework Article in bugzilla

Article on Eclipse Commands Framework, by Marc R. Hoffmann

Eclipse.org Wiki on Command Framework

Eclipse Commands Tutorial, by Lars Vogel

Eclipse.org Wiki on Core Expressions

Eclipse.org Wiki on Menu Contributions

Eclipse.org Wiki on mapping from old to new menu contribution extension points

Enough said.

Archeology of Java

2009-06-01T14:18:00.000-07:00

When faced with a bulky problem...

you have to start digging.

Thanks to Aslam Khan for planting the term "archeology of Java" in a discussion.

Eclipse RCP Commands API: Review of Part Two

2009-06-01T02:47:00.000-07:00

Quick Review: Defining a Command

In this blog I just to want review the basic definition of a command by adding an additional Command to the example application using the steps defined in Part Two of the series on Eclipse RCP Commands.

We already have an Open eBook command that we made visible in the File menu of the MyReader application. Now we want to add another item to the File menu, as well as to a context menu, to allow the user to annotate an eBook. Let us call this the Annotate eBook command. So let us follow the same eight steps we did for the Open eBook command.

Step 1: Create RCP application

Done already (I assume you are working from the example in Part Two.)

Step 2: Add org.eclipse.ui.commands extension to plugin.xml.

Done already. (see step 2 of previous blog)

Step 3: Declare Annotate eBook command.

right-click the org.eclipse.ui.commands extension, and select New -> Command from the context menu.

change the id to something like "com.richclientgui.myreader.commands.AnnotateEBook"

change the name to "Annotate eBook"

change description to "Annotates the current eBook"

Our plugin.xml now contains the following entry for the org.eclipse.ui.commands extension:


   <extension
         point="org.eclipse.ui.commands">
      <command
            defaultHandler="com.richclientgui.myreader.handlers.DefaultOpenEBookHandler"
            description="Open an eBook file for reading"
            id="com.richclientgui.myreader.commands.OpenEBook"
            name="Open eBook">
      </command>
      <command
            description="Annotates the current eBook"
            id="com.richclientgui.myreader.commands.AnnotateEBook"
            name="Annotate eBook">
      </command>
   </extension>

Step 4: Add the org.eclipse.ui.menus extension to plugin.xml.

Done. (see step 4 of previous blog)

Step 5: Add the menuContribution element

We want to make our Annotate eBook command accessible both in the File menu, and in the context menu of the view. We already declared a menuContribution for the File menu (see step 5 of previous blog).
In order to make the command accessible in any context menu, we add a new menuContribution:

Right-click the org.eclipse.ui.menus extension, and select New -> menuContribution from the context menu

Change the locationURI to popup:org.eclipse.ui.popup.any?after=additions

Step 6: Add the Annotate eBook command to the menuContributions.

Right-click on the menuContribution created in step 5, and select New -> command from the context menu.

Change commandId to the id you provided to your Command definition in step 3.

Change mnemonic to "A" to underline the first letter of "Annotate" as your shortcut mnemonic for your command in the menu.

Repeat the above for the menu:file?before=quit menuContribution element.

But now we have an interesting problem: the client wants the menu item in the File menu to read "Annotate eBook", but the context menu's item must read only "Annotate". If we change the name attribute of the command definition, then it will change in both places. Luckily, the Commands API can help us out here. It is possible to change the presentation of commands for specific menu contributions by "overriding" the text to be used for labels and tooltips. To do this we:

Select the command contribution element under the popup:org.eclipse.ui.popup.any?after=additions menu contribution elment,

and change the value of the label attribute to "Annotate".

Our org.eclipse.ui.menus extension definition in the plugin.xml now looks like:


   <extension
         point="org.eclipse.ui.menus">
      <menuContribution
            locationURI="menu:file?before=quit">
         <command
               commandId="com.richclientgui.myreader.commands.OpenEBook"
               mnemonic="O"
               style="push">
         </command>
         <command
               commandId="com.richclientgui.myreader.commands.AnnotateEBook"
               mnemonic="A"
               style="push">
         </command>
      </menuContribution>
      <menuContribution
            locationURI="popup:org.eclipse.ui.popup.any?after=additions">
         <command
               commandId="com.richclientgui.myreader.commands.AnnotateEBook"
               label="Annotate"
               mnemonic="A"
               style="push">
         </command>
      </menuContribution>
   </extension>

Step 7: Change command menu-item placement.

Let's assume we are happy with the current placement.

Step 8: Implement a default Handler

Let us be lazy again and implement a very basic handler that just opens a message dialog. I will go into more detail about org.eclipse.core.commands.Handler and a future blog.

Implement a class called DefaultAnnotateEBookHandler that extends AbstractHandler, and only override the execute(...) method to call the JFace MessageDialog class to show some information.

Select the AnnotateEBookCommand definition from step 3 and select the DefaultAnnotateEBookHandler class as the defaultHandler's value.
The code for DefaultAnnotateEBookHandler looks something like this:


import org.eclipse.core.commands.AbstractHandler;
import org.eclipse.core.commands.ExecutionEvent;
import org.eclipse.core.commands.ExecutionException;
import org.eclipse.jface.dialogs.MessageDialog;
import org.eclipse.swt.widgets.Display;

public class DefaultAnnotateEBookHandler extends AbstractHandler {

  public Object execute(ExecutionEvent event) throws ExecutionException {
    MessageDialog.openInformation(Display.getDefault().getActiveShell(),
        "Annotate", "For now: write in the margins of the real book.");
    return null;
  }

}

Where's that context menu?

Those of you who have actually been entering the example code, would have found out by now that there is no context showing when running the example. Why not? Well, we have not created a context menu yet for our View. Do that, open the View class created by the New Plug-in Project Wizard in step 1 of my previous blog.
Change the code to look like this (basically adding the createContextMenu() method):


public class View extends ViewPart {
  public static final String ID = "MyReader.view";
  private TableViewer viewer;

  //other code not shown...
  
  public void createPartControl(Composite parent) {
    viewer = new TableViewer(parent, SWT.MULTI | SWT.H_SCROLL
        | SWT.V_SCROLL);
    viewer.setContentProvider(new ViewContentProvider());
    viewer.setLabelProvider(new ViewLabelProvider());
    viewer.setInput(getViewSite());
    createContextMenu();
  }
  
  private void createContextMenu(){
    final MenuManager mm = new MenuManager("view.popupmenu");
    mm.setRemoveAllWhenShown(true);
    mm.addMenuListener(new IMenuListener(){
      public void menuAboutToShow(IMenuManager manager) {
        mm.add(new Separator(IWorkbenchActionConstants.MB_ADDITIONS));
      }
    });
    final Menu menu = mm.createContextMenu(viewer.getTable());
    viewer.getTable().setMenu(menu);
    getSite().registerContextMenu(mm, viewer);
  }

If you run the MyReader application now, you should get the context menu when right-clicking in the view, proudly showing your "Annotate" item.

Feel free to download the source code for this blog's example.

Next up

Showing commands only when you want to...

References

Eclipse.org Commands Framework Article in bugzilla

Article on Eclipse Commands Framework, by Marc R. Hoffmann

Eclipse.org Wiki on Command Framework

Eclipse Commands Tutorial, by Lars Vogel

Enough said.

Eclipse RCP Commands API Part Two

2009-05-25T14:47:00.000-07:00

This is my second blog about the Eclipse Commands framework, but actually the first one containing useful (I hope) information. I'm going to focus on the topic from a practical "using it in development" point of view, trying to keep the examples as simple as possible and the theory limited. For an updated outline please refer to the first blog in the series: Eclipse RCP Commands Part One.

Short history: the Commands framework has been around partially since Eclipse 3.0, maturing over the versions until it became quite useful in Eclipse 3.3. Some refinements in Eclipse 3.4 makes it even more appealing. I must admit, before Eclipse 3.3 I saw no reason for using Commands, and I stuck to using IActions and IActionDelegates, trying to work around their issues as much as possible (and falling into the rythm of the copy-and-paste anti-pattern in order to contribute an IActionDelegate to multiple places in a UI). No I'm trying to convince all my clients to "renew" their code to use Commands...

What are Commands

"A command is neither the presentation nor a particular behavior implementation; it is an abstract representation of some semantical behavior." - Marc R. Hoffmann (see Article on Eclipse Commands Framework)

That's the best quote I could find as to what a Command is. What does it boil down to? I assume (hope?) you are all familiar with the Model-View-Controller pattern, used especially when developing UI applications. By abstracting a particular piece of functionality into separate Model, View and Controller objects, the code is must less coupled, allowing more (and easier) reuse, flexibility and extensibility.

Well, the Command design is not exactly MVC, but it has the same goals in mind. It abstracts the actual business or application semantics (i.e. what is actually meant to happen from business or application functionality perspective) into this thing called a Command. Worries about how it should appear in the UI (menu contributions), or what exactly must happen on a code implementation level to execute the command (handlers) is left for later. In this way we get the same decoupling of presentation and implementation as with MVC, and thus the gain in reusability of Commands and their handlers, and increase in the flexibility and extensibility of the code, thus leading overall to code that is much easier to maintain.

Add to the above paragraph that code that is easier to maintain leads to huge development cost savings, and you'll have a convincing argument to offer to your boss for allowing you to refactor away all the old IActionDelegates.

Ok, but what to we do with Commands?

Plain and simple: we use it to implement functions that our application can perform and make it available as menu or toolbar items so the user can invoke it.

On a more practical level

That is about enough theory for one day. Let's get down to the bits and the bytes.

The Example

Firstly, I want to introduce my patent-pending idea for an application. Image this: you have this cross-platform application (obviously implemented using Eclipse RCP) that can actually read electronic versions of books, that we can call "e-books". "Wow!" you say. "Amazing". "What a novel idea".

Let us call our bleeding edge application MyReader. You can download the source code for this blog's version of the example.

Step 1: Create a RCP application using Eclipse 3.4 (I'm using 3.4.1) and the New Plug-in Project wizard.

Name the project MyReader

On the next wizard page fill in the details you want, but make sure "Would you like to create a rich client application" is set to "Yes".

On the third wizard page, select the "RCP application with a view" as the template to use.

Run the resulting RCP application to make sure it runs, so you don't blame my examples later for messing up your pristine code.

Now we have the example application that we are going to enable with Commands. Exciting, isn't it?

How to define a Command

To have a command that is actually accessible in the UI, and able to do something, we need 3 "components":

The Intent: the Command declaration

The Presentation: the menu contribution declaration(s)

The Behaviour: the Handler that implements the behaviour of the Command

Declaring the Command (Intent)

We declare the Command using the org.eclipse.ui.commands extension point. I'm sure you remember this command we declare indicates the meaning or intent of the functionality we want to add to our application or plugin.

Let us explore this Command declaration in our example, and then I'll discuss what is going on.
We need to open an ebook file with our application, so we will define a command to do this.

Step 2: Add the org.eclipse.ui.commands extension to our plugin.xml

Open the PDE-Editor (Plugin Editor), if it is not open already, and select the Extensions tab. (You double-click the plugin.xml or MANIFEST.MF files in the project. However, if you did not know that, you must maybe first implement a "Hello RCP World" application before jumping to Commands...)

If, due to random bit-changes caused by unexplained solar activity, you already have the org.eclipse.ui.commands extension in your list of extensions, then do not follow the rest of this step.

Click on the "Add..." button.

Start typing in "org.eclipse.ui.commands", and select it from the filtered list when you see it. If it is not available uncheck the "Show only extension points from required plug-ins" option.

Select the Finish button. This will add the org.eclipse.ui.commands entry to your plugin.xml file.

Step 3: Declare the Open File command

right-click the org.eclipse.ui.commands extension, and select New -> Command from the context menu.

change the id to something like "mydomain.myreader.commands.OpenEBook"

change the name to "Open eBook"

change description to "Opens an eBook file for reading"

for now, ignore the rest

Steps 2 and 3 updates the plugin.xml file of the plugin project by adding the necessary extension point and declaring a basic command. The plugin.xml file now contains:


   <extension
         point="org.eclipse.ui.commands">
      <command
            description="Open an eBook file for reading"
            id="com.richclientgui.myreader.commands.OpenEBook"
            name="Open eBook">
      </command>
   </extension>

Congratulations! Your first command.

"But if I run my app, I don't see this command. What's wrong?" Nothing. We still need to define how this command will be visible in the UI, and what the behavior should be when this command is invoked. As mentioned earlier, these are decoupled from the Command declaration.

However, let us first examine the declaration in the plugin.xml. The org.eclipse.ui.commands extension allows us to declare, among other things, a Command. The Command definition needs the following attributes:

id	a unique id that will be used for referring to this command when declaring the UI contributions and Handlers
name	a user-readable name that will be used for the label in the menu contribution(s), if the menu contribution does not define its own label
description	a user-readable name that will be used for the tooltip in the menu contribution(s), if the contribution does not define its own description

We are still going to have a look at some of the other attributes available. If you can't wait, go and see org.eclipse.ui.commands for more detailed information about the extension point definition. Go on, don't mind me.

Note: here we had a look at how to declare commands using the extension point in the plugin.xml file. In a later blog I plan to discuss how to do it programmatically. I will update this section with a link to that blog as soon as it is available.

Basic menu contribution (Presentation)

It is time to get his command to be presented in the UI of the application. I assume you have already done some nice UI design work sessions with your potential end-users and you are ready to build the ultimate user friendly intuitive graphical user interface for your application. For our example we are just going to use the UI-design-by-coincidence approach and just add our stuff and see how it looks.

In order to contribute an item that will invoke a Command to the UI, we need to add the org.eclipse.ui.menus extension to our plugin.xml, and declare a MenuContribution element followed by a Command element.

We first declare where (i.e. the main menubar or toolbar, or a view or editor specific menu and/or toolbar, or a context menu) the command should be added via the MenuContribution. Then we declare the visual representation of our Command using the MenuContribution's Command element.

Step 4:Add the org.eclipse.ui.menus extension to plugin.xml

Click on the Add... button in the Plugin Editor.

Select the org.eclipse.ui.menus extension from the list of available extensions. If it is not available uncheck the "Show only extension points from required plug-ins" option.

Select the Finish button. This will add the org.eclipse.ui.menus extension to the plugin.xml file.

Step 5: Add the MenuContribution element

Right-click the org.eclipse.ui.menus extension, and select New -> menuContribution from the context menu

Change the locationURI to menu:file?after=additions (don't worry, we'll discuss it just now)

Step 6: Add the Command to the MenuContribution

Right-click on the menuContribution created in step 5, and select New -> command from the context menu.

Change commandId to the id you provided to your Command definition in step 3.

Change mnemonic to "O" to underline the first letter of the "Open" as your shortcut mnemonic for your command in the menu.

I'm sure you are eager to run your MyReader app now. Go ahead, please. Do you see it? A grayed-out Open eBook menu-item just underneath Exit in the File menu.

That is not quite what we intended. We'll get there, though. First a discussion on what we actually did.

We first needed to add the org.eclipse.ui.menus extension to our plugin, and then we declared that we want to contribute an item to a menu via the MenuContribution element. We only had to specify one attribute: the locationURI. More on that in the next section.

We then declared that we are actually contributing a Command item as part of our MenuContribution. This is not the actual definition of a Command, but just an element indicating that we wish to represent the command with the identifier specified in commandId as an item in the menu or toolbar that we are declaring this MenuContribution for. Thus by specifying the locationURI "menu:file?after=additions" and the commandId "com.richclientgui.myreader.commands.OpenEBook" we are saying that we want the OpenEBook command to display in the standard File menu after the additions placeholder.

The mnemonic attribute indicates what character should be underlined and act as a shortcut key for selecting the menu item, if that menu is currently open. Other additional attributes can be specified to manage the presentation of the Command in the menu, e.g. the icon, label (overriding the value set in the Command's name attribute), tooltip (overriding the value set in the Command's description attribute), etc. This gives us the flexibility to present the same Command slightly different depending on where it gets contributed, something that is not possible with IActions and IActionDelegates.

LocationURI

The locationURI is an interesting attribute: it allows the developer to use a URI string to specify where a specific contribution (whether it is a command item, a submenu or some other widget that can be contributed) must be added. It is of the form:

[scheme]:[id]?[placement arguments]

scheme	The scheme indicates the type of the target component of the contribution, and can be one of: menu : either main menu or view menu toolbar : either main toolbar or view toolbar popup : context menu
id	The unique identifier of the menu, toolbar or context (popup) menu where the contribution must be added. See the list below for standard platform identifiers that can be used.
placement	The arguments helps to define the placement of the contribution items in relation to another item or placeholder (i.e. GroupMarker) in the target menu. It consists of either the word "before" or "after" followed by an equal sign (=) and then the identifier of a menu contribution item. The word "additions" can also be used in place of an identifier. Contributions added to "additions" will typically be placed last in a menu.

Talking in detail about the locationURI and menu contribution placement can be a long blog entry on its own, so I want to come to this subject in more detail later in the series.

Note: I usually declare my view's identifier as the same as the fully qualified Java class name of the ViewPart implementation class, and then use the convention viewID.menu, viewID.toolbar and viewID.popup as identifiers for its various menus. E.g. a View implemented in the class com.richclientgui.myreader.BookView will have the Id com.richclientgui.myreader.BookView and the menu IDs com.richclientgui.myreader.BookView.menu, com.richclientgui.myreader.BookView.toolbar and com.richclientgui.myreader.BookView.popup.

Platform Menu IDs

Some standard identifiers are available for commonly used menus and toolbars:

ID	Description
org.eclipse.ui.main.menu	the main Eclipse application menubar
org.eclipse.ui.main.toolbar	the main Eclipse application toolbar
org.eclipse.ui.popup.any	contributions using this identifier will be visible in all context menus of the application (well, that's not the full truth, but that is a topic for another blog)
menu:file	three guesses what menu this one point to...
menu:help	I'm not even going to say its a menu, and you only get one guess
menu:window	Ok, you start to get the picture
helpEnd	name of group-marker at end of Help menu
quit	id of Exit action

See IIDEActionConstants and IWorkbenchActionConstants for more useful identifiers.

I can't wait to move that Open eBook item to the top of the menu...

Step 7: Change Command menu-item placement

Select the menuContribution element we specified in step 6.

Change the locationURI to be menu:file?before=quit

Running our latest version gives us a still grayed-out item, but at least where we want it.

And our plugin.xml has grown a bit:


    <extension
          point="org.eclipse.ui.commands">
       <command
             description="Open an eBook file for reading"
             id="com.richclientgui.myreader.commands.OpenEBook"
             name="Open eBook">
       </command>
    </extension>
    <extension
          point="org.eclipse.ui.menus">
       <menuContribution
             locationURI="menu:file?before=quit">
          <command
                commandId="com.richclientgui.myreader.commands.OpenEBook"
                mnemonic="O"
                style="push">
          </command>
       </menuContribution>
    </extension>

Now to implement the behaviour.

Simple Handler (Behaviour)

After all this build-up, it is quite simple to actually add behaviour to a Command. You need to

implement a class that extends org.eclipse.core.commands.AbstractHandler,

and update your Command's defaultHandler attribute that you left empty in step 3.

Step 8: Implement a default Handler

Implement a class called DefaultOpenEBookHandler that extends AbstractHandler, and only override the execute(...) method. I just added a call to the JFace MessageDialog class to show some information. I will discuss these Handler classes more in a future blog in the series.

Select the OpenEBookCommand definition from step 3 and select the DefaultOpenEBookHandler class as the defaultHandler's value.

Here is my DefaultOpenEBookHandler class:


 package com.richclientgui.myreader.handlers;
 
 import org.eclipse.core.commands.AbstractHandler;
 import org.eclipse.core.commands.ExecutionEvent;
 import org.eclipse.core.commands.ExecutionException;
 import org.eclipse.jface.dialogs.MessageDialog;
 import org.eclipse.swt.widgets.Display;
 
 public class DefaultOpenEBookHandler extends AbstractHandler {
 
   public Object execute(ExecutionEvent event) throws ExecutionException {
     MessageDialog.openInformation(Display.getDefault().getActiveShell(),
         "O no!", "I'm not ready yet. Go read the hardcopy book.");
     return null;
   }
 
 }

If you run the application now, you will actually see that the command item in the menu is enabled, and you should see a dialog with a message if you select the item.

The Sum of the Parts

We saw a basic introduction of how to:

declare a Command

contribute that command to the main menu-bar

define a class that encapsulated the behaviour of the Command

Each of these components on their own does not add value to an application, but together it forms a powerful yet flexible and very maintainable Commands framework, far superior to using IActions and IActionDelegates because of the separation between the intent, presentation and behaviour.

Summary of Steps

Step 1	Create sample RCP application
Step 2	Add the org.eclipse.ui.commands extension to our plugin.xml
Step 3	Declare the Open File command
Step 4	Add the org.eclipse.ui.menus extension to plugin.xml
Step 5	Add the MenuContribution element
Step 6	Add the Command to the MenuContribution
Step 7	Change Command menu-item placement
Step 8	Implement a default Handler

You can download the source code for this blog's version of the example.

Next Episode

Do not miss out on the next exciting episode on Eclipse RCP Commands. There I'll be tackling mind-blowing topics, like

how to show commands only when you want to

how to disable commands

dynamic menu contributions

handling the Handlers
(Time and weather permitting.)

References

Eclipse.org Commands Framework Article in bugzilla

Article on Eclipse Commands Framework, by Marc R. Hoffmann

Eclipse.org Wiki on Command Framework

Eclipse Commands Tutorial, by Lars Vogel

Enough said for now.

Eclipse RCP Commands API Part One: Outline

2009-05-21T14:05:00.000-07:00

I've been looking around on the web for information on how to use the Eclipse 3.4 Commands API (well, rather Eclipse 3.3 Commands API, 3.4 only fine-tuned it a bit), but could not find much. Since I became disillusioned with IActionDelegates and started using Commands more and more, I've also started having to explain what's going on to a number of people, so I decided to rather write a series of blogs on the topic, and maybe publish the thing as some full-fledged article some day.

So here is the outline I thought of following in my series of blogs:
(I'll update this with links to the relevant blogs as I go on.)

What are Commands?

Example Background

Defining a Command

Command

Declare Open eBook command

Adding to the UI (Menubar, toolbar or context menus)

Add to menu

Add to toolbar

Handler

Define and implement Handler

Problems with IActionDelegates and how Commands solve it

Advanced Command topics

Declaring Commands programmatically

Do show or not to show: isVisibleWhen

Using Core Expressions

propertyTester

Setting visibility programmatically

Enablement of Commands

Declaratively

Programmatically

Dynamic Menu contributions

Binding to keystrokes

CommandParameters

I'll be going as fast as (available) time allows to complete these various topics around Commands, and the outline will probably change as I go, but hey, that's what being Agile is all about. You are of course extremely welcome to give input as to what information you would like to see, or even provide valuable insight into the topic.

In the end I want to capture all of this in a proper article (must still decide between using LaTeX or Docbook with TextMate...), if there is enough interest. Please indicate with a comment or a tweet if you're interested in a full article.

Enough said for now.

The Tools I Use

2009-05-19T12:08:00.001-07:00

I started this entry on my mobile phone, as a way of testing a new modile blogging app. Might increase my blogging frequency. Hmmm, perhaps not.

Posted with LifeCast

SWT Table performance

2008-07-22T11:53:00.001-07:00

I recently discovered a extremely tuned custom SWT Table widget called NatTable. It is very good at handling large data sets, much better than even the latest Eclipse 3.4 version of the normal SWT Table widget.

To give you some indication, I created a Eclipse RCP application that has two views, each loading the same 1 million domain objects (a simple POJO with some 15 properties, of which only 6 gets displayed in the table as columns) into a normal SWT Table and a NatTable respectively.

Performance

The difference in performance (over multiple runs) is mind-blowing:

SWT Table took on average 57 seconds to load these entries and display the table. And that was with only one column and no column header displayed. (I decided to keep the SWT table as simple as possible, as I was trying out NatTable's API).

NatTable took on average 4,5 seconds to load. Yes, four-and-a-half seconds!. That is less than a tenth of the time it took for the SWT Table. And in the NatTable view I had 6 columns, with alternating row colours. In addition the NatTable's columns were all movable and had a custom column-header renderer.

Memory Usage

It does not stop at performance. I also tested the app's memory usage (loading only a single View at a time) . After doing a System.gc(), the app with only the normal SWT Table widget in a View (loaded with 1 million entries) was using on average 430Mb of memory.

The NatTable version was using only 300Mb of memory.

I'm busy moving my implementation over to using NatTable... will you?

Adding Eclipse SWT input validation the easy way

2008-07-19T15:11:00.000-07:00

Any input provided by a user in a GUI application must typically be validated in ne way or another. There is a number of ways this gets done, while some applications have just ignored the matter alltogether.

When crafting an Eclipse RCP application, there are some help provided by SWT and JFace. We can add ModifyListeners and VerifyListeners to certain SWT widgets. JFace also provides ControlDecorations to help us indicate to the user where a problem with a specific input value exists.

The problem is that these are at a low level, and we need to do a lot of "monkey"-coding just to add basic validation and error indication to a widget, and then we're not even touching the world of input masks. If you're like me, you want to concentrate on solving your business problem, and don't want to write lots of basic UI code over and over.

This is where the RCP Toolbox is very useful. It provides a light-weight validation framework (among other features) that makes it much easier to add validation and input masks to SWT Text, Combo and CCombo widgets.

The goal

Let us have a look at how to define a basic wizard for creating a new Booking. This wizard must capture the following fields from the user:

Name: the name of the booking, typically the name of the person making the booking. May not be empty, and preferably not less than three characters.

Date: the date and time of the booking. Must be any time from the current time to the end of the year.

Number of Persons: the number of persons to book for. Must be a number from 1 to 10.

Telephone Number: the telephone number of the person making the booking. Must be in the form +(country code) (area code) number, e.g. +44 (33) 555-1111.

And of course we want indicators next to each field when an error or warning condition exists in the field, as well as a message being written to the WizardDialog's message area. For fun we want the user to be able to get a quick-fix option on the date field for setting it to the current time.

The Validation framework

The RCP Toolbox provides a number of custom widgets and a easy to use validation framework. Adding validation starts with the ValidationToolkit class. This class gets instantiated to work with a specific type of contents, and is then used to create ValidatingField instances that can handle that type of contents.

The rest of the framework deals with interfaces and default implementations to facilitate the validation of contents, definition of input masks, provision of quick-fixes, error-handling and conversion of the input text to specific class types.

The WizardPage and the ValidationToolkits

We start by first defining our BookingWizardPage class and instantiating the necessary ValidationToolkit instances.


//Not all imports are shown
import com.richclientgui.toolbox.validation.IFieldErrorMessageHandler;
import com.richclientgui.toolbox.validation.ValidationToolkit;
import com.richclientgui.toolbox.validation.converter.DateStringConverter;
import com.richclientgui.toolbox.validation.converter.IntegerStringConverter;
import com.richclientgui.toolbox.validation.string.StringValidationToolkit;

public class BookingWizardPage extends WizardPage {
private static final int DECORATOR_POSITION = SWT.TOP | SWT.LEFT;
private static final int DECORATOR_MARGIN_WIDTH = 1;
private static final int DEFAULT_WIDTH_HINT = 150;

private StringValidationToolkit strValToolkit = null;
private ValidationToolkit dateValToolkit = null;
private ValidationToolkit intValToolkit = null;

private final IFieldErrorMessageHandler errorMessageHandler;

public BookingWizardPage() {
super("booking.pageone","New Booking Entry", null);
errorMessageHandler = new WizardPageErrorHandler();
}

public void createControl(Composite parent) {
final Composite composite = new Composite(parent, SWT.NONE);
composite.setLayout(new GridLayout(2, false));

strValToolkit = new StringValidationToolkit(DECORATOR_POSITION,
    DECORATOR_MARGIN_WIDTH, true);
strValToolkit.setDefaultErrorMessageHandler(errorMessageHandler);

intValToolkit = new ValidationToolkit(new IntegerStringConverter(),
    DECORATOR_POSITION, DECORATOR_MARGIN_WIDTH, true);
intValToolkit.setDefaultErrorMessageHandler(errorMessageHandler);

dateValToolkit = new ValidationToolkit(new DateStringConverter(),
    DECORATOR_POSITION, DECORATOR_MARGIN_WIDTH, true);
dateValToolkit.setDefaultErrorMessageHandler(errorMessageHandler);

//TODO: create ValidatingFields
setControl(composite);
}
}

The StringValidationToolkit class we instantiate in line 28 is a ValidationToolkit that deals specifically with ValidatingFields that
have normal String contents. In line 32 we instantiate a typed instance of ValidationToolkit that will create ValidatingFields that only
takes Integers as input.

We must provide a way that the contents of the fields are converted from a String to the correct content type. This is done with a set of converter classes
provided by the framework. Custom converters can easily be implemented as well. In lines 32 and 36 we specify a IntegerStringConverter and a DateStringConverter to convert Integer and java.util.Date values respectively.

The framework makes use of the JFace org.eclipse.jface.fieldassist.ControlDecoration and related classes to indicate whether a field has an error or warning condition, whether it is a required field, and if there is a quick-fix available (by right-clicking on the decorator icon) for the current error or warning condition. The position of these decorator icons relative to the input widgets as well as the margin width between the decorator icon and the widget can be specified when constructing a ValidationToolkit. All the fields created by this ValidationToolkit instance will use the same settings for their decorator icons. In lines 9 - 10 we have defined some constants for the decorator position and margins, and we use this for constructing all the ValidationToolkit instances.

Handling the error messages

We also make use of an IFieldErrorMessageHandler to get feedback from the validation process. The validation framework will call these error handlers when error or warning conditions occur, and allow us to do something with those messages. By default these messages are only displayed in the tooltips of the decorator icons. A
default error handler can be specified for each toolkit instance, or a separate handler can be set for each ValidatingField if so required.

The inner class WizardPageErrorHandler implements the IFieldErrorMessageHandler interface and basically just set the messages on the WizardPage's message area.


//inner class of BookingWizardPage
class WizardPageErrorHandler implements IFieldErrorMessageHandler {

public void handleErrorMessage(String message, String input) {
setMessage(null, DialogPage.WARNING);
setErrorMessage(message);
}

public void handleWarningMessage(String message, String input) {
setErrorMessage(null);
setMessage(message, DialogPage.WARNING);
}

public void clearMessage() {
setErrorMessage(null);
setMessage(null, DialogPage.WARNING);
}
}

The actual error or warning messages are generated by the various IFieldValidator implementations (we'll get to those), and can easily be customized by implementing custom validators.

Creating a simple ValidatingField

Of course just having some toolkit instances does not help us much. We need actual input widgets that are being validated. The first step is to update the createControl method of the wizard-page by adding lines 17 - 20 below.


public void createControl(Composite parent) {
final Composite composite = new Composite(parent, SWT.NONE);
composite.setLayout(new GridLayout(2, false));

strValToolkit = new StringValidationToolkit(DECORATOR_POSITION,
    DECORATOR_MARGIN_WIDTH, true);
strValToolkit.setDefaultErrorMessageHandler(errorMessageHandler);

intValToolkit = new ValidationToolkit(new IntegerStringConverter(),
    DECORATOR_POSITION, DECORATOR_MARGIN_WIDTH, true);
intValToolkit.setDefaultErrorMessageHandler(errorMessageHandler);

dateValToolkit = new ValidationToolkit(new DateStringConverter(),
    DECORATOR_POSITION, DECORATOR_MARGIN_WIDTH, true);
dateValToolkit.setDefaultErrorMessageHandler(errorMessageHandler);

createNameField(composite);
createDateField(composite);
createNumberPersonsField(composite);
createTelephoneNumberField(composite);

setControl(composite);
}

Then we can look at creating our first validated input field that makes use of a SWT Text widget to capture the name of the person doing the booking.


private void createNameField(Composite composite) {
new Label(composite, SWT.NONE).setText("Booking Name:");

final ValidatingField nameField = strValToolkit.createTextField(
composite, new IFieldValidator(){

 public String getErrorMessage() {
  return "Name may not be empty.";
 }

 public String getWarningMessage() {
  return "That's a very short name...";
 }

 public boolean isValid(String contents) {
  return !(contents.length()==0);
 }

    public boolean warningExist(String contents) {
     return contents.length() < 3;
    }
 
   }, true, "");
 GridData gd = new GridData(SWT.LEFT, SWT.CENTER, false, false);
 gd.widthHint = DEFAULT_WIDTH_HINT;
 nameField.getControl().setLayoutData(gd);
}

Since this field works with String contents, we make use of the strValToolkit instance to create the field in line 4 above.
We specify the parent composite that the input widget must be added to, the IFieldValidator that will be used to validate the field contents, whether this is a required field or not (thus whether the required decorator icon must be shown or not) and an initial empty string value for the field. Note that this call will also create a Text widget to be used for the field, but the API allows that you can create your own Text, Combo or CCombo instance and pass that to the toolkit to use when creating a new ValidatingField.

An anonymous inner class implementation of IFieldValidator is specified in lines 5 - 23. We're doing some very basic validation checks in this example, but
it is easy to implement validators that makes use of other heavy-weight business validation frameworks. Our validator will indicate an error condition if the contents of the field is empty (line 16), in which case the error message "Name may not be empty." will be displayed (line 8). This validator will also indicate a
warning condition if the name field contains less than 3 characters (line 20) with the message "That's a very short name..." (line 12).

In lines 24 - 26 we set the layout of the input widget on the composite.

Dating an input mask

Dates have always been a difficult input type to deal with. The easiest way for us developers to deal with them are to use widgets that pop up a calendar from where the user can choose a day, and possibly a time as well. However, this way of dealing with dates are not always a favourite with touch-typing end-users. They prefer some masked field where they only need to fill in the bits of the date that matter. Using the mouse should be restricted as far as possible. Luckily the RCP Toolbox provides a way of specifying input masks, as well as specific implementations of validators and converters for dealing with Dates.

We want to create a field that only takes dates as input, where the date entered must be of the form yyyy-MM-dd HH:mm (e.g 2008-07-19 21:00), and fall in the date range starting at the current time and ending at the end of the year 2008.


private void createDateField(Composite composite) {
new Label(composite, SWT.NONE).setText("Booking Time:");

final Date endYear = getEndYearDate();
//we create a Date field that takes input of form yyyy-MM-dd HH:mm
//and only allows values from now till the end of the year
final ValidatingField rangedDateField
= dateValToolkit.createTextField(composite,
new RangedDateFieldValidator(
  DateFieldValidator.DATE_TIME_HHMM_DASH,
  dateValToolkit.getStringConverter(),
  new Date(), endYear),
  true,
  new Date());
GridData gd = new GridData(SWT.LEFT, SWT.CENTER, false, false);
gd.widthHint = DEFAULT_WIDTH_HINT;
rangedDateField.getControl().setLayoutData(gd);
}

Here we used the dateValToolkit instance to create the field as the contents of the field must be a java.util.Date. We specify an instance of RangedDateFieldValidator (provided by the framework) that makes use of the specified Date input mask pattern DateFieldValidator.DATE_TIME_HHMM_DASH (line 9) to validate the contents of the field. Other patterns are available, or custom ones can also be defined. The DateStringConverter specified when dateValToolkit was constructed will be used to convert from Dates to Strings and vice versa.

In line 11 we specify the valid date range for the field, from the current date and time to the end of the year, and in line 13 we set the initial
value of the field to the current time.

Providing quick-fixes

I found that developers using Eclipse RCP to develop their applications like to make the experience for the end-user as good as possible. So we should not stop at just
validating input; we must also try and help them quickly fix mistakes, where possible. In this example we can do that by specifying a IQuickFixProvider.


//add at end of createDateField(..) method
//we add a quickfix that will set it to the current date
rangedDateField.setQuickFixProvider(new IQuickFixProvider(){

public boolean doQuickFix(ValidatingField field) {
field.setContents(new Date());
return true;
}

public String getQuickFixMenuText() {
return "Set to current time";
}

public boolean hasQuickFix(Date contents) {
//would typically first check contents to determine if quickfix
//is possible
return true;
}
});

The above is a very simple quick-fixer. It always says it has a quick-fix available (line 17), where a more complex provider will first check the contents of the field to determine if there is a quick-fix. When the user performs the quick-fix, it just sets the contents of the field to the current date and time (line 6).

When the validation framework detects there is an error condition on a field, it will see if there is a IQuickFixProvider available with a quick-fix. If this is the case, it will add the quick-fix option to a context-menu on the decorator icon with the text specified in line 11. All the user then needs to do is right-click on the decorator icon and select the quick-fix to perform.

Validating Combos

A Combo widget would be just the thing to use for capturing the number of persons for the booking. Our requirements say we must limit the number to a maximum of 10 people (and a minimum of 1 goes without saying). Once again we do not want to force the user to use numerous mouse-clicks or keystrokes to select the number, so we do not make the Combo read-only, and rather decide to add validation to it.


private void createNumberPersonsField(Composite composite) {
new Label(composite, SWT.NONE).setText("Number of persons:");

final ValidatingField numberPersonsField
= intValToolkit.createComboField(
  composite, new StrictRangedNumberFieldValidator(1, 10){
   public String getErrorMessage() {
    return "Bookings for groups bigger than 10 not allowed";
   }

   public String getWarningMessage() {
    return null;
   }

   public boolean warningExist(Integer contents) {
    return false;
   }

  },
  true,
  2,
  new Integer[]{1,2,3,4,5,6,7,8,9,10});
GridData gd = new GridData(SWT.LEFT, SWT.CENTER, false, false);
gd.widthHint = DEFAULT_WIDTH_HINT;
numberPersonsField.getControl().setLayoutData(gd);
}

Here we make use of the intValToolkit.createComboField method to create a field containing a Combo widget with contents of type Integer. We specify
a StrictRangedNumberFieldValidator (line 6) to ensure that the entered value only consists of digits and falls in the range 1 to 10. No warning conditions are checked. In line 22 we populate the Combo with a list of Integers from 1 to 10, and in line 21 we select a default value of 2. As easy as counting to 5.

And don't forget the telephone number

Freeform telephone number fields are used a lot, but unfortunately end-users can easily make mistakes in such fields. We want to force our user to input the telephone number in a specific form, thus at least preventing the cases where digits are missed. To do this, we make use of the framework's TelephoneNumberValidator. This validator allows telephone number to be entered in either international format (e.g. +44 (55) 555-5555) or in domestic format (e.g. (055) 555-5555).


private void createTelephoneNumberField(Composite composite) {
new Label(composite, SWT.NONE).setText("Contact Telephone Nr:");

final ValidatingField telephoneField
= strValToolkit.createTextField(
  composite,
  new TelephoneNumberValidator(true),
  true,
  "+44 (55) 555-4321");

GridData gd = new GridData(SWT.LEFT, SWT.CENTER, false, false);
gd.widthHint = DEFAULT_WIDTH_HINT;
telephoneField.getControl().setLayoutData(gd);
}

We are using strValToolkit to create the field, since the contents will be managed as a String. Then we specify a TelephoneNumberValidator as the validator
in line 7, with the true parameter indicating that we want to use the international format. In line 9 we provide an initial value.

Conclusion

This article describes a very simple example of how to add validation to SWT widgets using the RCP Toolbox. In a real-world application the actual business validations to be done might be more complex, but if this validation framework is used, the UI code related to validation would remain as simple as the code in these examples.

This validation framework really made our development much easier, allowing us to concentrate on the business code. It is very easy to extend the framework with custom
validators, converters, quick-fix providers and error handlers that ties into existing business code or other validation code, rules engines etc.

Note that the examples in this article need Eclipse RCP 3.3 or 3.4 as well as RCP Toolbox v1.0.1, created and distributed by
www.richclientgui.com.

RCP Toolbox 1.0 Released!

2008-07-03T02:35:00.000-07:00

I've been using Eclipse RCP for a number of years now, since version 2.1. In this time I've found that I needed to provide some customization of certain widgets or add validation to input fields quite a number of times.

So I thought one day to take these typical custom widgets and validation classes and combine them into a package. I got some other people to help, and we incubated what we decided to call the 'RCP Toolbox' in Sourceforge.

Then we added more features, including a lightweight Validation framework, Developer's Guide, and of course free technical support and released a commercial version yesterday.

So I'm very proud to announce the release of RCP Toolbox 1.0 on this blog.
Please visit our product page for more information on the toolbox.

And I hope you'll forgive me for this announcement in my blog... but I had to share it with someone :-)

Best Java environment ever... until...

2008-05-17T13:18:00.000-07:00

I converted about a year ago. First there was Windows (I knew no better), then there was Linux (happy student years) and then again Windows (the employer's choice).

Then a year ago I converted to a Macbook Pro (It helps to have one's own company). This is indeed the nicest machine and OS I've ever done Java development on. I was so happily coding away, using the Eclipse IDE and Leopard's built-in Subversion for version control.

That is, until a project at one of my clients went over to Java 6.

So I went to Apple and downloaded the latest Apple 64bit JDK (Java 1.6.0_05). This would have worked, but... guess what? The Mac OS X SWT (see Eclipse) is not supported by the new Apple Java 6 JDK, as SWT is based on Carbon native code, and the 64bit Java 6 JDK only supports Cocoa... [Anyone with tips on how to run Eclipse RCP apps - including the Eclipse IDE - with the Java 6 VM, please contact me.]

So what to I do? For non-SWT code everything is fine. For SWT code: I code blindly on the Mac side of things, check in to svn, fire up Parallels with a Windows VM, get from svn, compile it in the VM's Eclipse and run. Ultimately non-efficient, yes. I do find though that this way of working has dramatically improved my ability to visualise a GUI by looking at the code :-)

And the NextStep? Starting to learn the NextSTEP-based Cocoa Framework (what I've seen up to now: Awesome!) so that I can perhaps give a hand with porting SWT on the Mac from Carbon to Cocoa (as Apple does not seem that keen on having Java 6 support Carbon...)