Can't get SWT Display on Mac OS X

Question

I\'m running Mac OS X Snow Leopard and wan\'t to access the Display from the activator in an OSGi bundle.

Below is the start method for my activator:

@O         


        

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.