Порекомендуйте GUI фреймворк для приложения.

[kit_D]

Здравствуйте.
В недавнем прошлом мы разработали приложение под Андроид имеющее GUI и реализующее некоторые customer-specific криптографические расширения для VPN и WiFi клиентов. Клиент остался доволен, продукт сдан. Теперь возникла необходимость реализовать этот же функционал и под десктоп Линукс. Предварительно в качестве дистрибутива выбран RHEL (пока не знаю подробностей и деталей этого выбора).

Сразу возникают следующие вопросы:
Во-первых, становится не совсем deployment модель (но оставим это пока);
Во-вторых, что брать за основу GUI интерфейса? Какие графические среды использовать?

На ум сразу приходят варианты:
1) Qt - мощный обкатанный объектно-ориентированный фреймворк. Но вот как с вопросами лицензирования не ясно. Кроме того возможность его использование в других дистрибутивах тоже вызывает сомнения.
2) KDE библиотеки - ну тот ясно. Есть KDE - есть библиотеки. Нет KDE - нет библиотек.
3) X библиотеки - слишком сложно и ресурсоемко.
4) GTK - C интерфейс + непонятно как с использованием в RHEL.
5) Java - вроде как не самый часто используемый инструмент.

Уверен, что подобный выбор стоял перед многими разработчиками UI под Линукс. Естественно хочется использовать наиболее универсальный, с точки зрения использования в различных дистрибутивах, интерфейс.

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

[Olej]

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

Хороший выбор.
Можете предварительно отрабатываться на Fedora. Или на CentOS.
Потом всё переедет, не заметив того, на RHEL.

Сразу возникают следующие вопросы:
Во-вторых, что брать за основу GUI интерфейса? Какие графические среды использовать?

На ум сразу приходят варианты:
1) Qt - мощный обкатанный объектно-ориентированный фреймворк. Но вот как с вопросами лицензирования не ясно. Кроме того возможность его использование в других дистрибутивах тоже вызывает сомнения.
2) KDE библиотеки - ну тот ясно. Есть KDE - есть библиотеки. Нет KDE - нет библиотек.
3) X библиотеки - слишком сложно и ресурсоемко.
4) GTK - C интерфейс + непонятно как с использованием в RHEL.

Уверен, что подобный выбор стоял перед многими разработчиками UI под Линукс. Естественно хочется использовать наиболее универсальный, с точки зрения использования в различных дистрибутивах, интерфейс.

Посмотрите (и попробуйте ) вот это: Создание графических приложений.
Там есть примеры "на попробовать".

И ещё, отчасти, вот это (к инструментам): Интегрированные среды разработки.
Это к вопросу: какие инструменты вы станете использовать под выбранный фреймворк.

[kit_D]

Спасибо. Интересно было бы услышать мнения с точки зрения "кросс-дистрибутивности" этих графических фреймворков.

[Olej]

Спасибо. Интересно было бы услышать мнения с точки зрения "кросс-дистрибутивности" этих графических фреймворков.

1. формулируйте что такое есть ""кросс-дистрибутивность" этих графических фреймворков"(с)? - и обсудим (обменяемся мнениями).

2. тему вашу я перенесу в другой раздел: Linux изнутри - там складывается всё, что касается разработки новых программ и обсуждений программных кодов.
ОК?
Но ссылка здесь пока останется "на туда" - так что никто не заблудится.

[Olej]

На ум сразу приходят варианты:

По поводу того, что сразу приходит на ум:

1) Qt - мощный обкатанный объектно-ориентированный фреймворк. Но вот как с вопросами лицензирования не ясно. Кроме того возможность его использование в других дистрибутивах тоже вызывает сомнения.

- Qt действительно весьма обкатанный...
- под Qt заточено достаточно много инструментальных средств разработки (IDE), и рассматривать вам нужно только совместно: GUI фреймворк + инструменты разработки на нём и, в первую очередь, язык программирования.
- Qt - многоплатформенное создание: Linux, Windows, другие OS ... даже такая мало-распространённая как QNX.
- во всех дистрибутивах, если это Linux , проблем не будет никаких - Qt это уже достаточно типовая составляющая tools Linux.
Это были плюсы, теперь - минусы:
- у Qt всегда было "шаткая" лицензия: то они разрешают, то они не разрешают ... из-за этого одно время произошёл даже серьёзный откат от Qt ... но, сейчас, похоже, вопросов нет к лицензированию ... но не появятся ли они завтра? - это один из главных пунктов настороженного отношения к Qt;
- Qt - это исключительно С++ - а). язык не сильно органичный в Linux среде, б). в меру громоздкий, в). если придётся использовать Linux-проекты или прежние наработки (с той же криптографией) - придётся делать "мультиязычный винегрет";
- Qt - громоздкая и ресурсоёмкая система - если планируются простенькие GUI, то можно посмотреть в сторону чего-то попроще.

