Damus et Capimus: December 2008

Monday, December 22, 2008

Directions to Keyboard Heck

Have you ever wondered where Keyboard Heck is to be found?

I think I just took the short-cut. So to speak.

I use the two-handed Dvorak keyboard layout because I like it:

I also use a MacBook Pro because I like it.

This week-end, I upgraded my OS X to version 10.5.6, because Apple told me it was a good idea.

Well, now text editing in the Eclipse workbench has gone all to pieces.

What has happened is that the following Mac-standard keystrokes still work as expected:

Command-Q to quit
Command-, for preferences
Command-W to close window (which closes the internal editor in Eclipse)
Command-S to save

but most others require combining the Command key with the letter key where it would appear on a Qwerty keyboard:

Command-; to undo (Dv ; is where Qw Z is)
Command-R for an outline (Dv R == Qw O)
Command-Shift-U to format (Dv U == Qw F)
Command-J to copy (Dv J == Qw C)
Command-K to paste (Dv K == Qw V)

The most frustrating point is that to cut (Command-X) I actually would have to hit Command-Q because the Dvorak Q is where the Qwerty X is, but Command-Q "works" in the Dvorak layout and closes my workbench! I have to do Command-J to copy, then delete, then Command-K somewhere else to paste.

I mustn't be as smart as Pavlov's dog, because I still find myself closing my workbench occasionally despite that it isn't the natural keystroke on this keyboard!

My next step was, when last I posted this message, to try this out on the Cocoa port of SWT. Well, it turns out that the Cocoa port does not have this problem. Keys all work like the rest of my Cocoa apps. The new problem is that Eclipse doesn't run, yet, with the Cocoa SWT. It crashed the first time I tried to save a Java editor and now it crashes before I can begin working with any editor, on every launch. That's no better than hitting Command-Q to cut ;-)

Thursday, December 18, 2008

Target Definition to the Rescue!

Congratulations to the PDE team for saving my day!

I just switched my day-job development from Windows to Linux. I use IBM Rational® Software Modeler™ every day for its various advanced features, and among other things the software that I develop extends some of its features. Therefore, I self-host my PDE.

As it happens, my software project also depends on other Eclipse-based components that are not included in RSM. So, I install them into my RSM workbench. On Windows, this works fine because I am an administrator of the system and p2 installs the stuff into the shared bundle pool.

However, on Linux, the picture turns out to be a very different one. I installed RSM as root but I run it as a regular user. It seems that some kind of funky extension to Equinox causes p2 to install my extra features into my home directory, and the launcher finds its configuration there instead of in the main product installation location. Very cool! Great for a multi-user environment.

However, not so great for my PDE target. PDE only recognizes the plug-in locations installed in the product, not this extra location in my home directory. Enter the PDE Target Definition.

drum roll ...

I use the New Target Definition wizard to create a new PDE target, and it creates one that includes my current Eclipse configuration by default. Then, I add another location in which it will find plug-ins. I could even, if I wanted to, add plug-ins from my workspace, although this seems odd because the workspace generally is implicitly in the target, anyhow.

With one click in the top right corner of the editor, this target is installed in my PDE environment and it now finds every plug-in that I need. It's too easy!

Wednesday, December 10, 2008

Who Knew? Comparing Directories in Eclipse

Well, isn't that a pleasant surprise to follow a rather unpleasant one.

After having spent much of the day working on OSGi-bundle-izing Apache Batik 1.7 in the Eclipse Orbit project, I discovered that the re-distribution of the W3C CSS SAC 1.3 API that is included in Batik 1.7 is, in fact, the real original content as provided by W3C.

"Great!" you might say.

No. The reason I know this is that what I actually discovered is that the re-distribution of the SAC 1.3 library in Batik 1.6 was a modification of the original W3C code, that I had bundled in Orbit way back when. Mostly, the changes are either just in the CVS ID in the header comment (Apache and W3C both checked the sources into CVS) or fixing typos in the doc comments.

My heart sank when I saw that one class, the CSSException, actually had functional changes. A bunch of its code was removed by the Batik team. Ugh. So, now the Orbit bundle that for so long has been touted as "the" W3C CSS SAC 1.3 API in fact isn't, and I have to figure out what kind of version number to apply now to make the new bundle look like the real deal over the old one. The org.w3c.css.sac_1.3.0.v200803081811.jar bundle is not authentic.

Anyhow, the real point of this blog is not to complain but to congratulate the Eclipse Team Team (tee hee). I had always used BeyondCompare to diff directory structures, but I don't have it on my current system and I was impatient, so on a lark I thought "Hey, let's see if I can do Compare With -> Each Other..." on directories in Eclipse. Well, of course I can! That's how I found my little Batik/SAC conundrum:

I should know by now just to assume that Eclipse can do these things. Silly me.

Good work, Team people! This is one more task that I don't need to escape my cozy workbench for.