A couple of days ago I posted a little something about Contexts in the eclipse Core expressions framework. What I said was the only thing you were probably interesting in the standard ISource was the “activeContexts” variable. That  was a little misleading of me. There  are several that are potentially useful, but I’ve not been using them, since what I’ve been working on doesn’t really lend itself to most of them.

The “selected” variable lets you access whatever is “globally selected” under your mouse. Depending on the view you’re acting on it can consist of 0 or more entries of type “Whatever”.

As I have written previously, if you’re working on a View whose selection can affect the whole application, then you’re going to need to add:

getSite().setSelectionProvider(viewer);

Somewhere in the ViewPart class. All this does is register that viewer as a SelectionProvider with eclipse in its ISelectionService. That Viewer can now make its selections known to the UI itself.

To make use of this, you’ve got to delve into the Core expressions. The easiest thing to do is to create a “definitions” extension point and create the expression in there – that way you’ll be able to reuse it. One I’ve used is:

<definition
  id="category.definition">
  <iterate ifEmpty="false" operator="or">
    <instanceof value="TreeNode"></instanceof>
  </iterate>
</definition>

This one basically says “If anything out of what I have selected is of type “TreeNode” then this expression evaluates to true. In order to use this with a Handler, you’d use the following…

<activeWhen>
  <reference definitionId="category.definition"></reference>
</activeWhen>

Makes sense, no?

I’ve finally made some changes to the look of the site. These are:

1. I’ve moved the Wordpress installation up a level, and stuck a 301 redirect in the .htaccess. Watch Google b0rk like a muthafucka.
2. Replaced an h1 header with my awesome logo, that was awesome when I made it, but is of too low a resolution. Annoyingly I can’t remember how I made it and I’m shit with photoshop. This will probably get redesigned soon enough…
3. Fiddled with the Wordpress theme. It now defaults to a width of 800, not 660. Anyone still running their monitor at 800×600 can shove it up their arse.

Now I guess it’s Wordpress upgrade time…

I’ve just spent an hour and half on this one…

If you want the eclipse UI to know what you’ve got selected under your sticky little mouse, for the purposes of Core Command checking, then you need to include something akin to this in your View class:

getSite().setSelectionProvider(viewer);

Where viewer is the name you’ve given to the viewer class (Either TreeViewer or TableViewer in most cases), otherwise eclipse won’t register your viewer with its SelectionService, and won’t know when you’ve got something selected.

Just a little something to show that I love you. Kiss kiss.

One of the things that has pissed me off more than anything else throughout my odyssey with eclipse RCP has been the utterly, UTTERLY awful documentation for the declarative Commands framework. I’m sure you know the basics…

• You define “Command”s as xml entities through your plugin.xml / extensions browser. They shouldn’t contain anything more than presentation information. They are then included on menus and Tool/Coolbars.
• Unless there’s some behaviour associated with that “Command” that is Always available – where you provide a link to the class that implements that behaviour as a “Default Handler”
• A Handler is the implementation that is associated with a given Command. If they’re not always available, then they should be defined in the “Handlers” extenstion point.

Now, this is where it got me… Most of the time you need to stop idiot bastard users from clicking on the “Commit” button when there isn’t a Database connection, or whatever. So you need to ghost the menu / toolbar items, right?

However, in eclipse, you don’t get hold of the widget itself and set it to a “ghost” state, you actually need to disable the implementation, so that there are no active handlers for that Command. The Command itself is still there, but since eclipse hasn’t got anything for it to do, it’s disabled, right?

OK – so here’s the thing. There’s an arcane language for logical assessment, all part of the Core Expression Framework. Just so you don’t think I’m being mean for the sake of it, this is the eclipse wiki page for it:

http://wiki.eclipse.org/Command_Core_Expressions

Clear as dogpiss? Hmmm?

(more…)

OK, so the last post I made wasn’t quite what I mean to say. It’s not custom contexts, that’s something else. What I was talking about was custom ISources (When you’re defining core expressions, these are the Variables that you want to stick in the “with” elements and such.)

Well, rather than explain it all away, I’ll just post a link to the eclipse news posting that turned me on to how to use it. You see, when you write functionality, it’s REALLY important to make sure that potential users have to root about in newsgroups for getting on for a week before they get half of an idea (Which is normally all I end up getting, since I’m obviously fuckin’ thick…) and that when posting on newsgroup you get a “upgrade to 3.4″ or plain ignored.

For the record – “I’m stuck with 3.3 until I get a finished product. Then I can *think* about upgrading, this isn’t an answer, it’s you grabbing your nuts and making obscene gestures in my direction.”

Anyway, minor rant over.

For custom ISources, check out http://dev.eclipse.org/newslists/news.eclipse.platform/msg66913.html. Bear in mind that the EvaluationService is a restricted package in 3.3, since it’s internal. If you’re using 3.4. I suppose you should use the IEvaluationService interface. Can’t remember which package it’s in, though…

Right, NOW for contexts…

I’ve just spent about three weeks looking for a way to enable / disable handlers (Read “ghost menu items / Commands”). In eclipse 3.3., when the Standard ones just won’t cut it. Like when stuff gets turned on / off depending on something slightly more complicated than having a ViewPart selected, or an Editor in use.