Моё только личное IMHO:
Qt целесообразен () только при создании достаточно богатых GUI: фреймы, многооконные интерфейсы, многодокументные интерфейсы...
В последние годы расширенное (сверх необходимого) использование Qt определялось:
- модой ... как, например, Python;
- простотой начального изучения (въезжания в предмет) для начинающих пыонэров программирования...

2) KDE библиотеки - ну тот ясно. Есть KDE - есть библиотеки. Нет KDE - нет библиотек.

KDE библиотеки - это и есть Qt.
Но для использования Qt вовсе не обязательно иметь установленный KDE: KDE "родные" приложения замечательно работают в GNOME, или Xfce ... я таким образом многие годы использую K3b (считаю, что это лучшая писалка CD), но практически нигде не устанавливаю KDE.
Всё остальное здесь - см. пред. п.

3) X библиотеки - слишком сложно и ресурсоемко.

Xlib. Это низкий уровень, через который в X11 всё равно работают все остальные. Это как-раз очень не ресурсоёмко, но делать приложений в Xlib - достаточно трудоёмко (но не то, чтобы прямо караул).

4) GTK - C интерфейс + непонятно как с использованием в RHEL.

GTK+. Инструмент написания GNOME.
Также является неизменной составляющей любого дистрибутива Linux.
В плюс (относительно Qt) то, что вы можете писать приложение на чистом C - проще будет использовать сторонние Linux проекты и линковать со своими предыдущими наработками.

5) Java - вроде как не самый часто используемый инструмент.

Как-раз Java стала очень часто используемым инструментом для GUI проектов... сами IDE разработки разнообразные пишутся в Java.
... но не сама Java, а имеющиеся в JDK пакеты (группы классов) для построения GUI, разные и независимые: AWT, Sweeng, ... что там нового? - это всё не Java, а её пакетные надстройки.
В плюс:
- абсолютная переносимость и многоплатформенность;
- хорошие и доступные инструменты разработки: Eclipse, IntelIDEA и др.
В минус:
- язык разработки - Java (возможно минус для ваших условий)
- трудность связывания с C/C++ кодом - можно, есть разные способы, но хлопотно...
- необходимость установки у каждого заказчика JVM (хотя она и так у большинства стоит), какую JVM? см.: JDK & OpenJDK.

[kit_D]

Ну как то же пишут GUI, которые работают на большинстве дистрибутивов. Все эти приложения, которые мы хорошо знаем (Firefox, Skype, Wireshark, VLC и другие) работают как-то. Или же вы считаете в них интегрирована работа с разнообразными графическими средствами и в зависимости от дистрибутива на этапе компиляции выбираются те или иные графические библиотеки? Так получается?

Кстати, когда я говорил про ресурсоемкость XLib я и имел ввиду такой ресурс как время. Неправильно выразился вероятно.

[Olej]

На ум сразу приходят варианты:

Теперь из того, что на ум сразу не приходит

1. wxWidgets
Очень приятный многоплатформенный (Windows, UNIX, ...) фреймворк.
Посмотрите внимательно.
Для wxWidgets хорошо работает в качестве построителя "скелета" GUI - такой инструмент (IDE?) как Glut, который есть в репозитарии каждого Linux.
Язык С++ (или там есть диалект библиотек и на С?)

2. GLUT - OpenGL Utility Toolkit
Очень модная среди начинающих GUI-пыанеров среда: "... это так круто!"
Язык использования библиотек - С.
Закладываясь на OpenGL вы становитесь заложниками производителей видеоадаптеров: используется аппаратная поддержка OpenGL, которая на одних моделях работает, на других - не работает, а на третьих - "работает, но не так"
Смотреть в сторону OpenGL (любой реализации) можно только при условии:
- что вы всё остальное уже перепробовали, и вам производительности не хватает;
- при проектировании GUI где у вас там всё прыгает, летает и вытворяет подобные трюки.

