No Business Naming Things

A small bug (in implementation time, not importance) came in today regarding the working set drop down menu. It was a very reasonable request for the ability to have selection in this drop down exclusive rather than additive. Currently when you have multiple working sets and you select one in this menu it is checked. If you select another, it too becomes checked, and the window working set becomes the combination of the two working sets. This is fine most of the times but sometimes you really want that second check to switch the working set rather than augment it. Without such behaviour switching the working set requires two clicks or (god forbid) bringing up a dialog.

The above bug was addressed by adding code that would check the state of the primary modifier key (ctrl on Windows and Linux, cmd on OS X) and if it was depressed at the time of the click would invoke the switching rather than the addition behavior.

As it happens, we use this trick in several other cases… but you might never know it. For instance, if you hold down the primary modifier key and invoke an item from the run/debug pulldown menus it does not launch the selected session but rather opens it in the launch dialog for editing. This can be a very useful gesture that you’d have no way of knowing about without a) looking through the source code (NERD!) b) reading documentation (who does THAT nowadays?) or c) working with someone who knows everything there is to know about the platform (the power of omnipotence and osmosis).

So… we have useful features that you’d never know to look for. This seems like something we could have a UI guideline for at the very least and possibly even support in code. Imagine a little tip bubble appearing when you pop up a drop down menu that tells you what will happen if any of the available modifier keys is pressed. Do we have enough cases where this happens to justify the work? Hard to say.

I’m just procrastinating, don’t mind me.

Some time ago I was asked to help out with an Eclipse-based application. This drew me away from my workbench responsibilities for quite awhile and now that the other project is drawing to a close I find myself trying to re-integrate into the day to day life of an Eclipse developer. I’ve set out to start fixing certain small bugs as I encounter them and I found one today that instantly drew my attention - for some reason we were showing the Preference and Quit action on OS X not only in the Application menu (where they belong) but in the File and Window menus as well. I logged myself a bug, checked out a fresh copy of the workbench source into a fresh copy of I20060809 and set out to fix it. The fix involved tweaking the workbench window advisor and the carbon fragment that ships with the OS X version of Eclipse but after a short time I had a patch that addressed the issue.

Then deja vu struck.

Hesitantly I entered a quick search in bugzilla - bugs owned by me, on the Macintosh platform, that contained the word “pref” in the title.

Bug 73729 was returned in the results. Not only had this bug been noted before, but it had been assigned to me and I had already written an almost identical patch for it already.

That’ll teach me to let my attention to Eclipse lapse. She is a harsh mistress whose lessons do not go down easily.

Does this give anyone ideas? *coughscriptingcough*

class MyExecutionListener implements org.eclipse.core.commands.IExecutionListener {

    ... <snip uninteresting bits > ...

    public void preExecute(String commandId, ExecutionEvent event) {        if ("org.eclipse.ui.file.save".equals(commandId)) {            Command command = service .getCommand("org.eclipse.jdt.ui.edit.text.java.organize.imports");               if (command != null) {                    ExecutionEvent newEvent = new ExecutionEvent(                        command,                         event.getParameters(),                         event.getTrigger(),                         event.getApplicationContext());                    try {                        command.executeWithChecks(newEvent);                    } catch (Exception e) {                    }                }            }        }    }}

Summer can be really fun in Eclipse-land. We’ve just released, everyone is on vacation, and the plan for the next release is wide open and largely undefined. It’s time to play with weird and wonderful ideas.

Awhile ago I got it in my head that it might be cool if RCP developers had a tool that would allow them to totally control the plug-ins that their product is based upon. For instance, crop and remove problematic action sets, re-organize preference pages, rename editors, etc. One idea I had to accomplish this idea was to hook into the platform the ability to run the registry through a stylesheet on startup. I managed to get this working in the most minimal way awhile ago and recently people have been asking to see it. Until there is a suitable PR/plan item to attach it to I’ll just post the patch here for people to try out. No warranty, no support, etc etc. This patch was made against 3.2 but I’ve confirmed that it works with the latest code from head as of August 1 2006.

After applying the patch you can easily see the effects by launching your runtime workspace with the -Declipse.registryStylesheet argument. The value of this property should be a path to an XSL stylesheet. Below is an example stylesheet that can be used to remove the “line delimiter” action set from the file menu.

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">    <xsl:template match="actionSet[@id='org.eclipse.ui.edit.text.actionSet.convertLineDelimitersTo']">    </xsl:template>    <xsl:template match="node()|@*">        <xsl:copy>                <xsl:apply-templates select="node()|@*"/>        </xsl:copy>    </xsl:template></xsl:stylesheet>