Damus et Capimus: 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.

Thursday, November 20, 2008

OCL: Who Cares?

This week, the OCL 2.1 RTF has had to re-launch the voting on its first ballot, because it failed to reach a quorum. With a 10-member voting list, 2 votes just didn't cut it. And these were the two companies that put some effort into resurrecting this specification by addressing a substantial number of issues.

It's disappointing to see that there is so little interest from the OMG membership in the health of this specification that should, and I think was intended to be, a cornerstone of the the MOF architecture. There is still interest in the user community, judging by the continued influx of issue reports.

No metamodel is complete without constraints that specify the well-formedness of instance models. And OCL could be a key tool in that department, if it can keep up with the evolution of MOF and UML. Indeed, it already seems to be an important part of several Eclipse modeling technologies, as I hope to demonstrate at EclipseCon 2009. However, the current state of the specification makes the implementation of conformant tools difficult and interchange of OCL models impossible, because the language is imprecisely and inconsistently specified (some bits aren't really specified at all).

A few of us are working hard to reinvigorate and reform this specification, but we need help. With just two OMG members involved at this point, it is difficult even to get through a vote, and I worry about how relevant the product will be that results from such a small collaboration. So, pitch in with your time (it doesn't take much) and elbow-grease to make OCL succeed! Let's not let this thing go the way of the dodo.

Tuesday, November 18, 2008

And Now I Lay me Down to Sleep ...

Well, it looks like it must be winter, because I see Orion high in the sky outside my window. I don't know how it is, but there is something comforting about the onset of this season, and those early nights when the great Hunter rises to watch over those of us that dwell in the northern hemisphere. I can almost feel his presence.

The fire in the grate dims, and even Tess has stopped purring and is huddling close for warmth. I ask myself, What have I done for her lately? Dished out a can of wet food, cleaned the litter pan, washed the water fountain. And what has she done for me? Only offered me the simple, unconditional, absolute affection of one of nature's most perfect animals. I feel that I have got the better part of this exchange.