Hello Android (updated - now with link)

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

Looking for RCP experience reports

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

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

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

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

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?

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!

Circular Debugging

Did you know you can attach the Eclipse debugger to itself, i.e. the currently running Eclipse instance?

What the ...? Attach to itself? Yes, to itself. Sort of like the MetaClass circularity in Smalltalk, but different. But I digress...

Imagine a single Java VM which runs Eclipse. To be able to connect a debugger to it, it has to be started in debug mode. With a Sun VM, the following magic command line does the trick:

-vmargs -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

Note how we use suspend=n to let Eclipse start without waiting for a debugger to connect. If you start Eclipse by running the executable directly, you can put the options in your eclipse.ini file instead like this:

-consoleLog
-vmargs
-Xms40m
-Xmx256m
-Xdebug
-Xnoagent
-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

I also added the -consoleLog option in order to see any strings printed to the console by Eclipse.

Alright, so now we have Eclipse running as usual, except it is running in debug mode. This is not very exciting yet, but wait for this - here is how you attach it to itself, in three easy steps:

1. Pick a project containing the Eclipse code you want to debug.
   We will be debugging what is called a "Remote Java Application", except that the application is not very remote ;-). The debugger needs a project when creating the launch configuration because otherwise it would not be able to look up classes and their source code. You can pick your favourite Eclipse plug-in from your workspace, but make sure that the code in the project matches the exact version of your running Eclipse. If you want to play it safe, I recommend creating a project as follows: Open the Plug-ins view, select all, and pick "Add to Java Search" from the context menu. This will create a project called "External Plug-in Libraries" that matches your currently running Eclipse instance.
2. Create conditional breakpoints (optional):
   Since there is only one VM and thus only one UI thread, you will not be able to single-step through code that runs on the UI thread. Don't add unconditional breakpoints to any UI code because this will lock up Eclipse. You can, however, add conditional breakpoints that don't actually suspend the current thread. Create a breakpoint, then right-click on it and pick "Breakpoint Properties", click on "Enable Condition" and put something like this in the space below (by returning false after printing to the console, the thread will not suspend).

   System.out.println("Breakpoint hit");
   Thread.dumpStack();
   return false;
   

3. Create a launch configuration for a "Remote Java Application":
   Select the project from step one. Open the debug launch configuration dialog using Run->Debug..., select "Remote Java Application", and click the button for creating a new launch configuration. The default values should be good, with your project from step one, and the port number matching the one from the command line or eclipse.ini.

P.S. Why am I putting this on my blog? I couldn't easily find the magic command line options for starting a VM in debug mode. Luckily, zx on IRC knows these kinds of things. Rather than writing it down on a piece of paper that I would lose instantly, I wanted to record it as a blog entry and then got carried away... but if I'm lucky, I will soon be able to google for "circular debugging" to find this page.

Levels of Abstraction

Reading through some of Dave Thomas' latest articles, I found this quote which I really like:

"The art of programming is about managing the half-truths at higher levels of abstraction in such a way that they are sufficiently correct to make progress, and sufficiently vague that they can be refined at the next level." (in Programming with Models - Modeling with Code)

Thought some of you might like it too.

(Thanks to Mike for writing about Dave.)