Не может получить Дисплей SWT на Mac OS X
Я не ожидал бы, что интервьюируемый прокомментирует их код (предполагающий, что они писали его на месте в интервью). Если бы я брал интервью у кого-то испытанного, хотя, и им не удалось расположить код с отступом, то это, конечно, говорило бы против них. Я не ожидал бы, что добавление отступа будет прекрасно, или в стиле мне понравилось, или что-либо еще. Но это должно быть расположено с отступом. Это - часть записи кода.
, Если я принимаю на работу кого-то неиспытанного (и я обычно) тогда это не имеет значения. Но я не собираюсь просить, чтобы они записали двунаправленный связанный список также.
3 ответа
Я могу подтвердить, что мы успешно запускаем SWT Carbon на Mac OS X в его собственном цикле событий, запущенном активацией пакета, так что это определенно возможно! При запуске виртуальной машины используется -XstartOnFirstThread.
Но с Cocoa SWT (64-разрядная версия) я вижу ту же ошибку: (
Кажется, что, хотя способ, которым мы запускали Carbon SWT, работал, это, вероятно, было не кошерно: мы вели цикл обработки событий через другой поток, а не основной, как предполагалось. В Cocoa SWT это больше не работает, и в любом случае это, вероятно, была хитрая практика.
Я могу исправить ошибки пула потоков с помощью следующего взлома перед созданием дисплея (адаптировано из конструктора устройства SWT какао):
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();
}
Однако следующий за ним цикл событий зависает (т.е. display.readAndDispatch () /display.sleep () танец). Я подозреваю, что он просто не читает события пользовательского интерфейса из-за того, что не является основным потоком.
Я не уверен, есть ли кошерный способ исправить это. В моем случае мы контролируем основной поток JVM, который запускает OSGi, поэтому я подумываю добавить туда ловушку, которая может запускать цикл событий SWT после запуска OSGi.
Этот код выглядит очень странно ... это должен быть плагин Eclipse? Что ты пытаешься сделать? Я предполагаю, что вы пытаетесь создать плагин RCP с пользовательским интерфейсом. Если да, то вот ответ: не делайте этого. Ваш OSGi Activator не отвечает за создание цикла событий отображения SWT.
Создайте расширение приложения в вашем plugin.xml, чтобы декларативно создать загрузочную программу SWT. Это будет выглядеть примерно так:
<extension
id="application"
point="org.eclipse.core.runtime.applications">
<application>
<run
class="com.yourcompany.foo.Application">
</run>
</application>
</extension>
Затем создайте класс Application (назовите его как хотите), чтобы он выглядел примерно так:
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();
}
});
}
}
Очевидно, убедитесь, что у вас есть плагины SWT (org.eclipse.ui), доступные в вашем манифесте а также время выполнения.
Надеюсь, это поможет.
У меня возникла проблема, заключающаяся в том, что как только вызывается "display.sleep ()", окно "замораживает" приложение. Если у кого-то еще возникнет такая же проблема, решение, которое сработало для меня, заключалось в добавлении: - XstartOnFirstThread к виртуальной машине в момент выполнения.
Я пытался заставить программу Areca Backup работать на моем Mac и знал, что она работает :)
Моя система: MacOsX Snow Leopard 10.6.2
Пока, Дэниел У.