Boris Bokowski

Adventures into web UI land

2009-10-25T06:00:00.000-05:00

To explore how easy or hard it would be to write a UI component using web technologies, and then integrate it as a first class citizen in Eclipse, I reimplemented the PDE "site.xml" editor for the 0.9 release of e4, using HTML, JavaScript, Dojo, and CSS.

I thought it would be interesting to document the design decisions that I made for this. Since my experience with web UIs is somewhat limited, you should take the following with a grain of salt. I did, however, work on something that could be characterized as an "IDE in a browser" for over three years (2001-2004), so I don't consider myself a complete rookie. :-)

Note that I won't talk about integrating the web UI component into Eclipse, this posting is just about the actual web UI component itself. The Eclipse integration is a related, but different story, that deserves its own post.

Let's start with a screenshot of the original PDE editor. It has two panes, a tree on the left showing features and categories, and a bunch of fields on the right with which you can edit the currently selected object in the tree. Depending on the type of object, the right side shows different fields, for example feature environments if the selected object is a feature, or category ID, name, and description if the selected object is a category. To add new categories or features, there are some push buttons on the right side of the tree.

We should be able to achieve a very similar look and feel with a piece of web UI, after all, the "flat look" of the PDE editors was an attempt to mimic the look of a web page.

The first important decision I had to make was whether to generate the HTML, pre-filled with the data, on the server side. This has the advantage that the resulting HTML can be made to (somewhat) work even if the web browser displaying it has JavaScript disabled. You would probably use a server-side template engine for this. If you follow the link, you can see one of the disadvantages of this approach - there are a bajillion template engines to choose from. Good luck with deciding which one! ;-)

But seriously, I had other reasons for deciding to let client-side JavaScript fill in the data instead. For example, this approach scales better because the "filling in data" work is done on the client, with the server doing less work because it only serves raw data. Also, it makes it easier to handle dynamic changes to the data on the client side because there is only one way of turning data into populated widgets. Development and testing is easier because you avoid a complete layer of the cake - you don't need to restart the template engine or reload the template every time you make a change, instead you change the .html or .js file and reload the page in the browser. Finally, this approach quite naturally leads to an interface between client and server that could be used by other kinds of clients as well (you get an API if you decide to publish and maintain it).

Oh and I forgot, it wouldn't be buzzword compliant - to claim you're doing Ajax means that you have to use JavaScript and XMLHttpRequest, and to be RESTful means that the server should serve raw data.

I started with the HTML and CSS first, leaving the client-server communication for later. My first goal was to get the right kind of "look". Many things are easy to do in plain HTML, for example input fields and buttons, and the header area that says "Update Site Map". There were two things that are hard (or maybe impossible) with plain HTML: making the two panes resizable by the user, and displaying a tree of objects. I decided to use Dojo for these two things, because I had a little previous experience with Dojo, and because it had been IP-approved for use by Eclipse projects. Note that I didn't use Dojo widgets for buttons and text fields, mostly because I didn't like their Dojo-styled look and wanted the "plain" look that you get from plain buttons and plain text fields.

For the resizable panes with a draggable splitter between them, I was able to use a Dojo BorderContainer, which is configured like this:

<div dojotype="dijit.layout.BorderContainer" design="sidebar"
   livesplitters="false" gutters="false"
   style="width: 100%; height: 90%;">

The tree is created dynamically from JavaScript as follows:

myTree = new dijit.Tree({
  id: "myTree",
  model: model,
  showRoot: false,
  getLabel: function(item) { /* code to return the label... */ },
  getIconClass: function(item, opened){
     /* code returning a CSS class for the icon */
  },
  onClick: function(item,treeNode) { /* ... */ }
});
myTree.startup();
dojo.byId("tree").appendChild(myTree.domNode);

This creates a tree widget based on the model you are passing in, and puts it under the DOM node with the ID "tree". Of course, there is more code than what I am showing here, but I hope that the few snippets I am showing give you enough context to understand the rest.

I initially ignored the server part completely and just hard-code some example data right in the JavaScript. This allowed me to rapidly test and develop the web UI in a browser. Actually, make that "in all the browsers I cared about". During development, I kept Firefox, IE, and Safari open to make sure it worked in all of them. Some of the things you'd like to do in CSS, in particular with respect to layout, don't work quite the same in all the browsers. :-)

Here is the result, opened in a standalone web browser:

My next decision was about the client-server communication. I decided to use JSON as the data transfer format, because, as you all probably know already, "JSON has become the X in Ajax" (quote: Douglas Crockford). There was a more pragmatic reason, too: the version of Dojo that I used was a bit older and didn't support trees backed by XML data. With a little help from Dojo, you can make HTTP requests without having to worry about browser differences.

There is only one thing that is not obvious: if the web UI is in a file like "site-editor.html" that references the necessary CSS and JavaScript pieces, then how does it know its "input", i.e. which resource to operate on? Somehow, the web UI needs to get to know the full path to the site.xml file. One widely used approach for solving this problem is to (mis-)use the "anchor" part of the URL that the browser points at. So for example, if the browser's URL is http://localhost:9234/pde-webui/site-editor.html#/myproject/site.xml then it will request /pde-webui/site-editor.html from localhost:9234, followed by an attempt to find the anchor named /myproject/site.xml in the HTML. Even though it won't find this anchor, the document.location object will contain the full information. This means that our JavaScript code can just get the value of document.location.hash and then make a corresponding XMLHttpRequest to get data from the server, which it then uses to fill the widgets. Once you know about this technique (which by the way has some nice properties with respect to the back button and the browser history), you will start to notice its use in many existing and widely used web-based applications. Like for example, https://mail.google.com/mail/#inbox, or http://www.facebook.com/home.php#/bokowski?ref=profile :-)

