ansaurus

Question

Answer 1

A:

This code looks very strange... is this supposed to be an Eclipse plugin? What are you trying to do? I'll guess that you are trying to create an RCP plugin with a User Interface. If so, here's the answer: Don't do that. Your OSGi Activator is not be responsible for creating the SWT display event loop.

Create an application extension in your plugin.xml to declaratively create the SWT bootstrap. It will look something like this:

   <extension
         id="application"
         point="org.eclipse.core.runtime.applications">
      <application>
         <run
               class="com.yourcompany.foo.Application">
         </run>
      </application>
   </extension>

Then create the Application class (call it whatever you want) to look something like this:

public class Application implements IApplication {

    /* (non-Javadoc)
     * @see org.eclipse.equinox.app.IApplication#start(org.eclipse.equinox.app.IApplicationContext)
     */
    public Object start(IApplicationContext context) {
     Display display = PlatformUI.createDisplay();
     try {
      int returnCode = PlatformUI.createAndRunWorkbench(display, new ApplicationWorkbenchAdvisor());
      if (returnCode == PlatformUI.RETURN_RESTART) {
       return IApplication.EXIT_RESTART;
      }
      return IApplication.EXIT_OK;
     } finally {
      display.dispose();
     }
    }

    /* (non-Javadoc)
     * @see org.eclipse.equinox.app.IApplication#stop()
     */
    public void stop() {
     final IWorkbench workbench = PlatformUI.getWorkbench();
     if (workbench == null)
      return;
     final Display display = workbench.getDisplay();
     display.syncExec(new Runnable() {
      public void run() {
       if (!display.isDisposed())
        workbench.close();
      }
     });
    }
}

Obviously make sure you have the SWT plugins (org.eclipse.ui) available in your Manifest as well as the runtime.

I hope that helps.

arcticpenguin 2009-10-16 17:43:13

No I'm not trying to create an Eclipse plugin. I'm trying to use SWT in an OSGi environment without Eclipse RCP. I know that the Workbench in RCP is responsible for creating the Display and that it is performed in the main thread before any plugins are activated. AFAIK it should be possible to create the Display in any thread, as long as it is used as the UI thread after that. From the doc:"In SWT, the thread which creates a Display instance is distinguished as the user-interface thread for that display."

Mattias Holmqvist 2009-10-17 07:15:33

However, I've learnt that Mac OS X requires that thread to be thread 0. That might explain why it works on windows but not on Mac. I don't know how to solve that though...

Mattias Holmqvist 2009-10-17 07:17:03

You want SWT without RCP but you want OSGi - seems strange. RCP is basically SWT and OSGi with a few other plugins that you don't have to use if you don't want them.

arcticpenguin 2010-06-11 22:15:27

RCP is much more than OSGi + SWT.

mklhmnn 2010-10-27 10:50:18

I would say more, not much more. I've been developing on that platform for 5 years so I'm quite familiar.

arcticpenguin 2010-10-27 13:18:17

Answer 2

+1 A:

I can confirm that we successfully run SWT Carbon on Mac OS X in its own event loop kicked off by a bundle activation, so it's definitely possible! This is using -XstartOnFirstThread when launching the VM.

