Boris Bokowski

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!

Circular Debugging

2007-01-15T14:34:00.000-05:00

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:

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.
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;
```
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

2007-01-15T00:54:00.000-05:00

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.)

Scripting CVS

2006-03-23T03:20:00.000-05:00

Tonight, I created my first EclipseMonkey DOM - it allows you to check out CVS projects into your workspace from a script. I don't know when Bjorn will make the DOM available, but to whet your appetite, here is a script that shows how to use the DOM:


--- Came wiffling through the eclipsey wood ---
/*
 * Menu: CVS > Get JFace Data Binding
 * Kudos: Boris Bokowski
 * License: EPL 1.0
 * DOM: http://download.eclipse.org/technology/dash/update/org.eclipse.dash.cvs
 */

function main() {

 var repository = ":pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse";
 var projects = ["org.eclipse.jface.databinding", "org.eclipse.jface.examples.databinding", "org.eclipse.jface.tests.databinding"];
 var tag = "HEAD";
 for each(project in projects) {
     var module = project;
     cvs.checkOut(project, repository, module, tag);
 }
}
--- And burbled as it ran! ---

Halo Now

2006-03-21T14:23:00.000-05:00

http://www.eclipsecon.org/2006/Sub.do?id=113