No Business Naming Things

As a quick followup to the helpful article on themes posted to the Eclipse Tips blog, I would like to point out that all of the values that are in the currently active theme are also in the JFace registry. Yes, it is possible to get the current ITheme from the workbench IThemeManager, but that’s only REALLY useful if you’re interested in direct theme manipulation or you have non-color/font values that you’re trying to utilize via getInt/getString/getBoolean. If all you want to do is track the current value for a given element regardless of the theme that’s currently active you’re better off obtaining it from JFaceResources.getFontRegistry and getColorRegistry. The advantage to obtaining the value from here is that if you attach a listener to these registries you’re notified of changes not only when a value within a particular theme has changed, but you’ll get notified when the user selects a new theme. The workbench will always push the values in the current active theme into these registries.

Although particular to gaming cons, this post brings up a good question: what policies do Eclipse conferences espouse that protect (woman) attendees from unwanted interactions? Although I haven’t had my ass groped at EclipseCon I have had some experiences that have left me uncomfortable and a little shaken. I’m not alone here either. I’ve heard stories from at least one other woman attendee relating similar experiences. Being the stubborn loner that I am I never reported them but honestly, if I had wanted to, I’m not sure where I would have reported them too.

Given that we’re typically outnumbered by a very large margin, tech conferences have the potential to be an awkward place for women to be, particularly the shy and introverted ones like me. After a cursory inspection of the EclipseCon and Eclipse Summit websites, I can’t find any policies relating to interpersonal relations (or anything else) whatsoever. Would it be reasonable to expect this from our conference organizers?

I don’t intend this to come off as a flame to either conference or its attendees. The vast, VAST majority of attendees are civil, courteous, intelligent and thoughtful (even Steve) but there is always the possibility of a bad apple. I know from personal experience it would have been reassuring to know there was a policy in place and somewhere to turn if a situation occurred at a conference.

Ganymede is out the door! Hooray to everyone who helped make this happen!

Now get to work on Io(?) you slackers. It isn’t going to write itself.

Why is it that as every major release draws to a close some hoary, bizzare bug from the depths crawls to the surface like a creature from the imagination of Lovecraft? For this release I must point to bug 235847, a bug that somehow manages to destroy the help menu AND blank the Synchronize view in one fell swoop.

That which is not red

Is an eventual lie

And with strange builds

Even Kim may cry

… how many readers here are into face to face gaming?  Role playing, table top war gaming, board gaming, stuff of that nature.  If you are, how satisfied are you with the available tools that allow you to bring this hobby into the online space?

There was a lot of noise made about how e4 is a community affair. It’s a lie.

It’s all really about Steve Northover. We are merely satellites held aloft by his sheer awesomeness. So awesome, in fact, that we’ve abandoned our traditional splash screen in favor of a picture of him. It’s hard to condense so much awesome into 134,225 pixels but I tried my best.

ps: for the record, that guitar wasn’t pink and adorned with Hello Kitty before he touched it. It spontaneously became that way after he touched it. After he was finished playing it became so despondent at the loss of his touch that it immediately started crying. It’s still crying now, days later That’s how awesome we’re talking about.
pps: Awesome.

Hopefully this will be the last post with the words “startup changes” in its title for a very long time to come.

As mentioned previously, in 3.3 we prevent unknown Runnables from executing during the startup procedure via

and

. I last mentioned a strategy for avoiding use of such runnables during the initialization of editors. I believe that advice is still valid. However, there are scenarios where you may legitimately need access to these methods. Without them, for instance, Splash Screen implementors are forced to spin the event loop themselves if they want to do any clever UI work while the workbench is coming up. In an answer to this problem, we’ve added the new

class as API to the 3.4 stream. This class has one static method,

. Calling this method on any thread not created by the UI (ie: any user Thread) will allow that thread to access the Display.async() and Display.sync() methods as if they were one of our privileged startup threads.

For example:

package mail.example;

import org.eclipse.swt.SWT;
import org.eclipse.swt.events.PaintEvent;
import org.eclipse.swt.events.PaintListener;
import org.eclipse.swt.graphics.Color;
import org.eclipse.swt.widgets.Canvas;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.ui.application.DisplayAccess;
import org.eclipse.ui.splash.AbstractSplashHandler;

public class SplashHandlerWIthDisplayAccess extends AbstractSplashHandler {
        public void init(Shell splash) {
                super.init(splash);

                final Color[] color = new Color[] { splash.getDisplay().getSystemColor(
                                SWT.COLOR_YELLOW) };
                final Canvas canvas = new Canvas(splash, SWT.NONE);
                canvas.setBounds(0, 0, splash.getSize().x, splash.getSize().y);
                canvas.addPaintListener(new PaintListener() {

                        public void paintControl(PaintEvent e) {
                                e.gc.setForeground(e.display.getSystemColor(SWT.COLOR_BLACK));
                                e.gc.setBackground(color[0]);
                                e.gc.fillOval(0, 0, canvas.getSize().x, canvas.getSize().y);
                        }
                });

                Thread worker = new Thread() {
                        public void run() {
                                DisplayAccess.accessDisplayDuringStartup();
                                try {
                                        Thread.sleep(500); // sleep a little so we can see the
                                                                                // color change
                                } catch (InterruptedException e) {
                                }
                                canvas.getDisplay().syncExec(new Runnable() {

                                        public void run() {
                                                color[0] = canvas.getDisplay().getSystemColor(
                                                                SWT.COLOR_GREEN);
                                                if (!canvas.isDisposed())
                                                        canvas.redraw();
                                        }
                                });
                        }
                };
                worker.start();
        }
}

This simple splash handler creates a canvas on the splash shell that will initially have a yellow oval taking up the entirety of the drawing area. We then create a thread which declares that it will be used to access the display during startup. After a short nap this thread will set the color of the oval to green and cause a repaint. You can verify that without the call to

the oval will remain yellow until the splash comes down.

I wanted to give a heads up to anyone who’s currently using the org.eclipse.equinox.transforms projects that live in the Equinox incubator. They will be changing shape shortly in an effort to resolve some intractable build issues (alluded to previously). While providing transforms will be virtually identical there will be migration path for older transform bundles. I will outline the changes when the new code is in the incubator which I expect to happen sometime in the next week or so. In the meantime I’ve gone and tagged the existing code with Version_1 for any clients who were making use of it.

While applying a patch for the About->Plug-ins dialog the other day (a patch that gets us off of deprecated code.  Yay!) I was struck once again at how homely our certificate tray slide out is. It’s really quite ugly and it got me thinking: It’s an isolated piece of code; It’s a low-risk change; It’s potentially a very fun problem to work on (especially if you dig into the custom SWT controls).

It’s a perfect bug for some young would-be committer to step up to.

While trying to clean up and refactor the Equinox XSLT transform code (a moderately complex Equinox framework extension broken out among several bundles) that I wrote last year I find myself in one of three situations:

1. I can have code that doesn’t compile without discouraged access warnings but works just fine in a running instance.
2. I can have code that compiles cleanly but wont actually work in a running instance by virtue of how Equinox loads framework extensions.
3. I can have code that compiles cleanly, runs fine, but is held together by spite, twine, and reflection.

Sigh.

Some days you’re the windshield, other days you’re the bug.