But, with Cocoa SWT (64-bit), I see the same error :(

It seems that, although the way we ran Carbon SWT worked, it was probably not kosher: we were driving the event loop through another thread, not the main one as you're supposed to. Under Cocoa SWT, this doesn't work any more, and it was probably dodgy practice anyway.

I can fix the thread pool errors with the following hack before creating the Display (adapted from the Cocoa SWT Device constructor):

  NSAutoreleasePool pool = (NSAutoreleasePool) new NSAutoreleasePool().alloc().init();
  NSThread nsthread = NSThread.currentThread();
  NSMutableDictionary dictionary = nsthread.threadDictionary();
  NSString key = NSString.stringWith("SWT_NSAutoreleasePool");
  id obj = dictionary.objectForKey(key);
  if (obj == null) {
          NSNumber nsnumber = NSNumber.numberWithInteger(pool.id);
          dictionary.setObject(nsnumber, key);
  } else {
          pool.release();
  }

However, the event loop that follows hangs (i.e. the display.readAndDispatch ()/display.sleep () dance). I suspect it's just not reading UI events due not being the main thread.

I'm not sure if there's a kosher way to fix this. In my case, we control the main JVM thread that launches OSGi, so I'm toying with the idea of adding a hook in there that can run the SWT event loop after OSGi launch.

Matthew Phillips 2009-10-23 01:53:25

Is it possible to get hold of some simple code to get that up and running? And a working start configuration?

Mattias Holmqvist 2009-10-24 14:31:10

You've understood my question correctly. The last comment you're saying that you're looking to add a hook to run the SWT event loop. I believe that's supported by the Display class, once you've created the first instance of it in the main thread, the static methods will work as expected. At least if you believe the docs. From my understanding you will then be able to call Display.asyncExec(..) to execute code in the SWT event thread...that's how you do it in Eclipse at least.

Mattias Holmqvist 2009-10-27 22:22:53

Creating the Display instance in the main thread is the tricky part! We use a generic "bootstrap" class that launches the OSGi framework, and it has no idea about SWT or even access to the classes since they're actually loaded later by the SWT bundle.My idea is to add some sort of generic hook to the bootstrap code, which the SWT bundle will use to get its loop executed by the main thread. The trick is to do this cleanly...

Matthew Phillips 2009-10-28 05:15:27

That was my initial idea too. Then I was wondering if this wasn't provided already by OSGi in some way...

Mattias Holmqvist 2009-10-29 20:18:27

That would be nice, but I strongly suspect OSGi won't be helpful. AFAIK OSGi spits off a bunch of threads to launch the bundles, and doesn't particularly know or care about the main thread. But I could be wrong: looking at the spec might be a good idea at this point.If I get something working that might be generalisable, I'll post it here.

Matthew Phillips 2009-10-30 01:29:23

Just to expand: I have now successfully gotten an SWT OSGi bundle to run by allowing it to inject its event loop into the main thread (the one that kicks off OSGi) in combination with the -XstartOnFirstThread.

Matthew Phillips 2009-11-08 23:58:10

Answer 3

+1 A:

Thank you Matthew, I had the same behaviour and it got solved by using the first argument:

-XstartOnFirstThread

erwin 2009-10-23 10:41:30

Answer 4

+1 A:

Hi,

I had the problem that as soon as "display.sleep()" was called the Window freezed the application. If somebody else hace the same problem, the solution that worked for me was to add: -XstartOnFirstThread to the VM at the moment of the execution.

I was trying to make Areca Backup software work on my Mac, and know its working :)

My system is: MacOsX Snow Leopard 10.6.2

Bye, Daniel W.

Daniel 2010-03-29 03:30:52

Answer 5

A:

Howdy,

As it happens I work with Matthew and am trying to apply his technique using a different implementation of OSGi. It works for Knopflerfish 2.x (OSGi 3.x) fine but to get it working under Equinox (Eclipse 3.5.2, OSGi 4.1) I've had to play with a pair of properties:

osgi.parentClassloader=fwk or app
org.osgi.framework.bootdelegation=*

Unfortunately that screws up loading images from the local bundle for some reason.

So, two questions: did you get it working? And what OSGi implementation did you use? I'd just really like to use a modern OSGi implementation rather than resorting to the old Knopflerfish one, but at least I have that option.

Thanks.

Derek 2010-07-16 06:38:35

Answer 6

A:

I had the same issue and resolved it by adding both -d32 and -XstartOnFirstThread

John Ainsworth 2010-09-17 17:57:04

ansaurus

tags:

views:

answers:

Can't get SWT Display on Mac OS X.

related questions