Archive for the ‘Apple’ Category

Apple
Growl support for Eclipse RCP

July 5th, 2009

On Mac OS X, Growl has become the de facto standard for all notifications. There is an opened bug asking for Growl support in SWT/RCP : Bug 209911 – [Mac] Support for Growl notifications.

The best solution would be to have a standard API for notification with support for notification plug ins (including growl) and this is exactly what is discussed on bug 209911 and on the wiki page for Platform UI/Notifications.

But for those wanting to add Growl support to their applications as soon as possible, I’ve just attached to bug 209911 a plug-in which can successfully send Growl notifications.

Growl Action

Growl Action

Growl Notification from Eclipse

Growl Notification from Eclipse

The Growl wrapper depends on Apple’s Java/cocoa bindings, so the trick was to add external libraries to the plugin classpath :

Bundle-ClassPath: .,
external:/System/Library/Java

It works, but you should know that :

  • Apple Java/Cocoa bindings are deprecated.
  • This does not work with Cocoa/x86_64, probably because of the deprecation. There you get the following error :java.lang.UnsatisfiedLinkError: /usr/lib/java/libObjCJava.A.dylib: no suitable
    image found. Did find: /usr/lib/java/libObjCJava.A.dylib: no matching
    architecture in universal wrapper

Hopefully, the Growl wrapper is a really small class, and it should be rather easy to rewrite it with SWT’s internal Cocoa packages for someone who knows Cocoa (I don’t). If you want to take a look at the wrapper, just download my attachment to Bug 209911 and take a look at the class : com.growl.Growl.

Sharemedia
Eclipse 3.5 RC3 released : Cocoa works great

May 31st, 2009

Eclipse 3.5 RC3 is out and this release fixes the last issues (Bugs 277539 and 277437) I was seeing when running the best test suite I have, ShareMedia, on the previous 3.5 RC2 Cocoa x86_64 SWT port.

Now everything is working, even the most tricky parts such as custom widgets, Open GL with LWJGL and animations…. :-)

ShareMedia running on SWT 3.5 Cocoa x86_64

ShareMedia running on SWT 3.5 Cocoa x86_64

The new 3.5 release also brings some long-waited features on Mac OS X :

- Java 6 and 64 bits support

- Shell modified hint

Shell modified hint

Shell modified hint

- Shell sheet style

Shell sheet style

Shell sheet style

- Program icons are now returned in full size !!!! Program.findProgram("jpg").getImageData() returns beautiful 512×512 icons instead of 16×16, see the following gallery widget snippet :

Gallery Snippet on SWT 3.4

Gallery Snippet on SWT 3.4

Gallery Snippet on SWT 3.5

Gallery Snippet on SWT 3.5

UPDATE: Oh no ! this is a cocoa bug, images should still be returned in 16×16. SWT committers, please don’t fix it ! :-) I hope this will help fixing bug 181723.

These improvements make Eclipse 3.5 an absolute must for all Mac users.

The only thing I’m still missing is the Native OSX toolbar (bug 222859)

I would like to thanks all developpers who worked very hard to create this great Cocoa port in only one year and those who keep hacking to improving Eclipse UI on Mac.

Apple
Workaround for maven/svn issues on OSX Leopard

December 7th, 2008

–non-interactive flag prevents svn from getting credentials from OSX keystore. As a result you cannot authenticate on password protected svn servers.

Add this script ahead of svn in your classpath and you will be able to use the maven-release-plugin again on Leopard :

#!/bin/sh
if [ "$1" = "--non-interactive" -o "$1" = "--username" ]; then
shift
fi
if [ "$1" = "--non-interactive" -o "$1" = "--username" ]; then
shift
fi
/usr/bin/svn "$@"

Script taken from http://blogs.exist.com/bporter/2008/02/25/working-around-non-interactive-problems-in-leopards-subversion/

Sharemedia
Reopening SWT bug 141282

November 8th, 2007

I spent several hours to locate a SWT problem with DND and special characters in path on OSX. The hard part was that strings were are correctly displayed by SWT and work with the file API. But if you try to compare or check equality of this string with another one, it always fails because a special char uses 2 chars instead of one. This is only an encoding problem, but not easy to find.

See Bug 141282 on Eclipse
and Bug 97 on ShareMedia bugtracker