By now, if you are still following, we have a client-side web UI consisting of some HTML, CSS and JavaScript, that will access a server over HTTP to get the data that needs to be displayed. Let's now focus on the server part.

Obviously, we need a place to serve our static .html, .css, and .js files. The canonical choice for this is to configure Jetty accordingly. I am instantiating my own instance of Jetty and instruct it to pick a port number for me. If I know that the web UI will only be accessed from the local machine, Jetty can be configured to only accept connections from localhost.

For the RESTful interface, I implemented a servlet that

responds to a GET request with the data I need in JSON format, and that
accepts PUT requests when the user wants to save changed data.

In reality, the servlet does a little more (like e.g. authentication), but this post is already pretty long and I need to gloss over some of the details to not bore everyone to death.

Let me just add one more thing - how did I implement the part of the servlet that converts the site.xml file into the JSON format I needed?

The most obvious approach would be to parse the XML as a DOM and then generate JSON based on that DOM. Instead, I decided to use EMF objects as an intermediate "format". My idea was that by using EMF, the example code could easily be adapted to any data model that's already EMF based, and XML files (assuming they have an XML schema) could then be considered a special case.

If you have an XML schema, you can let EMF create an .ecore file for you (using the New EMF Project wizard). For my use case, I chose to not generate any Java code from the .ecore file, because the code that generates JSON works on any EMF model, using generic EMF calls. This means that it should be very easy to change the schema, or even to use the same code for completely different models.

Just to be clear, if you know that the format of your XML never changes, or if you want to minimize the external dependencies of your code, or if you enjoy programming against the DOM API ;-), or if adding EMF as another "layer" disturbs you, it's perfectly fine to not use EMF. Maybe it would even make sense to use XML on the client side as well.

Overall, I was pretty happy with the structure that I came up with and think that it can serve as an example of how to approach the task of writing a web UI component. And now I'm looking forward to your comments, especially ones that explain how I could have made better decisions!

JSR 330 (Dependency Injection for Java) passed!

2009-10-15T11:47:00.004-05:00

Two days ago, JSR 330 passed its final vote, and we now have a standard way to annotate Java classes for dependency injection. Thanks to the spec lead Bob Lee, the JSR 330 expert group did its work in record time, in the open, and under one of the most permissive licenses.

Because of the transparency of the expert group work, it is no secret that I am representing IBM in that group. I even implemented the spec in order to understand it better, and made that implementation available as open source in the context of the e4 project, which is the place where Eclipse Platform folks can experiment with new technologies. (Btw, I intend to put javax.inject in Orbit for use by other Eclipse projects.)

I am happy with the current state of JSR 330 and am looking forward to working with the expert group on a planned maintenance draft that will define a portable configuration API. Because with such an API, it will be possible to reuse application code across different injector implementations.

Note that postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions. Similarly, IBM's votes on JSRs don't necessarily represent my personal positions, strategies, or opinions. ;-)

Embedding web UI components in Eclipse using e4

2009-09-25T14:33:00.000-05:00

The demand for software that can be accessed through a web UI is increasing. We already expect software for occasional use (e.g. online shopping, banking, filling out forms, ...) to be accessible from a browser, without having to install anything locally. Over the last few years, more and more producticity applications (email, documents, spreadsheets, etc.) have become available through browsers as well. It is only a question of time until software development tools (at least for a certain class of uses) will have to have a web UI as well. In fact, a few browser-based IDEs already exist, such as Mozilla's Bespin project, and a very recent example: embed, a special-purpose IDE for embedded development.

At the same time, locally installed "rich client" applications, especially software development tools, aren't going to go away soon - there is a huge investment in the tools we have today, and I don't expect that all of this will be reimplemented using other technology just because web UIs are now the cool new thing to do.

So the obvious question is, how can we, the Eclipse community, prepare ourselves for the trend towards the web, while keeping our desktop users happy?

One approach is to keep the current programming model and just "make the stuff run in a browser". Fundamentally, this is very hard because the existing code we have today is not written with a client-server separation in mind. To a certain extent, it can be made to work though, and we have two examples of this at Eclipse, in form of the RAP project, and the experimental "SWT Browser Edition".

The basic idea behind RAP is to place all application and UI logic on the server, including all widgets and their state, and to render those widgets on the client in a web browser while sending user events back to the server. However, there are a couple of characteristics of RAP that limit its applicability: For example, the "stuff" you run in a browser will be a complete application as opposed to individual UI components, high-latency situations are problematic, and you cannot run application code on the client side. (I hope the RAP team will let me know in the comments if I got any of this wrong.)

The work on SWT BE "browser edition" is another take at the same problem, taking, if you will, the opposite approach: Client code (application and UI logic) makes use of the SWT API and as such can run in a desktop situation just fine. For "making it run in a browser", all the code is cross-compiled - to JavaScript for the Dojo port of SWT, or to ActionScript for the Flex port of SWT. So in a nutshell, instead of placing all application code on the server as with RAP, all application code ends up running on the client, in a browser. The obvious problem with this approach is that you still need code that runs on the server, to at least send data to the client and to receive updated data from the client, and that more often than not, you will end up with too much code on the client for execution. Of course, you could rewrite your existing code and ensure a proper client-server split, but if you are rewriting it anyway, why not go all the way and rewrite it using HTML and JavaScript?

For the e4 0.9 release, we have done the first step of exactly that - we rewrote or "cloned" an existing component using HTML, CSS, JavaScript, and Dojo on the client side. The idea is to gradually move certain components (not complete applications) over to use web technology, while still having these components appear in the desktop Eclipse client as first-class citizens. As a first example, we chose the PDE site.xml editor, because of its relative simplicity but also because it is a good representative of a whole class of form-based UI components in Eclipse. We wanted the end result to run in a regular browser, as well as an editor inside of Eclipse. Here you can see it running stand alone in a browser:

To make the editor work in a regular browser, it had to have a "real" server-side counterpart. Luckily, Eclipse already ships with an embedded servlet container, Jetty. This means that the web UI editor could talk to a servlet running in the same VM as the embedded browser widget rendering the UI. This is not unheard of at all - the Eclipse help system is taking the exact same approach.

However, just presenting the unchanged web UI in an embedded SWT browser widget - backed by IE if you run Windows, Firefox on Linux, and Safari on the Mac - is not enough. The editor would only be a first-class citizen in the Eclipse UI if, for example:

you didn't have to authenticate to the web UI every time you open an editor,
the editor signaled unsaved changes through the usual "*" in the editor tab, as opposed to an indicator in the editor itself,
you can trigger saving your changes using the menu (File>Save ),
etc.

In other words, the editor needs to make use of appropriate Eclipse APIs that connect Eclipse UI components such as views and editors to their context: the Eclipse workbench. One of the goals of e4 has always been to simplify the core APIs, and to make them accessible from other programming languages. So in a sense, we have started to make this real by offering JavaScript APIs that can be called by web UI components: to signal that they have unsaved changes, to provide a callback that will save those changes, etc.

Give it a try! After downloading the e4 0.9 SDK, start it up with an empty workspace and create an update site project (Ctrl+3, 'nusp'). Add some features and categories to it using the regular PDE site.xml editor, save, and then right-click on the site.xml file and use "Open With" to open it with the web-based editor. It will look like this:

Please leave comments if you have any questions. I will try to write up more about this in the next couple of days, going into more technical detail.

API compatibility matters

2009-09-24T11:35:00.005-05:00

A few weeks ago, Palm has released an SDK called "Mojo" for their WebOS. They also offer Eclipse plug-ins that have been developed for and tested with Eclipse 3.4.2. I just read a short review of this Eclipse-based tooling and was happy to see the following:

The WebOS plug-in is supposed to officially work with Version 3.4.2 of Eclipse (code-named Ganymede). However, I was able to successfully run it on Version 3.5 of Eclipse (code-named Galileo) without any problems.

It makes me happy to see real-world reports like this. They confirm that you can run plug-ins developed for older versions of Eclipse on more current versions. In the Eclipse community, we almost take this for granted and sometimes tend forget the effort involved in pulling this off. Because when you think about it, compatibility is only achieved when both sides do a good job of enabling compatibility:

On the Eclipse SDK side, we tend to think that we are doing good job of ensuring API compatibility between Eclipse releases, so that you can run older plug-ins on newer versions of Eclipse. Since Eclipse 1.0 (2001), we've had excellent rules in places around API compatibility, and if you want to read more I'd recommend you start at our "API Central" wiki page. More recently, we've automated a lot of the necessary compatibility checking in form of API tooling that ships with the Eclipse SDK. I haven't seen anything like it for other languages or environment yet, but would like to hear if similar tooling exists elsewhere. C#? ActionScript? Let me know in the comments!
On the Palm Mojo side, the developers must have done a good job of only using documented APIs, and abiding by the contracts for those APIs. Because if you don't, all bets are off.

Here is a quote from the 2001 article "How to use the Eclipse API" by Jim des Rivieres, a recommended read for anyone developing Eclipse plug-ins:

As the Eclipse platform matures and evolves, it will be the API contracts that guide how this evolution happens. Outside of these contracts, everything is unsupported and subject to change, without notice, and at any time [...]. Client code that oversteps the above rules might fail on different versions and patch levels of the platform; or when run on different underlying OSes; or when run with a different mix of co-resident plug-ins; or when run with a different workbench perspective; and so on. [...] To those who choose to ignore the rules, don't say that you weren't warned. And don't expect much more than a sympathetic "Told you so."

Of course, in reality, life is never as easy and black-and-white as software developers would like it to be. Sometimes, the existing API doesn't work for your particular case, or there is no supported API at all. In these cases, however, you need to realize that by calling internals, you are assuming technical debt. The idea behind this metaphor, created by Ward Cunningham, is that you have taken a shortcut and need to pay up later, either in form of interest payments or paying back the principal. In concrete terms: Whenever a new version of the plug-ins you depend on comes out, you have the cost of testing that your code still works, and the cost of adapting to any change that may have broken your code. This is a recurring cost, hence the term "interest". If you want your code to run against both older and newer versions of your dependencies, the interest payments are much greater, because the problem is much harder. Often, you will need to use Java reflection to guard your calls to internals. Alternatively, you can pay back the "principal" at a later point in time, when the necessary API has been added, and get rid of your debt. You did file an enhancement request to get that API added, didn't you? Because if you don't, you'll be bound to pay interest forever!

Every now and then, I encounter people who are hoping to get away without paying either interest or principal. And that's after our collective experience with how schemes based on trading debts can take the whole economy down! :-)

Thank you!

2009-03-20T16:11:00.005-05:00

I am looking forward to attending my first Eclipse Board meeting on Monday. This first time, I will be a guest since my term of office starts in April. Unfortunately, I can only attend the second half because I am co-presenting a tutorial in the morning. Sorry about that, it won't happen again. ;-)

Thanks to all who voted!

RCP Mail 2.0

2009-03-19T19:59:00.003-05:00

Come to our EclipseCon 2009 tutorial (Monday March 23, 8:00 - 12:00) if you would like to learn about best practices for data binding, commands/handlers/contributions, and the common navigator. Bring your laptop with a copy of Eclipse SDK 3.5 M6 for the hands-on excercises!

Three RCP practitioners, and three Platform UI committers for a total of six people will help you understand and build RCP Mail 2.0. Should be fun!

2009 Eclipse Board of Directors

2009-02-23T16:10:00.001-05:00

You have probably seen Mike's email - the elections for committer representatives for the Eclipse Board of Directors is now open.

Rather than explaining why you should vote for me :-), I thought it would be useful to summarize the key election facts:

You are voting for a one-year term starting April 2009. Voting is open as of today, for three weeks until March 13, 3 pm Eastern time. Check out the committer candidates and their vision statements.
To vote, check the email you received from emo@eclipse.org on Feb 20, 2009. It contains the URL for voting, as well as the required voting password.
The Board will have 24 directors, as follows:
- Sixteen directors for the strategic members, one seat per member.
- Four directors from "sustaining members". There are nine candidates, and sustaining members (companies) get to vote. This is the old "add-in providers" category but generalized to include "enterprise members" in the future.
- Four directors representing the committers. There are six committer candidates.
Each committer has one vote. Here are some important details:
- Committers who are employed by a member company can go ahead and vote. Note though that all votes from one company will be collapsed into a single vote.
- Individual committers, if they have not done so yet, must sign a membership agreement in order to be able to vote. To understand why this is required, read this page, then read this page to make sure you fill out the form correctly. No voting privileges without signing the form!
In previous years, turnout was pretty low - for example in 2008, only 148 of about 1,000 committers cast their vote. More votes will add weight to the positions of the committer representatives, so please vote now!
There is more than one Eclipse Board of Directors, so be careful not to confuse the different board elections. ;-)

Eclipse in the Cloud

2009-02-17T18:07:00.000-05:00

About a year ago, at EclipseCon, we showed a demo of how the Eclipse IDE could look like if it was browser-based, talking to an Eclipse server "in the cloud". The reactions were lukewarm: "Looks cool, but why would I want to run an IDE in a browser?" "I have yet to see web enabled IDEs as an industry trend".

This industry trend is now starting to happen.

On Thursday, Mozilla and their new developer tools lab launched Bespin, an "experiment proposing an open, extensible web-based framework for code editing". Within a few days, 30,000 people logged into their public server, 400 people joined their discussion group, about 50 bugs were filed, several of them with patches, and many articles, blogs and even a Wikipedia entry were written. Congratulations, Ben and Dion of Mozilla (and Ajaxian fame), on the successful launch!

We looked at Bespin and asked, wouldn't it be great if Eclipse could play in this space too? Wouldn't it be cool if we could implement a Bespin server using Eclipse plug-ins that already exist?

Well... that Eclipse-based Bespin server is available now, after two days of development!

Simon Kaegi and I locked ourselves into a room and just implemented it. Today, we are declaring success, and are sharing the code as part of the e4 project with anyone interested. If you would like to give it a spin, check out this wiki page.

The Eclipse IDE, as you know it, is an OSGi-based application, and is built entirely out of components (called plug-ins or bundles). Many of these components can run headless, on a server, such as the underlying resource model, the incremental Java compiler, etc. Using the headless components, it was very easy to implement the Bespin client-server API. Like Mozilla's Bespin server, our server supports browsing files and folders, and editing files. In addition to that, we implemented extra features such as showing compile errors and warnings, and checking out projects from CVS servers using anonymous CVS.

Bespin already shows a lot of promise at this early stage. It consists of a surprisingly fast code editor written in JavaScript using Canvas, a file browser, and an emacs-like command line interface for issuing commands. There are two backend implementations provided by Mozilla, one in Python, and one in Java, and the browser-based client talks to the server using a RESTy API. Here is how it looks like:

If you would like to play with the Eclipse Bespin server, or work with us on it, check our wiki page. If there are any questions, hop on IRC, where we can be found on #eclipse-e4/irc.freenode.net or #bespin/irc.mozilla.org as borisb6i and skaegi.

P.S. Mozilla has a cool-looking and fast client, and Eclipse has a lot of experience with IDE features, and good amounts of code that can run headless. Sounds like a great opportunity for collaboration, doesn't it? Well, thanks to Mike and the Eclipse Foundation who organized it, and Dion and Ben who are investing their time and some of Mozilla's travel money, we will have an in-person meeting on Thursday, in Ottawa, to talk about this. These guys are moving fast!

Bundle Marketplace: +1

2009-02-05T16:51:00.002-05:00

I fully agree with Gorkem Erkan that the Eclipse community should seriously consider building a bundle marketplace. In fact, I recently had the same idea (independently) as you can see here on Twitter.

In the Eclipse context, that bundle marketplace would probably consist of multiple overlapping sub-markets... with every Eclipse-based application defining a sub-market. For example, bundles that work with the Eclipse IDE, bundles that work with the Flex IDE, or the SAP IDE, or with IBM's Rational tools such as Team Concert. Also, at the RCP level, vendors could offer a basic application for free and offer upgrades as additional for-pay bundles.

I think this an exciting idea. What do we need to do to make it happen? Would the Eclipse Board of Directors support this? Which members of the Eclipse community (other than Kent Beck ;-) ) would benefit the most, short-term?

Looking forward to your comments.

Are you listening?

2008-10-16T11:48:00.000-05:00

Did you know that the Eclipse SDK alone has over 250 different listener interfaces? In the following screenshot, look at the size of the scrollbar slider!

This is only the tip of the iceberg - corresponding to all these listener interfaces, there are about 250 different Event classes. This is so that later on, additional event data can be added without breaking binary API compatibility by passing a dedicated event object to the listener. (Remember that where we forgot to use event objects, we ended up with warts like IPerspectiveListener4.)

To top it off, there are probably about 500 methods for adding and removing all these kinds of listeners. addLaunchLabelChangedListener/removeLaunchLabelChangedListener, addLocalSiteChangedListener/removeLocalSiteChangedListener, addLogEntryListener/removeLogEntryListener and so on.

In the end, when you think about it at a more abstract level, there are only a couple of possible changes that can happen in a program. A value can change, from an old value to a new value. A set can change, by adding or removing elements. A list can change, by adding elements at a certain index, removing elements at an index, or moving or replacing elements.

