Qt Jambi против SWT для кросс-платформенного графического интерфейса

В настоящее время я участвую в разработке приложений, в первую очередь для Linux (Fedora 10). Однако позже может случиться, что нам придется переносить эти приложения в Mac OS X и Windows, и мы не хотим, чтобы вас поймали, выбирая неправильный набор инструментов GUI. *

Для множества наследственных причин мы заперты в использовании Java. Мы находимся в процессе решения между использованием Qt Jambi и SWT для графического интерфейса. У меня мало опыта в использовании любого из них, поэтому я делаю небольшие прототипы, чтобы попробовать и почувствовать их. До сих пор (только разработка на Linux) между ними не так много. Тем не менее, есть предел для глубины, в которую я могу пойти за короткое время. Вот почему я прошу о помощи.

Особые особенности, представляющие для нас интерес, следующие:

  • Безрамные окна

  • окна с настраиваемой формой (то есть не прямоугольные)

  • эстетически приятный

Есть ли у кого-нибудь опыт и/или понимание этих двух библиотек, которые могли бы нас позже спутать?

  • Люди с гибким программированием, несомненно, скажут фразу "возможно,... позже" и скажут, что мы не должны беспокоиться об этом. Однако в отсутствие других решающих факторов между инструментариями будут использоваться варианты будущей расширяемости. Я обещаю не писать какой-либо кросс-платформенный код, пока мне не придется:)

Обновление 11 февраля: Спасибо за отличные ответы. Для любопытных мы, вероятно, поедем с Джамби. Это было главным образом функциональность таблиц стилей, которая выиграла меня, поскольку они облегчают много настраиваемых элементов формы виджета, которые нам нужно делать. Набор примеров Qt показал, что бескаркасные окна в произвольной форме действительно работают на разных платформах, поэтому нам не следует улавливать отставание от трека. Выпуск LGPL был причиной того, что мы рассматривали Jambi вообще:)

ОТВЕТЫ

Ответ 1

Я согласен с Уксусом: Не исключайте Свинг. Я разработал как Swing, так и SWT, но не с Qt. С Swing ваш код будет автоматически кросс-платформенным. С SWT ваш код кросс-платформенный с небольшим усилием, хотя и не так много усилий. Вы собираетесь внедрить локальное приложение, апплет или приложение Web Start?

Преимущество SWT заключается в том, что он использует все собственные виджеты. (знакомый Look-and-feel.) Недостатком SWT является то, что он использует все собственные виджеты. (не так много виджетов, как у Swing). Является ли это скорее преимуществом или недостатком, зависит от того, что вы делаете и каковы ваши цели. Это означает, что Swing имеет большую ширину виджетов. Тем не менее, есть несколько вещей, которые SWT делает, что Swing не работает (или вообще) - например, запуск собственного браузера системы и выполнение сценариев JavaScript в этом браузере.

Если вы рассматриваете SWT, подумайте об этом осторожно. Если у вас есть определенные потребности (например, выполнение JavaScript в окне браузера, которое было запущено вашим приложением), то это может быть ваш лучший выбор. Однако, если Swing может полностью удовлетворить ваши потребности, это может быть лучший выбор.

Надеюсь, кто-то еще может предоставить информацию о Qt Jambi.

Обратите внимание, что поддержка должна рассматриваться в вашем решении. С SWT существует небольшое сообщество, поддерживающее его. С Swing, более крупное сообщество, но это не означает, что исправления будут быстрее внедряться в релиз разработки. С Qt Jambi и с SWT, если ошибка исправлена, вы просто распространяете обновленные библиотеки с вашим приложением. С Swing вы должны ждать обновления JRE. Ни один из них не обязательно является разбойником, но он должен быть рассмотрен.

Лицензионные сборы могут быть или не быть предметом рассмотрения. SWT и Swing, конечно же, не имеют лицензионных сборов Jambi. Я не знаю ни одного из них, но это может зависеть от вашего предполагаемого использования - например, распространяете ли вы приложение GPL или коммерчески лицензированное.

Удачи.

Ответ 2

У меня нет опыта работы с SWT, но я также работал с Jambi/Qt, Swing и GTK. Единственная проблема с Qt/Jambi - это, по моему мнению, лицензирование (вы должны либо опубликовать свое программное обеспечение под лицензией GPL, либо купить коммерческую лицензию). Вы не можете начать писать программное обеспечение бесплатно, а затем "посмотреть, что произойдет". Вы должны быть уверены, что ваше программное обеспечение будет успешным, потому что вы должны покупать лицензии. Это во многих случаях не является случаем.

С уважением.

Ой, я пропущу эти комментарии, спасибо за ответ. Это отличная новость! Хороший переход от Nokia.

@cursa, который не был указан, так что также обратите внимание, что Qt/Jambi больше, чем набор инструментов виджета. У вас есть классы для работы в сети, манипуляции с строками (вместе с движком regexp), мьютексы, 2-й вектор и растровая графика, openGL и многие другие. Это дает реальный импульс развитию приложений.

Я также рекомендую загрузить Qt-пакет в noobies от Jambi из-за очень приятного браузера помощи под названием Assistant, которого не хватает Jambi. Все API Qt и Jambi одинаковы (кроме слотов и сигналов), даже документация не изменяется, поэтому вы можете использовать ее взаимозаменяемо.

Ответ 3

Вы знаете, что Qt Jambi прекращен после выпуска версии 4.5 в этом месяце? Это не делает его плохим выбором. Qt имеет другие поддерживаемые сообществом языковые привязки, которые живут вне контроля Trolltech.

http://www.qtsoftware.com/about/news/preview-of-final-qt-jambi-release-available

Ответ 4

Я бы не исключил SWT, так как это большой успех в мире затмений. Я использовал его счастливо в течение 6 лет и никогда не приходилось прибегать к качелям.

Ответ 5

Я бы не рекомендовал SWT. SWT - плохо спроектированная библиотека с множеством хаков и ошибок. Вы будете смотреть все время на обходные пути для простых пользовательских задач

Ответ 6

После многих лет это меня удивляет, что разработчики java по-прежнему ищут инструменты для программирования gui. В моем случае swing ретранслятор медленный, это не хорошо для больших проектов. Поскольку мы можем видеть, что многие проекты, такие openoffice начались с солнца, используя С++ виджеты для программирования gui, я использовал для качания в каком-то проекте, но покупатели часто спрашивали меня об изменении производительности. Qt также неактивные программисты и поддержка, я использовал для тестирования javafx, но все еще вижу проблемы с производительностью, вы можете загрузить образец javafx с сайта oracle, сменив GUI-страницы на длительное время по сравнению с собственными С++ gui's.