JavaFX 2.0 и Qt для кроссплатформенного приложения

Мне нужно немного советов от ваших разработчиков, которые занимаются кроссплатформенными приложениями (особенно программами с графическим интерфейсом).

Вскоре я буду создавать приложение, которое должно быть кроссплатформенным, поэтому я провел предварительное исследование двух разных сред: JavaFX 2.0 и Qt.

Честно говоря, оба более чем удовлетворяли бы мои потребности. И тогда я спросил себя, почему я выбрал одно из другого (ПРЕДУПРЕЖДЕНИЕ О СПОЙЛЕРЕ: Я не знаю ответа: P). Я знаю, что JavaFX 2.0 является довольно новым (по состоянию на 2012 год) и не полностью поддерживается на разных платформах, но это будет в конечном итоге.

Вопрос, который я задаю, заключается в следующем: какой из них вы бы использовали для кроссплатформенного приложения и на какие критерии вы смотрели при принятии этого решения?

Спасибо, что нашли время, чтобы прочитать это! 🙂

РЕДАКТИРОВАТЬ:
Для справки при рассмотрении этого вопроса приложение, которое я буду писать, включает чтение / запись файлов XML, отображение изображений и создание небольших виджетов с пользовательскими функциями. Я написал подобное приложение на C # с .NET, но хотел бы получить совет при рассмотрении JavaFX 2.0 или Qt для межплатформенного удобства использования.

Еще раз спасибо! 🙂

14

Решение

Это старый вопрос: стабильность против кровопролития. Я постараюсь дать вам некоторые личные идеи, основанные на функциях вашего приложения.

JavaFX 2.0 является довольно новым (по состоянию на 2012 год) и не полностью поддерживается на разных платформах

Ну, он полностью поддерживается в Linux, Windows и Mac. Я могу сказать это, потому что я разрабатываю приложение JavaFX 2.2 для Mac, на котором сервер работает на компьютере под управлением Linux, а клиенты — на компьютерах под управлением Windows.

Чтение / запись файлов XML

Мне еще предстоит увидеть какой-нибудь инструмент / интерфейс лучше / проще / быстрее, чем sax2 для разбора XML. Конечно, заслуживают уважения парсеры модуля QtXMLPatterns, но они даже разрабатывают синтаксический анализатор XML на основе SAX2 (который, кстати, не является полным и не полностью совместим с унаследованными методами SAX1), поэтому я бы сказал, что добавьте JavaFX 2 некоторый результат.

Отображение изображений

Обе технологии могут отображать изображения с достаточной легкостью, но JavaFX 2.2 не хватает некоторых инструментов для манипулирование изображением (Особенно формат кодеков). Если обработка изображений является критическим вопросом, я бы сказал, что Qt немного впереди в борьбе.

создание небольших виджетов с пользовательским функционалом.

На данный момент это не простая задача в JavaFX 2, так как объект Stage не имеет опции, подобной ALWAYS_ON_TOP, и не будет работать до 3.0 (где-то в 2013 году). Это не сложно, но в Qt уже есть несколько хороших инструментов для настройки. / display / обрабатывать виджеты, которые мы просто не можем воспроизвести в JavaFX.

Какой из них вы бы использовали для кроссплатформенного приложения, и какие критерии вы учитывали при принятии этого решения?

Ну, JavaFX 2.2 сделан из и для Java. Я лично считаю, что программировать на Java намного лучше и проще, чем на C ++. Вам никогда не придется бороться с указателями в java, вы всегда можете рассчитывать на сборщик мусора для управления памятью, в Интернете есть множество учебных пособий и документации (которые, я считаю, превосходит C ++) и постоянно растущее сообщество Java Gurus.

В резюме я выбрал JavaFX 2.2, потому что он симпатичный, потому что он классный, потому что я могу легче обрабатывать MVC, и потому что я люблю Java, но я считаю, что вы должны использовать Qt, если основная часть вашего приложения — это виджет этого

Я надеюсь, что это помогло, ура

19

Другие решения

В настоящее время я изучаю различные кроссплатформенные среды, подходящие для разработки автономного приложения для разработки html5. Помимо кроссплатформенной работы (Windows, Linux, OS-X), мое приложение также имеет следующие основные требования:

Встроенная база данных
Встроенный (или, во-вторых, основной браузер) движок рендеринга HTML5
Высокофункциональное редактируемое дерево DND, панель сплиттера и виджеты редактора форматированного текста
Обработка изображений средней нагрузки
Портативность USB-флешки

Я серьезно взглянул на эти рамки:

JQuery (JavaScript), HTML5, CSS3
Google Web Toolkit [GWT] (Java для JavaScript)
JavaFX 2.0 (Java)
QT (C ++ (доступна привязка Java))
Xulrunner (XML, JavaScript)
GTK + (C)
Adobe Air
пижама

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

Первоначально JavaFX 2.0 взял меня дальше всего, с большим отрывом. Простым объяснением этого является то, что с JavaFX все инструменты, IDE, библиотеки, документация, примеры кода, исправления ошибок, отладка, поддержка сообщества, поддержка производителя (Oracle) и кривые обучения объединены с наименьшим количеством несовпадений импеданса.

Вероятно, самой большой победой JavaFX стала простота реализации клиентской встроенной базы данных (Derby). Что касается всех других структур, эта задача была, на удивление, значительно более сложной и «грязной».

К сожалению, я столкнулся с серьезным камнем преткновения в JavaFX, когда обнаружил, что виджет WebView не выполняет JavaScript из локального файла: // URL-адреса. QtWebKit, GTKWebKit, Safari и Opera (все на основе WebKit) также демонстрируют один и тот же файл: // поведение блокировки JavaScript (однако Chrome нет), поэтому я предполагаю, что это стандартная мера безопасности WebKit.

