Кроссплатформенный язык GUI / инструментарий - PullRequest
Новая
       39

Кроссплатформенный язык GUI / инструментарий

6 голосов
/ 09 марта 2010

Я пытаюсь написать кроссплатформенное приложение с графическим интерфейсом, которое будет развернуто в Windows, Mac OS X и Linux.Мои требования:

  1. Единая база кода для всех трех платформ развертывания, без большого количества условной логики для обработки различий между платформами.
  2. Выглядит как можно ближе к "нативному"на всех трех платформах.
  3. Легко распространяется на все три платформы, в том смысле, что он может быть легко установлен конечными пользователями и не страдает от чрезмерного раздувания (как описано в этой статье ArsTechnica. )

Исходя из этих требований, я сузил выбор наборов инструментов до Qt и wxWidgets, поскольку ни один из других известных мне наборов инструментов (включая Java Swing и SWT, Flex, AIR)и т. д.) удовлетворяют требованию "на вид".Среди этих двух последних претендентов Qt, кажется, предлагает лучшую поддержку приложений, которые выглядят и чувствуют себя нативными на всех трех моих платформах развертывания, но я готов рассмотреть мнения об обратном.

Я бы предпочел не делать этогоиспользуйте C ++ в качестве языка реализации, но я не уверен, есть ли практические альтернативы.Больше всего меня беспокоит использование языка реализации, отличного от C ++, проблема развертывания.Как обсуждалось в статье Ars Technica , PyQt не отвечает требованию «простого развертывания» в каком-либо практическом смысле, и я подозреваю, что большинство других языковых привязок для Qt пострадают от тех же проблем развертывания (по крайней мере, вMac OS X). Java (или Scala) с QtJambi? QtRuby? WxPython?

Кто-нибудь знает о какой-либо комбинации языка и инструментария, которая удовлетворяет всем трем вышеуказанным требованиям?

Ответы [ 8 ]

8 голосов
/ 09 марта 2010
  1. Это зависит от ваших потребностей. Но в целом Qt Framework (с любым языком) и Java SE (с любым языком) намного лучше, потому что он имеет не только кросс-операционные библиотеки GUI, но также кросс-операционные сети, потоки, ... wxWidgets - только GUI.
  2. И Qt, и wxWidgets хороши. По моему опыту, Qt лучше. Качели это ... Ну, не так приятно.
  3. Приложения Qt и wxWidgets, написанные на C ++ и приложениях Java Swing, не так сложны для развертывания в Windows, Mac и Linux. Правило заключается в том, что развертывание является простым, когда вы программируете на «родном» языке. Под «родным» языком я подразумеваю язык, на котором написана сама структура.

PyQt не соответствует требованию «простого развертывания» в практическом смысле ...

Приложения Python (и любой другой язык с реализацией по умолчанию в качестве интерпретатора) сложно развернуть в обычном смысле (я имею в виду в виде автономных исполняемых файлов).

Так что, вероятно, у вас есть 2 варианта:

  1. C ++ / Qt или C ++ / wxWidgets.
  2. Java / Swing, если нативный внешний вид не является очень строгим требованием.
4 голосов
/ 09 марта 2010

wxWidgets довольно хорош, и содержит некоторый код не-GUI (в отличие от того, что сказал kemiisto): потоки, сокеты и т. Д.

Приятной особенностью wxWidgets является то, что на самом деле wxPython должен быть довольно прост в развертывании в OS X. Существуют некоторые другие языковые привязки для wx, но wxPython, вероятно, один из самых старых.

3 голосов
/ 24 января 2012

На своей повседневной работе я занимался кроссплатформенностью (Windows / MacOS / Linux) с использованием perl и wxWidgets. Комбинация удобна для разработки (я хакер Perl), и мне редко приходится включать специализированный код для каждой платформы. Есть некоторые Perl-модули, которые помогают с этим (например, File :: HomeDir, который знает о канонических местоположениях для каталогов документов и т. Д. На различных платформах).

В выпуске я вообще не полагаюсь на системную установку perl, а вместо этого собираю установку perl, включенную в релиз. Таким образом, я могу полностью контролировать среду выполнения приложения. Я поставляю пакет установщика Windows через innosetup, файл mac os .dmg с включенным .app, который пользователь может просто перетащить в их / Applications, а для linux я собираю пакеты debian и redhat.

1 голос
/ 20 апреля 2017

Примерно десять лет назад было модно моделировать GUI в кроссплатформенном варианте XML (например, XUL), а затем иметь механизм обработки для конкретной платформы, который обрабатывает XML-файл для отображения макета. Однако это уже не модно. Сегодня, в 2017 году, тенденция состоит в том, чтобы создавать свои приложения на платформах, которые позволяют писать все на HTML, CSS и / или JavaScript, независимо от того, в какой среде должен выполняться ваш код.

