My Key Bindings Don't Work

In 3.2 M4, some of you may have noticed that some of your key bindings weren't working as you would expected. This was entirely my fault. I was fiddling with converting the old action-based extension points into a pure command representation. So now, even actions without an action definition id will get a command automatically generated. This is great fun, but it led to some conflicts between handlers. This should be fixed in I20060110-0800 and later.

Linkability and Commands

I've spent a fair amount of time in the past few weeks talking with Christopher Daly in Beaverton. We're working on a way to integrate the cheatsheet linking mechanism with commands. It looks like we will expand how parameterized commands work. Currently, a parameter is just a string. Our proposal is to provide a typing mechanism on parameters that allows us to convert the strings into objects (and vice versa). This would allow someone, for example, to create handlers that work on domain-specific objects, rather than every handler needing to do some conversion on their own. It would also allow someone to find all commands that work on a particular object type (e.g., all commands that take a java element as a parameter).

Commands and parameters are becoming remarkably similar to Java methods and parameters, except specified in XML. The command definition becomes like an interface, which the handlers all must implement. Then the binding is done dynamically at run-time based on the activeWhen expression. It's interesting because we can make our language different (i.e., more powerful) than the Java language. Should we allow the type look-up to be more flexible (e.g., allow things like or or adapt)?

It also highlights some of the weaknesses of extensions as API. As it stands right now, most ids defined in extensions become equivalent to API (e.g., view id, command id, editor id, etc.). But there is no real means to provide documentation. So, if the parameters for a command define an API contract, where does one put the documentation?

EclipseCon Talks

My talk got accepted! The list of tutorials are finalized and scheduled, and the acceptances for long talks are starting to go out. I'm happy, 'cause it looks like we'll actually be able to put together a decent Halo team.

Platform/UI Tutorials and Talks

The Platform/UI team at IBM has proposed several talks and tutorials for EclipseCon 2006. If you're going to be going to EclipseCon, I'd suggest taking a moment to check them out.

Tutorials:

• Foundations of UI Development with Eclipse. This tutorial will teach the UI foundations of the Workbench and JFace to developers with limited experience in this area of plug-in development. Attending this tutorial will also act as preparation for the "Advanced Development with the Eclipse UI" tutorial. This session will give an introduction to the components of the Workbench, such as (views, wizards and menus) writing sample code along the way. At the end of this session attendees will have built a set of samples that exercise the various building blocks of the Workbench and JFace.
• Advanced UI Development With Eclipse. This tutorial will be a follow on session for "Foundations of UI Development with Eclipse", however the foundations session is not required for developers with sufficient Eclipse experience. While the Foundations session gives an introduction to the components of the Workbench, this session will apply what was learned in the first session in building an application that is tightly integrated with the Eclipse SDK using many key features of the Workbench. At the end of this session attendees will have created an integrated Eclipse UI application.
• At Your Command: Migrating From Actions To Commands. In 3.2, actions and action-based extension points are becoming deprecated. This tutorial will discuss the new commands architecture. Commands allow plugins to extend the Eclipse menus, toolbars, and status line -- as well as providing hooks for undo/redo support and key bindings. This tutorial will start with the basic uses of commands, and move on to more advanced features: undo/redo support, key bindings, parameterized commands, dynamic menus, and contributing arbitrary controls to toolbars and the status line. The tutorial will focus on uses of the existing actions API, and show how these can be migrated to commands.
• Designing Eclipse APIs. Good APIs are critical to the long-term success of any Eclipse project. Over the last years, the Eclipse Platform team learned many lessons on API design, which we would like to share with the other Eclipse projects. This is a hands-on tutorial with many examples, practical exercises, and enough room for discussion. The covered topics fall into three categories. On the level of Java, we explain how to write maintainable APIs that don't break existing clients. On the level of Javadoc specifications, we teach how to make promises you can keep long-term. On the process level, we tell you about best practices that help you improve the quality of the API you are developing. This tutorial is targeted at Eclipse committers.

Long Talks:

• Smaller, Faster, More Responsive - Performance Tuning Using the Eclipse Platform.
• Redoing Undo: Eclipse 3.1 Undoable Operation Support.
• Data Binding with the Eclipse Platform.
• Your action is my command.
• Customizing UI Look and Feel with Eclipse.
• Everything Changes: Dynamic Plug-in Support in Eclipse.
• Go Wild with RCP: Anatomy of an RCP-based Smart Client Application.
• Practical Accessibility in Eclipse.

Events:

• Halo Feature Challenge. Want a particular feature in Eclipse? Challenge 4 Platform/UI committers for the right to get your feature or bug fix into Eclipse. Scratch games are also available if you just want to meet the Platform/UI team. Challenging teams can be two to four people. The feature or bug fix must be reasonable: this means not too big and not too controversial. It will likely also have to be in the Platform itself, just because we don't have commit rights anywhere else. The match will be three games. One selected by the challenger, one selected by us, and one will be Team Slayer on Blood Gulch.

Why GtkFileChooserDialog Sucks

Some people say that the native file dialog is a key aspect of "native integration". It can be very frustrating to have some feature supported in one file dialog, but not in another. Eclipse is largely a GNOME application. We try to integrate as well as possible with KDE, but ... well, we're written on top of GTK+. There's only so much you can do. So, our file dialog should be the GNOME file dialog (i.e., GtkFileChooserDialog).