В то время я рассмотрел проблему file: // JavaScript с JavaFX, поэтому перешел к разработке прототипов jQuery, GWT и Xulrunner. В результате, однако, моя производительность прототипирования взяла огромный удар. Несоответствие Франкенштейна и импеданса с этими другими структурами было заметно хуже, чем с JavaFX.

Настолько, что после многих недель блуждания по сорнякам я вернулся к своему прототипу JavaFX, мотивированному найти обходной путь. В конце концов я решил эту проблему, встроив веб-сервер Java SE 6 в прототип и подключившись к локальным файлам, загрузив JavaFX WebEngine с URL-адресами в следующем формате: «http: // localhost: 58357 / xxxxx.html» Разблокировка прототипа JavaFX таким образом было похоже на возвращение домой. Это был настоящий глоток свежего воздуха, не говоря уже о большом, большом повышении производительности.

Основываясь на этом опыте, вот некоторые идеи, которые могут оказаться полезными в дебатах JavaFX против Qt.

  • Я согласен с вопросом о JavaFX против Qt, так как эти две платформы соответственно оказались моими
    # 1 и # 2 любимый, самый продуктивный выбор.
  • Тем не менее, я бы добавил фреймворк jQuery / HTML5 / CSS3. это
    фреймворк настолько силен и настолько загружен потенциалом для x-платформы
    разработка приложений, что я бы пошел так далеко, чтобы сказать, что это
    неизбежная. В моем широком поиске элементов управления виджетом
    ведущие кандидаты на редактируемое дерево DND, панель сплиттера и богатые
    Текстовые виджеты редактора wysiwyg оказались с открытым исходным кодом jQuery
    плагины. Как только вы обойдете локальный файл: // проблема,
    jQuery / HTML5 / CSS3 хорошо совместим с JavaFX WebView
    виджет. Единственная область, в которой jQuery / HTML5 / CSS3 терпит неудачу, это
    хранилище базы данных на стороне клиента. Это где комбинация JavaFX
    и фреймворки jQuery / HTML5 / CSS3 оказываются чрезвычайно мощными.
  • Хотя они написаны на C ++, модули Qt имеют Java и
    Оболочки языка JavaScript означают, что разработчикам не нужно знать или использовать
    C ++ для использования Qt.
  • Это поднимает вопрос о том, что это не обязательно должен быть JavaFX против Qt,
    или-или вопрос. На самом деле, более конструктивный и полезный
    вполне может быть вопрос «JavaFX AND Qt?»
  • Это поднимает еще один важный момент: я быстро обнаруживаю,
    лучший кроссплатформенный фреймворк для разработки приложений на самом деле
    Амальгама JavaFX 2, прямой Java SE, Swing (для устаревшего обычая
    widget), WebKit и jQuery / HTML5 / CSS3. Вниз по дороге, GWT,
    связанные сторонние библиотеки GWT и модули Qt могут
    потенциально присоединиться к смеси. Дело в том, что план использования одного,
    генетически чистый каркас быстро ушел в окно.
  • В настоящее время одна общая нить, которая связывает весь этот гибрид
    Фреймворк вместе — это старая Java SE. И потому, что JavaFX 2 является
    Основываясь на Java SE, я хочу начать с JavaFX 2, затем добавить Swing,
    WebKit, jQuery / HTML5 / CSS3, GWT и Qt по мере необходимости.
  • Наконец, эта статья помогла убедить меня перейти на универсал JavaFX.
    http://fxexperience.com/2012/04/interview-with-peter-zhelezniakov/

—ЧАС

12

Из временных меток я вижу, что это было 4 месяца назад, когда я сообщил, что выбрал JavaFX2 вместо QT для своего исследовательского проекта по созданию прототипов. Около 2 месяцев назад я начал переключаться с JavaFX2 на QT и с тех пор не оглядывался назад. Главным предметом спора был переход от создания прототипа к производству. Что касается написания производственного кода, QT оказался намного впереди JavaFX2.

Как всегда, дьявол кроется в деталях, и это была куча маленьких вещей, которые имели большое значение. С JavaFX2 я постоянно сталкивался с такими мелочами, как неконтролируемое поведение изменения размера разделительной панели, ограниченное управление деревом и ограниченный доступ к API-интерфейсу WebKit (например, попробуйте реализовать кнопки масштабирования браузера или сохранить целую веб-страницу в локальном HTML-файле — выполнимо). но в 100 раз громче, чем должно быть). При объединении эти «незначительные» обходные пути замедляют прогресс до полной остановки.

С QT такие препятствия присутствуют гораздо реже, и в результате переход от прототипа к продукту был естественным, плавным и на несколько порядков быстрее.

С другой стороны, добраться до «Hello World» с QT заняло гораздо больше времени. Оказавшись там, однако, производительность быстро обогнала и намного превзошла JavaFX2. Одна из причин этого — документация по QT, примеры программ и сообщество разработчиков гораздо более обширно. QT существует с 1992 года, JavaFX2 — с 2011 года, и эта разница в возрасте существенно влияет на уровни зрелости двух платформ GUI.

Что касается вопроса Java против C ++, то это вообще не проблема. Оба замечательные языки. Лично по ряду причин эффективности, производительности и производительности я считаю C ++ лучшим языком графического интерфейса, но опять же, это личное заключение.

6

Исходя из .NET / C #, вы должны также рассмотреть Настоящая студия как способ создания кроссплатформенных приложений. Это, безусловно, отвечает вашим требованиям к тому, что вы пытаетесь создать, и будет намного проще, чем JavaFX или Qt.

1
По вопросам рекламы ammmcru@yandex.ru
Adblock
detector