Описание тега swt-awt
swt-awt означает мост, разработанный с целью сосуществования приложений SWING и SWT в одном приложении.
Введение
Swing и SWT иногда рассматриваются как строго конкурирующие технологии. Некоторые люди имеют твердое мнение о том, какой инструментарий пользовательского интерфейса использовать исключительно для клиентских приложений. Однако в реальном мире идеологические крайности часто неосуществимы. Некоторые допустимые варианты использования требуют, чтобы обе технологии сосуществовали в одном приложении. Хотя смешивание двух наборов инструментов - непростая задача, это можно сделать, и это можно сделать так, чтобы эти два набора инструментов были легко интегрированы. В этой статье обсуждаются шаги, необходимые для достижения хорошей интеграции Swing/SWT. Он фокусируется на варианте использования встраивания существующих компонентов Swing в приложение Rich Client Platform на основе SWT.
(Гордон Хирш, SAS Institute Inc. Авторские права © 2007 SAS Institute Inc. Сделано доступным в рамках EPL v1.0 20 июня 2007 г.)
Использование моста SWT/AWT
Мост SWT/AWT был частью SWT с версии 3.0. Это очень простой API, расположенный в пакете org.eclipse.swt.awt. [Заметка]
В этой статье основное внимание уделяется внедрению кадров AWT в композиты SWT. Он демонстрирует только половину моста SWT/AWT. Тем не менее, большинство описанных ниже улучшений применимы и к другому направлению: встраиванию композитов SWT внутрь фреймов AWT.
Как минимум, встраивание кадра AWT в композит SWT - это всего лишь две простые строки кода.
Composite composite = new Composite(parent, SWT.EMBEDDED | SWT.NO_BACKGROUND);
Frame frame = SWT_AWT.new_Frame(composite);
Экземпляр org.eclipse.swt.Composite создается в стиле SWT.EMBEDDED. Этот стиль указывает на то, что кадр AWT должен быть встроен в Composite. Вызов статического метода new_Frame создает и возвращает такой кадр. Затем кадр может быть заполнен компонентами AWT и / или Swing.
Возвращенный кадр не является стандартным кадром AWT. По умолчанию это подкласс java.awt.Frame, предназначенный для встраивания в собственные приложения. Фактически, это тот же фрейм, который используется для встраивания апплетов в окно браузера.
Показанный выше пример кода обманчиво прост. В то время как SWT делает многое для управления интеграцией двух наборов инструментов, объем реализации моста очень узок. На самом деле вы должны сделать гораздо больше в своем приложении, чтобы сделать интеграцию более последовательной.
Несколько потоков событий
Интеграция Swing/SWT имеет важные последствия для многопоточности. Каждый набор инструментов пользовательского интерфейса имеет свою собственную очередь событий, и каждая очередь событий обрабатывается отдельным потоком. Большинство API-интерфейсов SWT необходимо вызывать из потока событий SWT. У Swing есть аналогичные ограничения, хотя они не столь строго соблюдаются. Это разделение является основным недостатком смешивания наборов инструментов и добавляет сложности коду.
Приложения должны знать о текущем потоке и, при необходимости, планировать выполнение задач в соответствующем потоке набора инструментов пользовательского интерфейса. Чтобы запланировать работу в потоке событий AWT, используйте:
javax.swing.SwingUtilities.invokeLater()
javax.swing.SwingUtilities.invokeAndWait()
Чтобы запланировать работу над потоком событий SWT, используйте:
org.eclipse.swt.widgets.Display.asyncExec()
org.eclipse.swt.widgets.Display.syncExec()
Это те же API-интерфейсы, которые используются в среде с одним набором инструментов, чтобы пользовательский интерфейс оставался отзывчивым, а длительные операции передаются рабочему потоку. Благодаря интеграции Swing/SWT они используются для дополнительной цели перемещения работы из одного потока событий в другой.
Использование нескольких потоков событий увеличивает риск тупиковой ситуации. По возможности старайтесь избегать блокировки одного потока событий при планировании работы над другим потоком событий. Другими словами, не звонитеSwingUtilities.invokeAndWait из потока событий SWT и избегайте вызова Display.syncExecиз потока событий AWT. В противном случае, если когда-либо будет сделан один блокирующий вызов, в то время как другой поток сделал свой собственный блокирующий вызов в другом направлении, возникнет тупик.
Ссылки