How about we use only three listener interfaces, IValueChangeListener, ISetChangeListener, and IListChangeListener? Or we settle on something that looks like EMF's notification API. We might need pre- and post-notifications, and maybe also changes to maps, so the resulting number of listener interfaces might be closer to ten. Definitely not 500 - and I only looked at the base Eclipse SDK...

What do you think? Can we make the Eclipse API more consistent and uniform in this way? Do you agree that all these domain-specific listener interfaces, each with a corresponding event class, and add/remove methods, are a source of accidental complexity, and settling on a small number of generic listener APIs can reduce code bloat?

Avoiding Bloat

2008-10-07T15:30:00.000-05:00

Martin Oberhuber asked on the e4 mailing list what had happened to the pervasive architectural themes that were identified at the summit, such as reducing bloat, too many listeners, and becoming more asynchronous. I started writing a response, focusing on one of the topics, bloat, and it quickly became more than just an email response so I am posting it here.

Before we go into the details, let me state the obvious: It is pretty much guaranteed that we will cause more bloat, overall, for the case of the Eclipse SDK based on the new e4 platform, as long as that SDK still contains 3.x plug-ins that require compatibility layers. This is because all the old (bloated?) functionality and the new (lean?) functionality will be there at the same time.

It seems the best we can do is to avoid bloating the new platform itself, when it is used without any compatibility layers. Unfortunately, we have all these cool new technologies that we would like to use - EMF, CSS, declarative UIs, data binding, cross-compiling of Java to ActionScipt, being able to use multiple languages, client-server split, etc. Put them together and the likely result is bloat. Or is there a way to avoid bloat and use cool new technology at the same time?

So what is bloat? Let's look at Wikipedia's definition of software bloat (thanks John Arthorne for pointing me to it):

Software bloat, also known as bloatware or elephantware, is a term used in both a neutral and disparaging sense, to describe the tendency of newer computer programs to be larger, or to use larger amounts of system resources (mass storage space, processing power or memory) than necessary for the same or similar benefits from older versions to its users.

Let me dive into one concrete example, to show why this is a hard problem:

Code bloat through redundancy, caused by low-level API occurs when clients of a low-level API have to write the same boilerplate code over and over again. Think of all the code we have to write for SWT layouts, for example:

Composite contents = new Composite(parentComposite, SWT.NONE);
contents.setLayoutData(new GridData(GridData.FILL_BOTH));
GridLayout layout = new GridLayout();
layout.marginHeight = convertVerticalDLUsToPixels(IDialogConstants.VERTICAL_MARGIN);
layout.marginWidth = convertHorizontalDLUsToPixels(IDialogConstants.HORIZONTAL_MARGIN);
layout.verticalSpacing = convertVerticalDLUsToPixels(IDialogConstants.VERTICAL_SPACING);
layout.horizontalSpacing = convertHorizontalDLUsToPixels(IDialogConstants.HORIZONTAL_SPACING);
layout.numColumns = 2;
contents.setLayout(layout);

Label label = new Label(contents, SWT.LEFT);
label.setText(WorkbenchMessages.FileExtension_fileTypeLabel);
GridData data = new GridData();
data.horizontalAlignment = GridData.FILL;
label.setLayoutData(data);

filenameField = new Text(contents, SWT.SINGLE | SWT.BORDER);
data = new GridData();
data.horizontalAlignment = GridData.FILL;
data.grabExcessHorizontalSpace = true;
filenameField.setLayoutData(data);

Whenever there is a low-level way of doing things, you can come up with a higher-level way and reduce the code size. Of course, you are only reducing the overall code size when the higher-level abstraction is used widely enough to amortize the cost of its implementation. In our SWT layout example, you could write instead:

Composite contents = new Composite(parentComposite, SWT.NONE);
contents.setLayoutData(new GridData(GridData.FILL_BOTH));

new Label(contents, SWT.LEFT).setText(label);

filenameField = new Text(contents, SWT.SINGLE | SWT.BORDER);

Point defaultMargins = LayoutConstants.getMargins();
GridLayoutFactory.fillDefaults().numColumns(2).margins(
defaultMargins.x, defaultMargins.y).generateLayout(contents);

Now this is looking a lot shorter, and maybe even more elegant. However, even if GridLayoutFactory is used widely enough to amortize the additional footprint caused by its implementation, there are still two problems: first, the original code ran faster, and second, you now have to learn two APIs - the higher-level one, and the lower-level one when the abstraction gets in your way.

You can see where I am going - there is no clear cut solution to this. It is really a hard problem, and in many cases, we will have to trade off one of the factors disk size, memory size, CPU consumption against the others.

Taking it just a little further, here is another idea, taken from the wikipedia article on code bloat:

The difference in code density between various languages is so great that often less memory is needed to hold both a program written in a "compact" language (such as a domain-specific programming language, Microsoft P-Code, or threaded code), plus an interpreter for that compact language (written in native code), than to hold that program written directly in native code.

So if we had a domain-specific language for creating SWT widgets and specifying their layout, we could get away with no Java code at all! I don't know if the .class file is a space efficient encoding for SWT widget hierarchies and layouts, but even if it is, consider this: The byte code for creating the widgets will stay in memory for as long as its class is referenced. Chances are that this will be a very long time; at least for the time that particular part of the UI is materialized somewhere. By comparison, if we had a domain-specific language, it would have to be read once to create the widgets and layout, after which the memory could be freed.

So maybe we can have our cake and eat it too! After thinking about this a bit, I am all excited about using cool new technologies, as long as they don't cause bloat.

We also have to be very carfeful not to use multiple redundant technologies to achieve the same thing, because that is another source of bloat. As in, for example, letting everyone plug in their favourite domain specific language for creating SWT widgets and layouts. This kind of redundancy would be just as bad as redundancy through repetitive boilerplate code, so let's pick one way of doing declarative UIs!