«Первое поколение» этого типа инструментов создало «гибридные» приложения, где веб-приложения работают поверх браузероподобных и специфичных для платформы WebViews . Однако эта техника довольно неэффективна. Ваши приложения не выглядят очень «родными», они довольно раздутые и им не хватает производительности. Тем не менее, относительно легко иметь постоянный внешний вид в разных средах. Phonegap / Cordova является самой популярной платформой для мобильных сред и NW.js для настольных сред.

«Второе поколение» отличается: они компилируют все в полностью «родные», специфичные для платформы двоичные файлы. Вместо того, чтобы полагаться на WebViews, «родные» виджеты используются, когда это возможно. Это придает вашему приложению «родной» внешний вид, обычно имеет меньше раздувания и намного лучше для производительности. Тем не менее, у вас будет больше различий между различными платформами. Примеры: NativeScript , React Native & Tabris.js (все для мобильных сред).

К сожалению, пока нет инструментов «второго поколения» для рабочего стола. Итак, прямо сейчас, если вы хотите создать кроссплатформенное настольное приложение, вы застряли с инструментами «первого поколения». NW.js имеет более длинный послужной список, чем Electron, и поддерживает различные функции, отсутствующие в Electron, но также имеет свои недостатки . AppJS все еще старше, но он не такой зрелый - и не такой популярный - как два других.

В любом случае, их зависимость от WebViews означает, что ваше приложение будет больше похоже на веб-приложение, чем на настольное приложение. И раздувание и недостатки производительности неизбежны при таком решении . Это означает, что вы никогда не получите ту же производительность, что и код, который вы пишете непосредственно на Java или C ++, и ту же производительность, которую вы получите на платформах «второго поколения», и она никогда не будет чувствовать себя в равной степени «нативной». Тем не менее, это все еще может быть лучшим решением, например. когда согласованность внешнего вида на разных платформах важнее или если у вас есть опыт работы веб-разработчиком.

Если важными критериями являются производительность, отсутствие раздувания и ощущение «родного» приложения, вам может потребоваться немного подождать, пока появятся платформы «второго поколения» для настольных ПК. Это действительно вопрос времени, когда платформы для настольных приложений пойдут по тому же эволюционному пути, что и платформы для мобильных приложений, хотя на самом деле они могут иметь форму «настольных расширений» для существующих мобильных платформ.

Как это выглядит в настоящее время, похоже, что вы скоро сможете писать «нативные» приложения для настольных и мобильных устройств с точно такой же кодовой базой. Поскольку в React Native уже есть плагины, в которых добавлена ​​поддержка для Windows 10 и для MacOS , я бы лично выбрал React Native и дал бы их команда разработчиков некоторое время, пока они не поддержат все настольные среды, которые мне нужно поддерживать, и эти расширения для настольных компьютеров достаточно зрелы для производственных сред.

Если вы не можете ждать так долго, вы не хотите делать ставки на то, что произойдет в будущем, или если эти критерии не так важны для любого приложения, которое вы хотите создать сегодня, вы можете попробовать платформ "первого поколения", доступных в настоящее время, и посмотрите, какая из них наиболее подходит для вас. Просто знайте о недостатках!

Как всегда, выбирайте мудро ...

Популярные платформы

Платформы первого поколения для мобильных сред (iOS и Android)

Платформы второго поколения для мобильных сред (iOS и Android)

Платформы для настольных сред (Windows, Linux или MacOS)

Платформы для умного дома и устройств IoT

1 голос
/ 31 марта 2010

Вы смотрели на Xojo ? Он определенно соответствует всем трем вашим требованиям, и его гораздо проще изучить и использовать, чем C ++.

0 голосов
/ 09 марта 2010

Java поддерживает "нативные" приложения, используя SystemLookAndFeel. Самый быстрый способ попробовать это вызвать следующее при запуске приложения. 

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

Взгляните на это для получения дополнительной информации о доступных стилях в Java.

http://java.sun.com/docs/books/tutorial/uiswing/lookandfeel/plaf.html

0 голосов
/ 09 марта 2010

Java / SWT - один из хороших вариантов. Вы можете найти много информации об этом здесь .

0 голосов
/ 09 марта 2010

.Net (C # или VB.Net) - это то, что я бы использовал для этого (фактически, - это , что я использую для своего собственного приложения). Благодаря проекту Mono приложения .Net могут работать на Mac и Linux, а также Windows без каких-либо изменений в коде (если только вы не вызываете функции Windows API). Вам даже не нужно компилировать разные версии вашей программы: один и тот же EXE-файл будет работать на всех платформах.

...