Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 40
Из под Mac OS X
$ java -jar simple_edit_macosx_cocoa-64-0.1.jar
***WARNING: Display must be created on main thread due to Cocoa restrictions.
Exception in thread «main» org.eclipse.swt.SWTException: Invalid thread access
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.widgets.Display.error(Unknown Source)
at org.eclipse.swt.widgets.Display.createDisplay(Unknown Source)
at org.eclipse.swt.widgets.Display.create(Unknown Source)
at org.eclipse.swt.graphics.Device.(Unknown Source)
at org.eclipse.swt.widgets.Display.(Unknown Source)
at org.eclipse.swt.widgets.Display.(Unknown Source)
at swt.texteditor.simple.Bootstrap.main(Unknown Source)
$ java -jar simple_edit_macosx_cocoa-64-0.1.jar
***WARNING: Display must be created on main thread due to Cocoa restrictions.
Exception in thread «main» org.eclipse.swt.SWTException: Invalid thread access
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.widgets.Display.error(Unknown Source)
at org.eclipse.swt.widgets.Display.createDisplay(Unknown Source)
at org.eclipse.swt.widgets.Display.create(Unknown Source)
at org.eclipse.swt.graphics.Device.(Unknown Source)
at org.eclipse.swt.widgets.Display.(Unknown Source)
at org.eclipse.swt.widgets.Display.(Unknown Source)
at swt.texteditor.simple.Bootstrap.main(Unknown Source)
Спасибо, к сожалению под Linux/Windows у меня таких проблем не возникло. Попробую в ближайшее время раздобыть Mac OS X и разобраться в чем там проблема.
У меня возникали такие проблемы, с помощью JarBundler смог разрулить всё. Если интересно — взгляните здесь: code.google.com/p/fa13jogador, проект, для которого применял сборку SWT-приложения под Mac
К сожалению, не нашел на чем проверифицировать, но я так понимаю, что для Mac пользователей должно помочь добавление флага -XstartOnFirstThread:
java -XstartOnFirstThread -jar simple_edit_macosx_cocoa-64-0.1.jar
java -XstartOnFirstThread -jar simple_edit_macosx_cocoa-64-0.1.jar
Помогло, можете добавить скрин в статью.
Два вопроса:
1) Почему не Jambi (Qt)?
2) Зачем самому иметь все три платформы для сборки, когда зависимости от эклипса можно разруливать мавеном?
1) Почему не Jambi (Qt)?
2) Зачем самому иметь все три платформы для сборки, когда зависимости от эклипса можно разруливать мавеном?
1). Был интерес именно пощупать фреймворк, на котором построен такой гигант, как Eclipse
2). Как я уже говорил, я не нашел последнии версии swt (3.7) в Maven репозиториях. То, что я нашел, было версии 3.3.0, что не очень-то хорошо(2011 год на дворе как ни как). К тому же Maven хорошо ездит по рельсам, а если нужно сделать что-то кастомное, то тут приходится извращаться. Конкретно пришлось бы использовать в любом случае Ant, только уже из-под Maven'a использовать maven-antrun-plugin, который бы дергал какой-то target, который продуцировал бы билды для разных платформ.
2). Как я уже говорил, я не нашел последнии версии swt (3.7) в Maven репозиториях. То, что я нашел, было версии 3.3.0, что не очень-то хорошо(2011 год на дворе как ни как). К тому же Maven хорошо ездит по рельсам, а если нужно сделать что-то кастомное, то тут приходится извращаться. Конкретно пришлось бы использовать в любом случае Ant, только уже из-под Maven'a использовать maven-antrun-plugin, который бы дергал какой-то target, который продуцировал бы билды для разных платформ.
Да, про старость версий я не заметил. Для меня это не было проблемой — просто раздеплоил на свой артифактори все версии клипца, а теперь просто подцепляю их через профили.
Конкретно пришлось бы использовать в любом случае Ant, только уже из-под Maven'a использовать maven-antrun-plugin, который бы дергал какой-то target, который продуцировал бы билды для разных платформ.
А executions нельзя настроить для assembly-плагина? Я так понял, что для вас мавен это то, что зависимости скачивает. Правда он сам по себе отличная билд тула. Просто нужно уметь пользоваться.
Я плохо знаком с Maven Assembly плагином, но из краткого знакомства с документацией, я вынес, что мне предлагается создать 7 профайлов(для каждой из операционных систем и для каждой из архитектур[32/64 бита]) и написать 7 дескрипторов(по дескриптору на профайл). На мой взгляд выходит несколько громоздкое решение для моей задачи.
У меня с Maven все хорошо пока, он катится по рельсам и ты лишь немного направляешь его. Но с ним становится все плохо, когда нужно его кастомизировать. Мое решение на Ant + Ivy у меня заняло в сумме 263 + 11 = 274 строк кода. А сколько строк заняло бы аналогичное решение на Maven?
У меня с Maven все хорошо пока, он катится по рельсам и ты лишь немного направляешь его. Но с ним становится все плохо, когда нужно его кастомизировать. Мое решение на Ant + Ivy у меня заняло в сумме 263 + 11 = 274 строк кода. А сколько строк заняло бы аналогичное решение на Maven?
Но с ним становится все плохо, когда нужно его кастомизировать.
Вы просто не умеет его готовить :) Рекомендую полистать www.sonatype.com/books/mvnref-book/reference/. Просветляет почему те или иные вещи сделаны так, как они сделаны.
Я плохо знаком с Maven Assembly плагином, но из краткого знакомства с документацией, я вынес, что мне предлагается создать 7 профайлов(для каждой из операционных систем и для каждой из архитектур[32/64 бита]) и написать 7 дескрипторов(по дескриптору на профайл). На мой взгляд выходит несколько громоздкое решение для моей задачи.
Не, можно просто запаблишить артифакт для каждой платформы с определённым классификатором(linux32, linux64, etc) и дёргать его в зависимости от операционной системы.
Мое решение на Ant + Ivy у меня заняло в сумме 263 + 11 = 274 строк кода. А сколько строк заняло бы аналогичное решение на Maven?
Хватит заниматься гольфом :) Это актуально, если мы пишем библиотеку и хотим уменьшить количество строк в код, который её использует. Но при дизайне портируемого билда определённо не стоит считать. Тем более любая ide валидирует pom-файлы и умеет автодополнение. Ну пусть будет много, зато расширяемо.
А как же qt.gitorious.org/qt-jambi/qtjambi-community?
Последний коммит буквально вчера…
Последний коммит буквально вчера…
stackoverflow.com/questions/2706222/create-cross-platform-java-swt-application — ещё вот эта штука может быть весьма полезной. Тут описано, как сделать универсальный jar-ник для всех платформ. Уже в SWT-FAQ внесено, кстати.
Сам просто на днях в этой теме вновь копался, выступал с докладом на JavaDay новосибирском :)
Сам просто на днях в этой теме вновь копался, выступал с докладом на JavaDay новосибирском :)
Я привык пользоваться Maven'ом, но для этих целей он не очень хорошо подходит, ибо свежих версий SWT я увы не нашел в Maven-репозиториях, да и пришлось скачивать мануально пакеты для каждой из платформ операционных систем/архитектур. Кроме того там где нужно много кастомизации Maven не особо подходит, зато на помощь приходит старый-добрый Ant. В качестве менеджера зависимостей я взял Ivy.
Ну классификаторы же. Зачем писать миллион первый ант скрипт?!!!
Хм… Может я чего-то не знаю, но Swing тоже умеет делать нативный интерфейс. Причём он может натягивать его динамически. Во время исполнения пробует натянуть интерфейс и поведение той системы, в которой запущен. Если что-то не так — откат на стандартный…
Вы сами себе противоречите. Взгляните на свой скриншот из-под MacOs: где же он нативный? Взять хотя бы меню!
А под Linux, так вообще тошнит от его «нативности».
А под Linux, так вообще тошнит от его «нативности».
И ещё скроллбар. Вертикального градиента не должно быть — только серый ползунок.
Это самое что ни на есть меню!
Просто я не люблю синие градиенты. Вот моё меню Finder — скрин.
Обратите внимание на скроллбар в TextArea.
Вот так это выглядит в стандартном режиме:
не нативно
Просто я не люблю синие градиенты. Вот моё меню Finder — скрин.
Обратите внимание на скроллбар в TextArea.
Вот так это выглядит в стандартном режиме:
не нативно
И вот опять тоже самое. Почему у Finder меню вверху, где и положено, а у вашего приложения в окне? Это уже не нативно.
А сколлбар должен выгляжеть вот так.
А сколлбар должен выгляжеть вот так.
нет не должен. А про меню вверху я вообще ничего не знаю, в топике есть скрин SWT под маком, там тоже меню не на месте. Я же не про Swing — Cocoa говорю, а про Swing — SWT.
> в топике есть скрин SWT под маком, там тоже меню не на месте
Это где? Там всего 1 скриншот из-под мака и меню в окне не видно.
Зато на скриншоте из-под Ubuntu явно видно, что оно вверху.
Это где? Там всего 1 скриншот из-под мака и меню в окне не видно.
Зато на скриншоте из-под Ubuntu явно видно, что оно вверху.
В топике, на скриншоте под Mac OS, меню вообще не отображается потому что скриншот не на весь экран, и не видно меню, которое отображается на панеле так же, как в Unity оболочке Ubuntu. Если вы владелец Mac OS, то можете скачать и запустить у себя приложение — больше чем уверен, что меню отобразится вверху, на панеле, там где отображают его другие нативные приложения. Да и как я уже пытался заметить, основная проблема в том, что Swing не использует нативные компоненты, а эмулирует их. Отсюда ряд ограничений, деградация производительности и прочие сопутствующие вещи при __прочих равных условиях__.
Внесу свою скромную лепту в виде комментариев по заключению…
Как мне кажется — у них как раз проще всего найти пример на тот или иной случай:
www.eclipse.org/swt/snippets/
Это как вариант — есть и множество примеров от сторонних людей.
Могу сказать, что о Swing толковой информации также мало как и об SWT — я не говорю о примерах уровня «Hello World» коих множество на всё что угодно.
Тут сложно поспорить — что-то на SWT в отличие от Swing просто-напросто убивает время.
У них действительно есть множество готовых решений под различные случаи, которые зачастую сильно упрощают разработку, в отличии от реализации подобной вещи в том же Swing. Однако стоит выйти за рамки стандартных кнопок-табов и начинаются проблемы…
На Вашем же примере табы приложения выглять ненативно на всех 3ёх ОС (что, кстати, странно). Скажем тот же Swing предоставляет на каждой ОС свой (весьма схожий с нативным) Look and Feel — мне они нравятся даже больше, нежели оформление некоторых компонентов в SWT.
Вопрос про скорость весьма спорный — я бы сказал даже про Swing — «Вы просто не умеете его готовит» :)
Скорости интерфейса на Swing должно хватать для любого десктоп приложения (для адекватной работы, естественно) — различные оптимизации работы интерфейса успешно делают своё дело. А вот нативный интерфейс, кстати говоря, ест побольше ресурсов машины при работе, как я смог заметить по нескольким тестам (да, он всегда отзывчив, не подвисает даже при нагрузках, но ресурсов потребляет больше).
В общем и целом — попробовав написать приложение на SWT — я сперва обрадовался, но потом потихоньку стал сползать на вставки Swing-частей в SWT, а затем полностью ушёл от SWT, так как смысла в нём никакого уже не было — он лишь нагружал приложение излишними библиотеками.
В SWT есть лишь несколько полезных вещей, которые очень бы хотелось в адекватном виде видеть в J2SE:
— Нормальная работа с меню в трее (сейчас, как ни крути — придётся использовать устаревшее PopupMenu для корректного его закрывания — в нём даже иконок не установить толком)
— Возможность создания ToolDialog'ов (нативных ToolDialog'ов — это отдельный тип окон — есть во всех известных ОС), более
— Более удобная работа с модальностью диалогов (т.е. хотелось бы иметь возможность легко и быстро создать модальный диалог, блокирующий лишь одно окно приложения, а не все)
— Нормальная работа прозрачности окон на Unix-системах (сейчас там полный бордак — корректно данная возможность представлина лишь на Windows/MacOS)
Впрочем все эти пункты, как можно заметить, не настолько критичны, чтобы бросать Swing и погружаться в SWT. Собственно именно поэтому я отказался от разработки десктоп-приложений на SWT в пользу Swing.
Минусы SWT на мой взгляд:
* Мало документации/туториалов
Как мне кажется — у них как раз проще всего найти пример на тот или иной случай:
www.eclipse.org/swt/snippets/
Это как вариант — есть и множество примеров от сторонних людей.
* Гугл не так много знает о SWT, как о Swing
Могу сказать, что о Swing толковой информации также мало как и об SWT — я не говорю о примерах уровня «Hello World» коих множество на всё что угодно.
* Многие проблемы приходится решать дольше.
Тут сложно поспорить — что-то на SWT в отличие от Swing просто-напросто убивает время.
Плюсы SWT на мой взгляд:
* В общем и целом простой и понятный API
У них действительно есть множество готовых решений под различные случаи, которые зачастую сильно упрощают разработку, в отличии от реализации подобной вещи в том же Swing. Однако стоит выйти за рамки стандартных кнопок-табов и начинаются проблемы…
* Кросс-платформенное, нативно выглядящее приложение
На Вашем же примере табы приложения выглять ненативно на всех 3ёх ОС (что, кстати, странно). Скажем тот же Swing предоставляет на каждой ОС свой (весьма схожий с нативным) Look and Feel — мне они нравятся даже больше, нежели оформление некоторых компонентов в SWT.
* Из коробки быстрее работающее, чем такое же на Swing
Вопрос про скорость весьма спорный — я бы сказал даже про Swing — «Вы просто не умеете его готовит» :)
Скорости интерфейса на Swing должно хватать для любого десктоп приложения (для адекватной работы, естественно) — различные оптимизации работы интерфейса успешно делают своё дело. А вот нативный интерфейс, кстати говоря, ест побольше ресурсов машины при работе, как я смог заметить по нескольким тестам (да, он всегда отзывчив, не подвисает даже при нагрузках, но ресурсов потребляет больше).
В общем и целом — попробовав написать приложение на SWT — я сперва обрадовался, но потом потихоньку стал сползать на вставки Swing-частей в SWT, а затем полностью ушёл от SWT, так как смысла в нём никакого уже не было — он лишь нагружал приложение излишними библиотеками.
В SWT есть лишь несколько полезных вещей, которые очень бы хотелось в адекватном виде видеть в J2SE:
— Нормальная работа с меню в трее (сейчас, как ни крути — придётся использовать устаревшее PopupMenu для корректного его закрывания — в нём даже иконок не установить толком)
— Возможность создания ToolDialog'ов (нативных ToolDialog'ов — это отдельный тип окон — есть во всех известных ОС), более
— Более удобная работа с модальностью диалогов (т.е. хотелось бы иметь возможность легко и быстро создать модальный диалог, блокирующий лишь одно окно приложения, а не все)
— Нормальная работа прозрачности окон на Unix-системах (сейчас там полный бордак — корректно данная возможность представлина лишь на Windows/MacOS)
Впрочем все эти пункты, как можно заметить, не настолько критичны, чтобы бросать Swing и погружаться в SWT. Собственно именно поэтому я отказался от разработки десктоп-приложений на SWT в пользу Swing.
Кстати, я надеюсь до новогодних праздников выложить две достаточно масштабные статьи на тему — будет возможность оценить «силу» Swing и различные его возможности. Думаю по ним Вы сможете примерно прикинуть под какие цели лучше Swing, а под какие SWT.
Насчет табов — я использовал CTabs и CTabFolder вместо простых Tab и TabFolder. Пожалуй это тоже сыграло свое дело.
Ну и ещё стоит сказать, что писать на чистом SWT — несколько старомодно. Гораздо удобнее пользоваться надстройкой JFace.
Например, создание меню на JFace выглядит попрозрачнее. А также работа с таблицами и деревьями.
Например, создание меню на JFace выглядит попрозрачнее. А также работа с таблицами и деревьями.
Посмотрел код. Ну, для учебной программы сойдёт, хотя уж очень она какая-то учебная. Зачем так много журналирования, непонятно. Зачем надо запускать задачи по asyncExec (это в главном-то треде) — тоже непонятно. Ну и в целом структура классов…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мои первые шаги в SWT: Простенький блокнот со вкладками