Note that there are lots of other sources of bloat, for example, unneeded functionality, too many layers of abstraction, or unnecessary flexibility. I am running out of time but it is probably interesting to think about these as well. I'd like to know if you have any pointers for me in the comments!

If avoiding bloat is one of the goals of e4, we need to keep this goal in mind all the time. Every bit of functionality should be pulling its own weight. For example, do not add convenience API unless its additional weight can be justified by reduced weight somewhere else.

I believe we should start watching our weight from the very beginning, and from time to time, it is probably healthy to discuss the weight of the various pieces. I can't wait until we have some kind of continuous build in place, so that we can make it visible for everyone how big (or small!) the components are, and how they are growing (or shrinking!) over time.

We could also borrow some ideas from the business world and introduce budgets. You want to provide a component for declarative UI? How about you get an allowance of 300 K? Would that be enough?

What do you think?

Accidental Complexity

2008-09-25T13:38:00.000-05:00

You can blame bit rot, API backwards compatibility, plain stupidity, or that we just didn't know any better at the time. Whatever the cause, we have introduced a good deal of accidental complexity over the last eight years or so, and with e4, we have a chance to reduce this or get rid of the "accidental" part altogether.

Here are some examples. If you know of other examples, please let me know!

First example: We have lots of early attempts to define API that had to be tweaked later; to see what I mean, press Ctrl+T for the Open Type dialog and enter 'I*2<' to see all the interfaces where we had to introduce a second and hopefully better version. Like IPerspectiveListener2, which was introduced in 3.0. This example is particularly embarassing, because we introduced IPerspectiveListener3 in 3.1. And, believe it or not, IPerspectiveListener4 in 3.2. Boy, am I glad that this has finally converged, or we would be looking at IPerspectiveListener7 in Eclipse 3.5.

Second example: The confusing (and untold) preferences story comes to mind, as a representative of a whole class of problems. Basically, whenever we ended up with many different ways to do the same thing, we were not able to remove old code because clients still depended on it. I am optimistic that the capabilities offered by the platform can be pared down to a manageable list. Ideally, down to something like twenty services, sometimes called "the twenty things" or the "Eclipse Application Model" in the context of e4. Like being able to persist data. Receive input. Produce selections. Schedule background work. Report progress. Provide pointers into the help system. Contribute to the menus and toolbars. And so on, but I don't have a full list at this point so I should write about it when I know more.

Third example: Like many other Java APIs, we live in a kingdom of nouns. We are sometimes joking how Eclipse, for every concept, has an adapter, a factory, and a manager. And an adapter factory, and a factory manager. Sadly, this is not a joke at all. ContextManagerFactory. ModifierHelperFactory. AbstractRefactoringDescriptorResourceMapping. I wish I could make concrete suggestions for how we can improve on this, but I am afraid we need to look at these APIs in detail. It's just a gut feeling that names with three or more three nondescript nouns are making things more complicated than necessary. By the way, my mother tongue is German, so I should be used to putting many nouns together, but I still find something like INodeAdapterFactoryManager is way over the top.

Fourth example: a good deal of complexity and bloat is caused by the proliferation of preference pages, leading to a countless number of lines of code that supports all the different combinations of all the supported preferences. Are we really helping our users by exposing and maintaining all these options?

That's it for today. I'd love to hear what you think about this, or if you have more examples of accidental complexity.

(Disclaimer: I am well aware that e4 will need to be backwards-compatible, so that 3.x plugins continue to run. When I wrote "get rid of" I meant something a little more subtle, as in "move it to compatibility plug-ins so that adopters of e4 don't have to worry about it when they develop new functionality.")

Better Than Newsgroups?

2008-09-15T16:27:00.004-05:00

For programming-related questions and answers, check out stackoverflow.com, which launched today with a public beta. It looks very interesting - a forum, crossed with digg (user-rated), wiki capabilities (user-edited), and delicious (tags). The hope is that these three mechanisms will make the site more valuable over time, as questions are answered, rated, tagged, and edited for clarity.

Currently, the site is a bit Microsoft-heavy. For example, C# has twice as many questions as Java, and EMF refers to the vector graphics "Enhanced Metafile Format". Still, Eclipse is well represented with 58 questions compared to Netbeans with 5.

I find it amazing to watch how questions come in at a rate of roughly one per minute, and how they get answered at a similar rate. It's just like on the EMF newsgroup, but so much more Web 2.0!

Simply models

2008-09-05T12:37:00.010-05:00

I have been working on a small demo application that (when finished) is meant to be an exemplary RCP-style desktop application based on e4. This is how it looks so far:

There is a very simple navigator on the left, a thumbnails view, and a preview area.

As I wrote the application based on Eric's and Tom's work, I started by implementing a couple of views that I contributed to the new e4 Workbench through an extension point.

Then I realized that all I need is an EMF model representing the parts that make up the UI: the views, the menu, and the toolbar. I don't actually need any extension points, because my application is not an extensible IDE - it is a rich client application for which I know how the UI should be structured. I am pretty happy about the end result - my application is fully described by one XMI file that I can edit using an editor for EMF models, and I can just go and modify that file if I want to rearrange views, add new ones, delete unnecessary ones, build my menu structure and so on.

Compare this to how it works with the current 3.x Workbench: I would have to write a perspective extension, a couple of views extensions, a command extension, a menu and a toolbar extension. Then I would have to assign unique IDs to all these pieces, and to ensure that IDs match up properly. How many hours we've wasted in the past when IDs did not match up!

Of course, this only works for closed applications, not for open and extensible ones like e.g. the Eclipse IDE. However, it is still pretty useful to be able to reason about a concrete EMF model representing the UI application structure. For example, when you have lots of little pieces contributed by many plug-ins, we can now talk about what it means to produce that concrete model from the many little pieces. One interesting question based on this is: Can we maybe generalize the many ad-hoc mechanisms we have grown over the last years (most of which involve matching up IDs) to something that is less ad-hoc and more general?

