Tag: swt

swtIbmWrapper (Not found in java.library.path)

When I’m doing proff-of-concept code for SWT based plugins for Notes I often times simply use a popup Shell constructed from Eclipse. This is much easier and faster than using a full Notes launch for this kind of stuff. After moving to IBM Notes 9 I had an issue with this approach and would see stacktraces like the below when trying to launch my shells.

23-01-2013 09:21:20 OS loadIBMSwtWrapperLibrary
WARNING:
Throwable occurred: java.lang.UnsatisfiedLinkError: swtIbmWrapper (Not found in java.library.path)
	at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1018)
	at java.lang.ClassLoader.loadLibraryWithClassLoader(ClassLoader.java:982)
	at java.lang.System.loadLibrary(System.java:506)
	at org.eclipse.swt.internal.win32.OS.loadIBMSwtWrapperLibrary(OS.java:6977)
	at org.eclipse.swt.internal.win32.OS.(OS.java:6993)
	at java.lang.J9VMInternals.initializeImpl(Native Method)
	at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
	at org.eclipse.swt.widgets.Display.(Display.java:139)
	at java.lang.J9VMInternals.initializeImpl(Native Method)
	at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
	at test_paint.BaseTest.run(BaseTest.java:17)
	at test_paint.Main.main(Main.java:17)
Exception in thread "main" java.lang.UnsatisfiedLinkError: org/eclipse/swt/internal/win32/OS.VtblCallWrapped(II)I
	at org.eclipse.swt.internal.win32.OS.VtblCall(OS.java:6997)
	at org.eclipse.swt.widgets.Display.init(Display.java:2828)
	at org.eclipse.swt.graphics.Device.(Device.java:138)
	at org.eclipse.swt.widgets.Display.(Display.java:490)
	at org.eclipse.swt.widgets.Display.(Display.java:481)
	at test_paint.BaseTest.run(BaseTest.java:17)
	at test_paint.Main.main(Main.java:17)

The solution was to add the DLL-directory (I’m on Windows) for the org.eclipse.osgi plugin to the native libraries location in my launch configuration. My Notes client is installed in C:Notes9 so the full path for Notes 9 Beta is “C:Notes9Dataworkspace.configorg.eclipse.osgibundles12001.cp”. Adding that in the build path dialog for org.eclipse.osgi solved the issue.

Developing an Eclipse plug-in from start to finish

Ryan Baxter from IBM who I had the honor of co-presenting with at Lotusphere just published a new article on the appdev wiki titled Developing an Eclipse plug-in from start to finish. The article takes you step-by-step through building a nice plugin and uses the Eclipse WindowBuilder (GUI editor) for taking the hassle out of building the UI.

A very nice Friday read.

Why all the talk about recycle() – how about dispose()?

Let me start by saying that I agree that recycle() could and should be handled by the API and there are numerous ways around it. I however also think that the majority of Notes developers out there will never have the need to call recycle() in their Java agents. There is a lot of talk about recycle() this and recycle() that but let’s face it – it’s not really a problem. If ever there is a problem with the Java API it’s not recycle() it is the fact that it has been left to stagnate and that it’s not keeping up with the Java language as a whole.

All this being said I wonder why so much talk and energy is being spent on recycle() and how come it is constantly being used as a reason not to move to Java and embrace the language. Looking at other API’s there are stuff that needs to be done. In the Java API it’s recycle() (whenever it’s actually needed) and in SWT it’s dispose(). I never see any SWT discussions on the dispose() method and DisposeListeners and using it as a justification for not choosing SWT and Eclipse as the fundation for an application. You judge a framework on what it does for you and not a single method in an API. Every API and language has quirks. Deal with it!

My post from 2006 (!!) has a lot more information on recycle() and why it’s there: Java in Notes/Domino Explained: The story on recycle()

Google saves the day for Notes plugin developers

Alan Cooke (member of the Redbooks team) just pinged me on Sametime and pointed me to a greate piece of news. As you might remember Google acquired Instantiations a while back. Instantiations developed a couple of developer tools for GUI building, code analysis and UI testing. Today all our prayers had been heard and Google is making all the tools from Instantiations free!!!. How sweet is that?!