Эти 2 предыдущие позиции затронуты кратко в: Создание графических приложений - там по ним в архиве есть примитивные примеры на "попробовать".

3. Motif (OSF/Motif®) / Lestif (свободный заменитель Motif).
Один из самых старых проектов межплатформенного инструментария для GUI в UNIX, очень любили его в Solaris.
Устанавливается элементарно просто - проблем с потребителем не создаст.
Сайт проекта: http://lesstif.sourceforge.net/.
man: http://linux.die.net/man/1/lesstif
Посмотрите.
Motif окна выглядят "старомодно" (все отмечают), но это и есть давний проект, а стиль отрисовки окон определяется дефаултными значениями флагов, которые можно отработать под свой вкус.

4. Tcl / Tk
Если вам нужно только GUI-обрамление для своего проекта (одиночное окно с разными органами управления и настройки), то Tcl / Tk - это самый быстрый и самый простой способ построения GUI, который потом связывается с исполнимым кодом на C/C++.
Есть в репозитарии любого Linux.
Сайт проекта: http://www.tcl.tk/software/tcltk/
http://linux.die.net/man/t.html - огромное количество man вида tcl_* & tk_*

[Olej]

Ну как то же пишут GUI, которые работают на большинстве дистрибутивов. Все эти приложения, которые мы хорошо знаем (Firefox, Skype, Wireshark, VLC и другие) работают как-то.

Как-раз весьма многие из приложений последнего времени "которые мы знаем"(с) - написаны на Java.

Или же вы считаете в них интегрирована работа с разнообразными графическими средствами и в зависимости от дистрибутива на этапе компиляции выбираются те или иные графические библиотеки? Так получается?

Ни в коем разе.
Я не знаю (не слышал) ни об одном конечном приложении (не девелоперском), которое использовало бы одновременно хотя бы 2 разных фреймворка.

- приложение (в установочном пакете .rpm, или .deb, или др.) - требует (проверяет) при инсталляции по зависимостям требуемые ему библиотеки ...
- библиотеки для Xlib уже есть всегда, библиотеки для Qt, GTK+, wxWindows - есть почти всегда...
- если их нет, то они по зависимостях подтягиваются из репозитария дистрибутива;
- это (зависимости) вы сами пропишете, когда будете собирать свой установочный пакет .rpm с помощью rpnbuild - к этапу разработки программы это не имеет отношения ... это потом;
- иногда (не часто) пакет не требует из репозитария, а сам устанавливает из исходных кодов проекта требуемые ему библиотеки (так делают Asterisk, FreeSWITCH), иногда исходники таких дочерних пакетов содержатся подкаталогами в дереве проекта, иногда они подтягиваются динамически с помощью w.g.e.t по известным URL проектов (имя утилиты изувечено точками в угоду движку этого форума , но вы поймёте).

Это всё решается!
Вам предстоит выбрать только один из распространённых фреймворков Linux и сделать проект только под него.

P.S. кстати, вспомнил, что я встречал пакеты одного ПО, но собранные под разные GUI, но тогда это и были разные пакеты одного и того же, и назывались эти пакеты по-разному: xxx-gtk, xxx-qt, xxx-wxwindows, ...

Так получается?

P.P.S. Соберите (повторите) вот те примитивные примерчики, что я приложил к Создание графических приложений - и станет немного понятнее откуда берутся недостающие части для GUI приложений.

[kit_D]

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

[Olej]

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

Qt - громоздкое средство, я вам сразу это отметил выше - самое громоздкое, из всего перечисленного списка, думаю.

Но вы ведь не сказали, что собираетесь эксплуатировать свой проект в системах с ограниченными ресурсами?
А для сегодняшнего десктопа Linux ... вот у меня в свеже (неделя!) установленном Fedora 17:

Код: Выделить всё

bash-4.2$ df | grep /dev/sd
/dev/sda3         10321208      9727052   489316           96% /
/dev/sda1         44348528     14559880 27535848           35% /home

/ - 10Gb, /home - 15Gb
... что ему ещё "сотня мегабайт"(с)? даже если их "несколько"(с)?

Хотя на самом деле Qt притянет заметно меньше...
Но, тем не менее, Qt будет самым ресурсо-пожирающим вашим выбором.