It's been fun to work on this little application so far. If you would like to participate, let us know on the e4 mailing list, and/or attend the bi-weekly e4 conference calls. You can always email me directly, of course.

P.S. The code is available in CVS - check out the ui/demos project under /cvsroot/eclipse/e4-incubator to get the launch configuration and project set file (emf-workbench.psf).

Unpaid Volunteers Do Exist

2008-06-05T10:25:00.005-05:00

Bjorn blogged about a recent discussion on the SWT and Foundation newsgroups, and claims that Eclipse does not do enough to attract unpaid volunteers.

From my little corner of the ecosystem, I can offer a counterexample. As of today, three of the nine active committers on the Eclipse Platform project's UI component (JFace, Workbench, IDE) are unpaid, part-time volunteers. It seems to be attractive enough to be a Platform committer, at least to some, resulting in 33% active Platform UI committers who are not employees of IBM.

Interestingly, they are all 'unpaid volunteers' (this applies to two more who are not listed as active committers now but were active in the past). They are independent consultants, employed software developers investing some of their spare time, or come from small companies that use Eclipse technology. To me, this contradicts Bjorn's assumption that Eclipse is only 'paid volunteers'. In fact, I would like to understand why in the past, we haven't seen 'paid volunteer' people approach us because they want to contribute to the Platform. (It looks like the e4 effort may change this.)

I admit that we could be more open and transparent over just explaining how to contribute, and hanging out on IRC and the newsgroups. However, what we cannot do is invest a lot of time into contributors who only contribute once (as opposed to ongoing, even if it is part-time). Working with the community on their contributions takes a lot of time. This is why we invest more time on those who may turn into committers at some point: if/when they become committers, we can hope for a return on our time investment.

By the way Bjorn, by disagreeing with one of the replies saying: "this is entirely a volunteer effort", you disagreed with an actual unpaid volunteer, one of the part-time non-IBM committers on the Platform UI component. Francis managed to break through the "glass wall", and the Rizzo Ceiling! I would recommed that you read Francis' post again in this light. ;-P

P.S.
A large part of the high barrier of entry and learning curve is inherent in what we do, and results from all the IP rules, process rules, API compatibility rules, accessibility rules, internationalization rules, performance considerations, architectural integrity considerations, and some more that I probably forgot. I don't think we can do much about this, but I agree with Francis that we need to get a lot better at encouraging contributions and contributors.

e4 summit: May 22nd/23rd

2008-04-10T23:30:00.002-05:00

I hope that all interested parties are already subscribed to the e4 mailing list. For those who are not, just an update that we now have a date (May 22nd/23rd, 2008) and a location (Ottawa) for the e4 summit, and that work on the agenda has started. If you are interested in working on the new Platform, please consider attending the summit and add yourself to its wiki page.

e4 pointers, and a teaser

2008-03-19T12:57:00.006-05:00

This is just a quick update for those who would like to contribute to e4, and those who would like to get our demo code to compile and run. I just updated the e4 wiki page (wiki.eclipse.org/E4) with a link to the mailing list, and instructions on how you can run the demos.

Oh, and here is a screenshot of the demo that was not shown in the Eclipse 4.0 talk. Come to the Eclipse 4.0 (e4) Kick Off BoF tonight to see it live:

Pre-emptive snarky comment

2008-03-05T22:42:00.004-05:00

It appears I am not the only one reading the "Old New Thing" blog from a Microsoft employee who sometimes ends his posts with pre-emptive snarky comments, like for example:

I enjoy reading that blog, and not for the snarky comments. I find it interesting to read from someone who is working in a similar position but different context: there seem to be striking parallels with similar experiences we have made on the Eclipse Platform team.

Anyway, it is time to make a pre-emptive snarky comment myself. It is not actually related to this blog entry. It is related to an e-mail announcing the creation of a new component e4 in the Eclipse Incubator project:

"Just as I expected from those guys at IBM. We'll never see diversity in the Platform."

Now that this is out of the way, here is the scoop: We want to make the code for our EclipseCon demos available in the open. We realized (admittedly, very late) that nobody from the SWT team had commit rights in the existing Eclipse Incubator project. Creating a new component in the Eclipse Incubator project was the fastest way to create a home for the experimental code that we will be demoing, with write access to everybody who has been involved so far.

The key words are "so far" - our hope is to find more people and companies who would like to work with us on e4 - our current name for the next-generation platform on which an Eclipse 4.0 can be built. To find out more about this, and to see the demos, come to these two talks at EclipseCon: Eclipse 4.0, and The Future of SWT.

By the way, when I wrote "we", I was referring to people at IBM, Innoopract, and Code 9. So far.

Hello Android (updated - now with link)

2007-11-12T12:58:00.000-05:00

Good to see Eclipse being part of Google's Android story.

Looking for RCP experience reports

2007-11-08T16:46:00.000-05:00

As the RCP guy on the EclipseCon 2008 program committee, I am trying to organize a "show and tell" session of interesting RCP applications, using several back-to-back short talks. If you want to tell us about your experiences with RCP, please make a short talk submission soon, the deadline is approaching fast! More details about what I am looking for can be found here.

BugDay tomorrow, Sep 28

2007-09-27T09:43:00.000-05:00

The Platform UI team is participating in tomorrow's bug day. We have marked a couple of bugs with the "bugday" keyword, added contact information to the September 28 BugDay wiki page, linked to the "How to Contribute to Platform UI" page, and made available project set files for all of Platform UI and IDE.

Happy bug fixing everyone!

I'm busy building a new Platform

2007-09-13T13:53:00.000-05:00