The article referenced above describes the different tools and screenshots.

The reason this is important to you as a Lotus guy or gal is that WindowBuilder Pro for SWT makes it very easy to quickly mock up or build the GUI for your SWT based plugins. You simply drag’n’drop components onto the screen to build the UI. Think of the XPages UI but for SWT components. Very nice.

So how do you get the tools? Simply head over to the respective Google page to learn more and/or install. The direct links are:

Did I mention that all the tools are now free?!?

Once you go the tool page you’ll see a link to the “Download” page in the menu on the left. The page has links to update sites for easy installation. The tools work with Eclipse 3.4, 3.5 and 3.6.

P.S.: There is also a GWT designer tool (Google Web Toolkit) available (tool page is here). The tool is very nice if you develop GWT applications.

Detecting if a sideshelf view is detached

Found this great tip on how to detect if a view was detached from the parent windows that is if a sidebar plugin was opened standalone. I’m thinking that this could be very useful and used in a variery of ways to allow further functionality in a sidebar plugin if opened standalone. What could this be? Well a sidebar plugin could provide a richer UI and/or more resource intensive operations when the user opens the view standalone as this probably means this is an important application to the user.

Tip: How to detect that a View was Detached

How Eclipse improvements are important to Lotus Notes 8

Eclipse 3.6 (also called Helios) was just released the other day and with a new release of Eclipse comes a new release of SWT (the underlying widget framework). Among the many release notes you’ll find “Eclipse 3.6 SWT News and Noteworthy” outlining core SWT improvements.

Especially one of the improvements was of interest as I see how it could be used to improve Lotus Notes, the interaction with the OS and in turn the usability of the client. The feature is about the program representation in the program list normally shown in the bottom of the screen. Below are some samples. I could see this used to give feedback about unread e-mails, pending IM’s, progress of overall replication etc. Interesting stuff (see “TaskItem overlay image / text / menu / process” in the release notes).

How dynamic are your Notes sidebar plugins?

If you thought that the MyWidgets sidebar plug-in is doing some kind of dark magic to dynamically add sidebar plug-ins then think again. The purpose of my latest exploration into the World of Eclipse was to find out how I could do the same stuff. It wasn’t easy and took a while but it proved to be easier than I thought (once I knew how of cause). The plug-in I did is rather simple but shows how to dynamically add sidebar plug-ins and associate actions with it much like MyWidgets. If you want to see how it works check out the Flash movie. Now this has amazing possibilities…

As always – this isn’t your ol’ Notes client… 🙂

Drag’n’drop in SWT components

Those who went to my Lotusphere session already know this but doing drag’n’drop in SWT is actually quite easy. All you need to do is define a drag source and/or a drop target. The former is only required if a control in users should be able to drag data from a control in your code. The latter is required if you would like users to be able to drop stuff onto your component.

When setting up a drag source or a drop target you specify the control the source/target controls and the types of data you can provide/accept. These types are called Transfer types and are subclasses of the org.eclipse.ui.dnd.Transfer class.

Transfer types that might come handy – the class names should be pretty self-explanatory:

  • org.eclipse.swt.dnd.URLTransfer.getInstance()
  • org.eclipse.swt.dnd.FileTransfer.getInstance()
  • org.eclipse.swt.dnd.TextTransfer.getInstance()

Making a JFace viewer a drop target is simple passing in the underlying control:

DropTarget dropTarget = new DropTarget(viewer.getControl(),
   DND.DROP_DEFAULT | DND.DROP_MOVE);

Once the drop target has been created you set the transfer types:

final Transfer[] dropTransferTypes = new Transfer[] {
  type1,
  type2
};
dropTarget.setTransfer(dropTransferTypes);

The last thing you need is to add an instance of DropTargetListener or use a subclass of DropTargetAdapter as I do here:

dropTarget.addDropListener(new DropTargetAdapter() {
  ...
  ...
});

Creating a drag source is analogous.