Why doesn’t Eclipse/Installation Manager work on Linux?

For the next time I’m grumbling about yet more incompatibilities causing problems with Eclipse on Linux, adding the following properties to the bottom of the launcher configuration file seems to help:

-Dorg.eclipse.swt.internal.gtk.useCairo=false
-Dorg.eclipse.swt.internal.gtk.cairoGraphics=false

For example, edit the install.ini file for Installation Manager, which is where I first encountered problems after updating Red Hat Enterprise Linux last year. The problem appears to be due to incompatible GTK and Cairo versions, and there’s a related IBM technote for Installation Manager on RHEL 6.6.

Unfortunately, while that was enough to get Installation Manager working, the Eclipse IDE still seems somewhat unstable. I been exporting the following environment variable for a while but, based on the SDK Known Issues wiki page, maybe that doesn’t make any difference with recent versions:

export GDK_NATIVE_WINDOWS=true

Another suggestion I’ve seen recently, related to tooltips, is to export another environment variable, although so far I haven’t tried it:

export GRE_HOME=/dev/null

Need to experiment a bit more with those last two, and see if I can narrow down whether there are any other real problems.

Advertisement

MQTT Joggler

Spurred on by the success of getting Mosquitto working on a Raspberry Pi, I recently had a play with MQTT on the Joggler. The O2 Joggler is still a great device for hacking and I currently have SqeezePlay OS running on it.

The reason I wanted to try and get MQTT on the Joggler was to make use of its light sensor, and publish light levels over MQTT. It all turned out to be pretty simple since most of the work has already been done by other people!

• Andrew de Quincey has code to read the Joggler’s light sensor
• Andy Piper has a handy quick start guide for Paho
• The MQTT C client documentation has simple publish examples

First thing to do was read the light sensor and get that working with an MQTT client. I had to skip some of Andy’s instructions and just built the client code rather than attempting to get doxygen working. Once I’d mashed up the light sensor code and publish example I could compile the worlds most pointless MQTT publisher:

gcc -Wall publightsensor.c -L../bin/linux_ia32 -I../src -lmqttv3c -lpthread -o publightsensor

Next it was time to check the results. This too was quick and easy thanks to the MQTT sandbox server, which has a handy HTTP bridge. And the final result… was a completely unscientific and slightly dingy light level 4! Now I’ll be able to turn on a lamp using an unreliable RF controlled socket and see whether it worked or not!

Update: the code really is all in the existing examples but I’ve created a Github Gist in case it’s any help: mqttjogglermashup.c (11 February 2013)

Checkbox fail

Apologies if this is a repeat grumble, but every time I export an EAR file from RSA the dialog box annoys me. Well, that’s a bit unfair, it’s not the whole dialog box, just one very pointless checkbox on it…

So the first time I attempt to export to a destination which already exists, I get a helpful error preventing me doing something potentially stupid. When I know that I’m just re-exporting the same EAR and I’m happy to just overwrite the old one (which probably wasn’t working because I forgot to include something important) I just need to check the “Overwrite existing file” box to make the error go away and I can hit finish. Lovely… except that the dialog remembers this option next time I come to do an export! Basically it may as well not exist after the first export.

It’s actually a bit of a love hate relationship with this little checkbox though, because if it always defaulted to unchecked I think I’d much prefer it to having a dialog popping up asking whether I want to overwrite an existing file. Oh well, almost useful.

Anyway, it’s Friday and time to go home; check.

Eclipse local history

Aha, looks like Cerys beat me to posting this tip! She’s much better at explaining things, so I recommend reading her post on the Eclipse local history. Here’s a screen shot to go with it:

Generated… not

Using JMerge makes it easy to combine generated code with custom code, preserving any modifications when re-generating. So, for example, you might have this generated code:

/**
  * some generated code which hasn't been modified
  * @generated
  */

public void doSomething() {
   // anything here can get overwritten when the
   // code is regenerated
}

Which you might modify:

/**
  * some generated code which has been modified
  * @generated NOT: added important bit
  */

public void doSomething() {
   // really important stuff which I don't want overwritten
   // when the code is regenerated
}

Nice but, having a short memory, I need a way to keep track of all these modified bits of code and luckily the Java task tag feature in Eclipse comes to the rescue with a simple solution. Open ‘Window > Preferences…’ in the main Eclipse menu. Find the ‘Java > Compiler > Task Tags’ page. Press the ‘New…’ button and enter the following details:

• Tag: “@generated NOT”
• Priority: Low

Problem solved: the tasks view will list everything you changed!

Eclifox on alphaWorks

It’s great to see Gautham announce that Eclifox has made it on to alphaWorks. There are a lot of things I like about Eclipse and this looks like a really interesting extension, although I must admit I do get a bit concerned when you try to do ‘too much’ in a web browser.

Will definitely be downloading this bit of alphaWorks for a play soon.