With all the recent talk about diversity and the Platform, I felt compelled to post some pictures of my backyard as well. I took a few photos today, well past the crack of dawn, at a time that I would have liked to wake up (unfortunately, my kids have to be at school at 8).

So what occurred to me is that the most important quality of a platform is that it earns the trust of its users and adopters. For example, trust that the platform will last for a long time, and that it is stable enough to support whatever you want to build on the platform. It may help when the platform is built by a diverse group of people, but diversity is not an end in and of itself. I for my part decided to not rush it, and to pay special attention to stability, which I hope you can see in the pictures.

Those bolts are half an inch thick, and four inches long. Overengineered, you might say, but down at the platform, it is important to set a high bar for anything that goes into the platform. Because we know the platform must not crush under whatever is built on top of it.

So I decided to build all of this myself without any outside contributions. However, I haven't figured out how best to build the roof yet. If you have roofing experience, I would like to know how you did it, and I might accept contributions such as shingles if you have some leftovers.

I almost forgot to talk about the other Platform I am working on. The Platform UI team is always open for contributions, and we are proud to have attracted several non-IBM committers. When I asked why they like being a Platform UI committer, one of the main reasons was that they learn a lot from us, and from just taking part in building a great platform.

If you would like to become a Platform UI committer too, my advice would be to pick one specific area you are interested in rather than scattering your efforts across all of Eclipse. This ensures that you will deal with one or two committers all the time, which helps building trust. (Remember, for platforms, it is all about trust). For example, pick RCP related issues, or editor management, or wizards, etc. Start by watching bugs in Bugzilla, and answering questions on the newsgroups, focused on that one area. This will get the corresponding committer's attention. Write an email to our mailing list with your intent to contribute, or if you are shy, send an email just to me. If we know about you and what you would like to do, we can start sheperding you towards becoming a committer.

I put some time into our wiki pages to lower the barrier. You might want to check out the new how to contribute page which is based on a similar page Brad Reynolds, one of our non-IBM committers, wrote for the data binding framework. To make it easier to find similar pages for other Eclipse projects or project components, I added a how to contribute category.

All of the above mainly applies to individuals who would like to contribute. If you are reading this from a corporate perspective, and you as a company would like to invest in or contribute to the Platform, you are welcome too! Write me an email and my manager will get back to you. ;-)

Improving editor tabs is hard

2007-07-26T05:39:00.000-05:00

I just ran across Aza Raskin's interesting usability puzzler about how tabs in Firefox should work. It is a very interesting read, especially some of the comments, and is directly related to the problem of how to improve editor tab management in Eclipse.

Firefox 1.5 had a single row of tabs that were visible all the time. Each tab shrunk equally as you opened more tabs than could be shown with complete titles. This works well for a small number of tabs, and degrades gracefully as you open more tabs. However, it does not scale to a large number of tabs - after opening twenty or so tabs, the space for each tab is just too small and users won't be able to tell which tab contains which web page.

Firefox 2.0 tried to solve this problem by only showing a limited number of tabs. Essentially, what you see is a scrolling window into the complete list of tabs. There are buttons for scrolling left or right, and a drop-down menu at the far right allows you to see the full list of open tabs as well as jumping to a particular tab.

Aza criticizes that the new tab behaviour is concealing information, and that it makes it harder to navigate between tabs because of the added UI complexity - i.e. the scroll buttons, the drop-down list. My mother tongue German has a useful composite word for what happened: "Verschlimmbesserung" - making something worse in an attempt to improve it.

Of course, his criticism applies to Eclipse as well. The drop-down menu in Firefox is comparable to the one in Eclipse which opens when you click the chevron, or press Ctrl-E. The scroll buttons do not appear in Eclipse - instead, it uses a logic which will show only the most-recently used editors. This appears to work for some users, but it also drives other users nuts (including myself) because it is practically impossible to predict what will happen to your tabs as you switch between editors. All in all, I'd say that Eclipse has at least as much added UI complexity as Firefox 2.0 over Firefox 1.5.

The Mozilla/Firefox developers are watching the conversation, and I would encourage interested others in the Eclipse community to do so too. I enjoyed reading the discussion in the comments, the proposed solutions, and even some cool mockups. Hopefully, I'll have some more time next week to write about the more interesting proposals for Firefox and what I think we can learn for Eclipse.

Until then, I will be using Vertigo, an extension for Firefox that shows tab titles in a vertical sidebar, to see how well it works for web browsing.

Innovation and Push vs. Pull

2007-06-23T14:11:00.000-05:00

Some of you may wonder what those tweaklets are that have been mentioned and even hyped in recent blog postings.

We are actually trying out a different avenue for innovation in the Eclipse UI. So far, we got feedback for new or changed features by putting them in an early milestone and waiting for the inevitable pushback. With tweaklets, our hope was that ideally, we could generate pull from those in the community who want to see this in the main codebase. Seems to work beautifully! :-)

So, Nick, thanks for making the Autopin tweaklet #1 on your list! By the way, it works best if you disable editor reuse on the Search, Debug, and Team preference pages, and it does not work well in conjunction with the Don't-Steal-My-Focus tweaklet which is also available from the update site.

Who is to blame?

2007-03-24T09:33:00.000-05:00

Ever wondered why Eclipse takes so long to start? Now you can find out, with a small plug-in that makes use of the new pluggable splash API. Just drop the "blame splash" plug-in into your plugins directory of a recent Eclipse build, restart Eclipse (use the -clean command line option once so that the new plug-in is recognized), and watch which plug-ins are loaded and why:

After Eclipse has started, the functionality is moved into its own proper window until you close it:

I tested this on Windows XP but it should work on other platforms too. You will need a 1.5 level Java VM to run this.

(Update, April 10, 2007: Essentially the same functionality, plus lots more, is offered by the core tools. The information just doesn't appear in the splash screen :) )

Please file specific bugs if you think that too many plug-ins are activated!