I don’t (always) like the ways Eclipse provides me to do long running operations. So I created another way with a nicer UI.

With the Jobs framework the Eclipse IDE provides some means for long running operations. The Jobs framework is able to run tasks in a parallel fashion and queue the rest, while providing user feedback with progress monitors. Other RCP applications have different needs when doing long running operations.

Specifically the Job frameworks UI feedback is not always what an RCP application wants. Sometimes I find that I’d rather prevent the user from clicking in the UI than queue more jobs. This happens for example if the user action triggers a network access that might take a while. There is no point in accepting the same user action again. So I want to provide a nice feedback mechanism to the user that their click is being processed.

Eclipse provides a progress monitor dialog. It’s a modal dialog that shows a process to the user and prevents her from clicking in the workbench. Personally, I don’t think it’s very appealing. Also, it’s not what I want… while I want some view being blocked often other views should stay operable.

I don’t know anything that means my use case from Eclipse so I created a few classes myself that take care of a presentable way to block workbench parts. Basically it’s a transparent shell that lays itself over a given control and displays a SWT ProgressIndicator widget. It responds to the controls re-size, move and disposal events… and looks quite neat! Way better than the progress modal dialog, and it leaves it up to the programmer which part of the UI should be blocked.

From the programmers point of view, I took the approach we find in Eclipse all the time: The programmer has to implement some “I..Runner” interface that is custom to my API.
It contains a run method that takes an IProgressMonitor and is called outside the UI thread.
My aim was to make the different steps during and after the long running operation as clear as possible to the programmer and reduce their need for inner classes. Unlike the Eclipse API I don’t think that it’s the users responsibility to sync back into the UI thread. This use case is common and creates unnecessary bloat in the source code. Therefore I provide 2 methods that are called within the UI thread after the operation is done, one for doing the actual feedback for the user and one for exception handling (if necessary).

public interface IResponsiveRunner {

/**
* called from without the UI Thread
*/
public abstract void runOutsideUIThread( final IProgressMonitor monitor ) throws Exception;

/**
* called after {@link #runOutsideUIThread(IProgressMonitor)} from within the UI Thread
*/
public abstract void uiFeedbackAfterRun();

/**
* Called within the UI thread. This method is called if an error occurs during execute before
* {@link #uiFeedbackAfterRun()} is called.
* @param caught
*/
public abstract void handleException( final Exception caught );
}

This is what a programmer has to implement. Starting the nifty progress report is very similar to using a progress monitor dialog, instantiate and run:

new NiftyProgress( myResponsiveRunner, new TransparentUIBlocker( control ) ).run();

The TransparentUIBlocker is the class that does the actual blocking. It’s passed in under a generic IUIBlocker interface that might have other implementations.

So, as a programmer, you provide an implementation of the IResponsiveRunner and point to a control that should be blocked, and you’re done. Nifty feedback to the user.

I attached a zip with plug-in projects with the classes and a small application that makes use of them. Use it, it’s EPL.

Oh, and if someone can tell me how to get notified if a view is hidden behind another one in a view stack, please do.

We recently moved our continuous integration builds to a new server. The builds are set up self-contained or have only little dependencies to files outside their workspace. So it shouldn’t be a big deal: Just set up the new projects in your CI server and copy over the settings from the old projects, right?

And if you then get an error that even Google knows only 2 pages of useless results about, you start scratching your head. At least I did after I got this one:

java.lang.UnsatisfiedLinkError: no swt-pi-gtk-3346 or swt-pi-gtk in swt.library.path, java.library.path or the jar file

It gets a bit more mysterious when you start looking for the swt-pi-gtk libraries, locate them in one of the SWT fragments, and you make sure that all your “-os” “-ws” and “-arch” options are set correctly.

To make the long story short, the solution was to install GTK on the new server…

Tags: eclipse, swt

This semester my wife gives a lecture in theoretical computer science at the KIT (Karlsruhe Institute of Technology). The current topic is decidability and therefor the students learn about the halting problem. The whole topic is rather dry and good examples for illustration are always welcome.

One example I liked is the question whether a program is a virus or not. As a proof, you could reduce the halting problem to this problem, but it is far better illustrated by giving a self-referencing program (the formal proof then would be based on diagonalization):

Let P be the program that decides whether A is a virus. Then you could define your virus A as:

if P(A) then exit;
else infect();

Great, isn’t it? The virus knows the virus-detector P and doesn’t behave as a virus if P can identify it as a virus. If not, it’s evil. q.e.d.

That’s the theory. Let’s have a practical look at it.

First of all, it seems that the virus author is a pretty bad program designer – we usually try to avoid circular dependencies. But, being pragmatic I’m willing to compromise where it is necessary and in this case I must (unless I want to reduce the halting problem).

What seems more awkward to me is that the virus depends on P to being a behavioral analysis. Antivirus programs actually do behavioural analysis to detect viruses. And although I can’t find a link of proof between all the antivirus ads in Google I remember at least one headline where a root kit detected antivirus software and clouded itself against it.
But Antivirus programs also do statical analysis. In statical analysis the code isn’t run but only looked at. And any P that does statical analysis would find infect() (hopefully, if the heuristics work) and thus mark the self-clouding virus as virus anyway.

Of course this does not invalidate the proof that I hinted to above. I really like it as example for decidability. It works if you define “virus” as a program with malicious behaviour.
It’s sad that in practice we can’t always restrict our environment as we need it – unless we just write a “Hello World”.