But, the average Linux user is used to many different file dialogs. KDE and GNOME applications use different file dialogs, and then some applications write their own custom dialog (e.g., OpenOffice, Firefox, xine, etc.). And what happens if you want to innovate (e.g., Microsoft Word 12)? And what do you do if the native dialog just isn't all that good?

This is where I'm stepping up. I feel the GtkFileChooserDialog is somewhat behind in "state-of-the-art" file chooser dialogs. Here's why (flame bait):

1. File Manipulation. When I'm in a file dialog, I generally expect to be able to manipulate the file system. I want to be able to create and delete files and folders (including trash can support). The only thing I can do is create a folder when saving something.
2. Key Bindings. "Alt+Back", "Alt+Forward", "Alt+Up/Backspace". These three key bindings can do wonders for making the dialog easy to navigate with a keyboard.
3. Limited Breadcrumbs. The breadcrumb support is a little bit limited. I can only jump up a fixed number of levels. It also isn't possible to jump up from "home" to a more general location.
4. Hidden Files. If I decide to show hidden files in the dialog, it does not remember this the next time it is opened.
5. Wasted Space. There is significant wasted space on the left-hand side of the dialog. All the items are one word, but yet there is space enough for several words.
6. Single List. The single list format is fine for small directories. It gets a bit burdensome for directories that have hundreds of files in them. It's not just about finding the file (which the type-ahead handles well), but about getting a feel for the state of the directory. It helps the user sense what other things are in the same directory, as well as giving them an indication if the directory is getting out of control.
7. Open Location. This function is hard to understand as it stands right now. It only appears in the context menu and by pressing "Ctrl+L". It's not clear what it's going to do. Once open, there's a race condition on the auto-complete. If you type '/h' and wait too long before pressing 'o', then the auto-complete pop-up is triggered and immediately fills in the rest of '/home'. Conversely, if I press '/ho' close enough together, then it fills it in, leaves the cursor after the 'o', and selects the rest of the text ('me/').
8. Icons. Icons would be nice. It makes it easier to quickly identify files. It's especially nice for the quick navigation bar on the left, at least from an aesthetic perspective.
9. Modified Column. This is an excessive default. It is something that is useful infrequently, and so perhaps better as an option that can be turned on.
   

Just so you know, I'm talking about the file chooser dialog as it appears in Eclipse 3.2 (under development) and GTK+ 2.6.10. I run KDE as my desktop environment. If some of these things have changed, that's great. If some of these things are just SWT (i.e., Eclipse's layer on top of GTK+) being suboptimal, then I'd like to know.

Things I Have Learned About API

It seems like I'm always learning new things about API -- especially with regards to Eclipse and Java. Here are some of the tidbits I've picked up.

1. Avoid Interfaces. It is good to avoid interfaces which you allow others to implement. Abstract super classes allow you more flexibility in the future. You can, for example, add new methods to an abstract super class, but you can't add to an interface.
2. Avoid Exposing Dependencies. It is good to try to avoid exposing anything you're dependent on. If I am writing a plug-in B that depends on A, then it best to avoid a couple of things. First of all, try not to have any of the classes in A appear in the API for B. If you need to expose classes from A, then it is good to try to avoid re-exporting the whole plug-in in your MANIFEST.MF.
3. Isolate Dependencies. Any time you are dependent on someone else's code, it is a good idea to try to isolate that dependency to a single place. This way, if you need to change the dependency at some point in the future, it is easy to do (rather than painful).
4. Minimal Commitment. If you never expose something as API, then you don't need to support it as API in the future. Releasing a minimal API at first gives you a chance to judge weaknesses and make changes. And, when specifying API through documentation, it's a good idea to only promise what is necessary to make the API useful (i.e., hide implementation details).
   
5. Be Precise. While the specification should promise little, the constraints on the parameters accepted should be very precise. This generally means indicating whether null is accepted or not, whether collections can be empty, and what types of elements are allowed within the collection. Enforce these constraints at the top of the method, so that implementation details don't allow people to get away with things. Expect lots, promise little.
6. Tiny Plug-ins. It's generally good to try to keep your plug-ins small -- containing only one functionality group. You can then use "glue" plug-ins to group functionality into logical combinations. I say this not from experience of doing, but from experience of regret. It's hard to predict what downstream clients might want or not want; you make their lives easier by keeping things in small modules.
7. Avoid Methods With The Same Name. If you are creating methods (public, private, whatever), it is generally a good idea to avoid methods with the same name and the same number of arguments. This avoids problems where YourClass.method(null) stops working because null is no longer precise enough. It also helps you avoid quirks in your compiler.

JFace and SWT Standalone

Significant steps have been taken to provide an easy way for developers to write JFace+SWT standalone applications. We've removed the dependency on org.eclipse.core.runtime and replaced it with a dependency on org.eclipse.equinox.common (which is much smaller). This allows you to use things like viewers, dialogs, wizards, commands and actions on top of the bare-bones SWT, while avoiding support for things like the registry and jobs.

This gives us three different bases on which applications can be built. Note that the sizes vary slightly from platform to platform. Also, this includes the default build of all these pieces. If you're willing to hack out pieces you don't need, then you can further reduce the size.

• SWT (~2.2MB)
• JFace and SWT (~3.0MB)
• Rich Client Platform (RCP) (~7.5MB)

I've opened a new bug about the possibility of providing a JFace and SWT standalone download, similar to the SWT standalone download that is currently available.