It’s a cockache and a half…

Full instructions will follow once I’ve managed to implement it all, but basically you need to write your own Context and ContextSourceProvider, then add the new SourceProvider to the Platform IHandlerService and IEvaluationServices.

Actually, I still don’t really understand the example it’s taken me a thousand years to find, since there are no decent explanations of how the Core Expressions language fucking works.

Eclipse Developers, SORT IT FUCKING OUT.

When you run eclipse or an eclipse based application it runs, by default, in javaw – so there’s no console and it seems to be a bit funny about what exceptions it logs, and which it catches itself. Unless you’re explicitly writing possible exceptions to log files, surrounded by great big “Look here” statements, you may never, ever see them. The solution is to have eclipse (or RCP) running as a standard java app with a console.

This is a piece of piss

%eclipse -vm {LOCATION OF YOUR JAVA.EXE}

Oh, and I’ve not forgotten about the RCP config files, but they’re taking up a bit of writing and I’ve got other things to do with my life.

If you’re writing a non-trivial RCP app under eclipse the chances are you’re going to be using a couple of extra plugins that provide additional functionality. Probably including:

• org.eclipse.ui.editors
• org.eclipse.ui.workbench.texteditors

I mean, this makes sense, if the functionality’s already there you may as well use it, right? Allow me to introduce a little friend

These little cunts are contributions that get added by plugins, so unless you’re going to alter the Plugin they come from itself (Note to you, don’t be retarded) you need a way to hide them. For some FUCKING REASON this is made a whole lot harder than it needs to be. Especially since documentation is a little thin on the ground. First up, you need to work out which contributions are being added. ActionSets are the usual culprits. You should be able to find out which ones are enabled easily enough, so I’m not going to show you how to do it.

Once you’ve found out, In ApplicationWorkbenchWindowAdvisor.java, override the postWindowOpen() method and give it something like this…

@Override
public void postWindowOpen(){ 
  IWorkbenchPage page = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage();
  page.hideActionSet("org.eclipse.ui.edit.text.actionSet.navigation");
  page.hideActionSet("org.eclipse.ui.edit.text.actionSet.annotationNavigation");

  ...

}

And hey presto. The actions you didn’t want and didn’t ask for in the first place are gone.

So the first application I’m working on at this new job of mine is an eclipse RCP application that will allow the users to perform a task that is currently dull, boring and scripted.

I like RCP, it’s got a good feel to it – however, there are more than a couple of problems that I’ve encountered.

• It’s a *rapidly* evolving and changing platform. Although the eclipse team don’t put out a release more than once a year, books tend to take a bit longer than that to write, print and proliferate. The only entry level textbook that seems to be kicking about is [McAffer Lemieux], which was written for eclipse platform version 3.1 – June 2005. I use 3.3…

• Related to the above. The eclipse community, whilst I’m sure very willing, suffer from developer syndrome – every FUCKING thing is, for the most part documented for people who have an understanding of the last version, or related systems. There are always tutorials kicking about, true, but these are often much simpler than is required

• No matter what they tell you, it’s hella-complicated. It’s a piece of piss to get one up and running, thanks to the really-pretty-good wizards that build the basics for you. (I’ve not met anyone so far who’s not used them to get their initial project state up and running). However, when you do something to a configuration file and it breaks everything you’re pretty much fucked, unless you’re going to spend a day fixing the problem you’ve just introduced – screaming at the eclipse newsgroups and hunting wildly for something valid for eclipse 3.3.

So here’s my plan, I’m going to document, in as simple a set of terms as I can, exactly what I’ve discovered about the configuration files required for an RCP app, probably dedicating one article to each. To kick off with I’m just going to explain what the damn things are called…

First of all, there are (basically) three categories of config files.

1. Files for the plugin(s) that provides the functionality you want the end product to have
   1. plugin.xml
   2. MANIFEST.MF
   3. *.target
   4. plugin_customization.ini
2. A file that describe the entire RCP as a product
   1. *.product
3. Files that control the building of the application
   1. eclipse based build
      1. build.properties
   2. ant / PDE build headless builds
      1. build.xml
      2. build.properties

Each one of them needs to be more or less perfect in order to get the application building, and they all depend on each other, in more or less the order listed above. I’ve intentionally left out the source files that are required to get the configuration right, since they’re mainly covered in tutorials that can be found with a little googling.

Next stop, plugin.xml. Whooo!

OK, I admit that I was too lazy to write my own fucking webpage. I accept that by using an open source package I’m going to have to make a series of design sacrifices in the name of getting shit done, but why, WHY, do all of these packages have to have their own ingrained little terminologies. Why do I have to:

1. Write my own set of webpages embedding the php elements for “article” or whatever in them. BUT, do it eight or nine times.
2. Hack someone else’s code to pieces just because at the time I downloaded a set of pages (see above) it was the least shittily presented, and the only starting point that didn’t make me want to crush kill destroy.

Fucking wack.

First step, get this motherfucker looking better. Second step, take a crowbar to the WordPress technical steering team.