URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID9
Нить номер: 2104
[ Назад ]

Исходное сообщение
"Какие есть хорошие кроссплатформенные средства разработки GUI?"

Отправлено _Павел , 23-Сен-03 12:59 
сабж. ПО пишется на С/С++, в задаче используется достаточно серьезная интерактивная графика (требуется быстрое рисование и одинаковость использования HID).

Собственно, имеется в виду следующее - как написать ПО так, чтобы оно "везде компилилось"?
Выскажитесь, пожалуйста, в этом смысле по поводу Qt и других библиотек.

Для разработки остального, я так понимаю (поправьте, если не так), хорошо подходит ACE.


Содержание

Сообщения в этом обсуждении
"Какие есть хорошие кроссплатформенные средства разработки GU..."
Отправлено _Павел , 25-Сен-03 11:25 
Неужели никто не знает?...
Или перевелись тут богатыри земли русской? ;-)

Печально... ну расскажите хотя б про Gtk+ какой-нибудь,
или еще про что-нить в этом роде...


"Какие есть хорошие кроссплатформенные средства разработки GU..."
Отправлено SergCh , 25-Сен-03 14:56 
>сабж. ПО пишется на С/С++, в задаче используется достаточно серьезная интерактивная графика
>(требуется быстрое рисование и одинаковость использования HID).
>
>Собственно, имеется в виду следующее - как написать ПО так, чтобы оно
>"везде компилилось"?
>Выскажитесь, пожалуйста, в этом смысле по поводу Qt и других библиотек.
>
>Для разработки остального, я так понимаю (поправьте, если не так), хорошо подходит
>ACE.


А я пользуюсь FOXtoolkit. Кросплатформенно все компилится.
(глюк только там был, если в 95-м прогу пускаешь, может уже нет)


"Какие есть хорошие кроссплатформенные средства разработки GU..."
Отправлено _Павел , 26-Сен-03 08:42 
Ну, 95-я мало кого волнует ;-).
А вообще - спасибо, тоже поищу инфу и по FOXtoolkit.

"Какие есть хорошие кроссплатформенные средства разработки GU..."
Отправлено SergeiZz , 25-Сен-03 17:07 
>Собственно, имеется в виду следующее - как написать ПО так, чтобы оно
>"везде компилилось"?
А я использую GLOW -- тогда по-настоящему "везде компилируется" (одинаково легко на Linux, Windows, MacOS).
Но это, думаю, не совсем то, что требуется.

>Выскажитесь, пожалуйста, в этом смысле по поводу Qt и других библиотек.
Qt не имела свободной версии для Windows, когда я выбирал оконную библиотеку. Теперь имеет...
Не вполне понятно, что значит "требуется быстрое рисование и
одинаковость использования HID". Но в любом случае, на мой взгляд, Qt не
хуже (да и не лучше...) лубой другой подобной библиотеки.

>Для разработки остального, я так понимаю (поправьте, если не так), хорошо подходит
>ACE.
Остального, чего именно?


"Какие есть хорошие кроссплатформенные средства разработки GU..."
Отправлено _Павел , 26-Сен-03 08:37 
>А я использую GLOW -- тогда по-настоящему "везде компилируется" (одинаково легко на
>Linux, Windows, MacOS).
а как насчет OS/2?

>Но это, думаю, не совсем то, что требуется.
Почему?

>Не вполне понятно, что значит "требуется быстрое рисование и
>одинаковость использования HID".
Быстрое рисование - имеется в виду отсутствие всяких ненужных наворотов, как в VCL-е (в последнее время есть заметная экспансия с их стороны в сторону кроссплатформенности). Java, понятно, тоже не подходит (ну нет в свободной продаже Java-машин). Вариант, когда нарисованное в Dialog Editor'е окошко грузится полминуты, не подходит.
HID - Human Interface Devices. Имеется в виду одинаковое использование клавиатуры и мыши.
Для рисования предполагается использовать OpenGL (вполне стандартная вещь, при этом, конечно, есть вопросы ее совместимости с предлагаемой библиотекой).
Остальное - это работа с витками, семафорами, сокетами и т.п. - говорят, ACE неплохая штука (и CORBA, вроде, на ней написана).
Еще, конечно, есть работа со строками, списками, массивами и т.п., но STL, вроде, действительно "Standart", на крайний случай есть libc, я к ней уже привык ;-)...

Задача такая - строится система сбора данных для работы под разные (любые) ОС. Ситуация на экране должна меняться довольно плавно и оперативно - что-то около 20..40 кадров в секунду. При этом обработка информации является задачей первоочередной важности.

Иначе говоря, через ПО, сделанное на этой библиотеке, необходимо иметь возможность смотреть фильмы с ОЧЕНЬ хорошим качеством. Железо при этом должно быть самое обычное, а не 10ГГц/1024Мб.

Вывод - наилучшим вариантом с точки зрения качества являлось бы писание на чистом API той ОС, в которой нарисована программа, но не охота переписывать эту бодягу каждый раз при изъявлении желания начальства увидеть "то же самое под ...".


"Какие есть хорошие кроссплатформенные средства разработки GU..."
Отправлено SergeiZz , 29-Сен-03 13:02 
>>А я использую GLOW -- тогда по-настоящему "везде компилируется" (одинаково легко на
>>Linux, Windows, MacOS).
>а как насчет OS/2?
Этот реликт мне не приходилось использовать.
Я, естественно, упомянул только те системы, на которых сам компилировал
(Linux, Windows). На MacOS компилировали люди, которым я доверяю всецело.
Чтобы компилировать GLOW, в системе должно быть: компилятор c++,
реализация OpenGL, GLUT, стандартные библиотеки C и C++.
Проще говоря, если компилируется GLUT программа, то GLOW тоже.
GLOW -- надстройка над GLUT.

>>Но это, думаю, не совсем то, что требуется.
>Почему?
GLOW идеальна в следующей ситуации. Имеется программка, которой граф.
интерфейс, вобщем-то и не нужен. Но вдруг возникает необходимость эту
программку использовать пользователю-не-разработчику-этой-программки.
Тогда жестоко заставлять его учить бесконечное множество сочетаний
клавиш. Надо бы GUI состряпать, но быстро и переносимо, и просто-просто в
изучении/использовании, но с поддержкой концепции компонентной модели.
GLOW -- идеальна в этой ситуации: это очень простая, но очень добротная
библиотека. Мне лично она подошла тем, что я легко могу заставить средней
руки программиста за очень короткое время её дописать до нужной именно
мне кондиции (простота -- это страшная сила!).

>Быстрое рисование - имеется в виду отсутствие всяких ненужных наворотов,
>как в
>VCL-е
Qt и GTK в этом смысле существенно лучше VCL.

>Java, понятно, тоже не подходит (ну нет в свободной
>продаже Java-машин).
Это я понял как "Java не подходит из-за дефитцита ресурсов".

>HID - Human Interface Devices. Имеется в виду одинаковое использование
>клавиатуры и
>мыши.
Это проблемы реализации OpenGL и GLUT, а не прикладной программы.

>Для рисования предполагается использовать OpenGL (вполне стандартная
>вещь, при этом, конечно, есть
>вопросы ее совместимости с предлагаемой библиотекой).
GLOW есть надстройка над GLUT, в виде GUI, написанном ислючительно на
OpenGL. Qt и GTK имеют соответствующие интерфейсные классы к контексту
OpenGL.

>Остальное - это работа с витками, семафорами, сокетами и т.п. - говорят,
>ACE неплохая штука (и CORBA, вроде, на ней написана).
Про CORBA я могу только матом по историческим причинам...
ACE (Adaptive Communication Environment) -- хорошая идея, но это (и
многое другое из той же оперы), по моему личному убеждению и опыту,
есть (пока?) именно идея, а не что-то, что можно использовать в крупном
проекте. Вам нужно будет сильно подумать, соответствует ли ACE Вашей
задааче. Думается, оно больше подходит для научной работы, нежели
коммерческого проекта.
Замечу в скобках, что оконный менеджер 3Dwm основан таки на Omni CORBA
ORB -- Вам, думаю, стоит разузнать поподробнее, как именно там OmniORB
использован.

>Еще, конечно, есть работа со строками, списками, массивами и т.п., но >STL,
>вроде, действительно "Standart", на крайний случай есть libc, я к ней
>уже привык ;-)...
Добавлю ешё boost.org к этому списку.

>При этом обработка информации является
>задачей первоочередной важности.
==> GLOW

>Иначе говоря, через ПО, сделанное на этой библиотеке, необходимо иметь возможность смотреть
>фильмы с ОЧЕНЬ хорошим качеством. Железо при этом должно быть самое
>обычное, а не 10ГГц/1024Мб.
В OpenGL есть доступ к фрейм буферам.

>Вывод - наилучшим вариантом с точки зрения качества являлось бы писание на
>чистом API той ОС, в которой нарисована программа, но не охота
>переписывать эту бодягу каждый раз при изъявлении желания начальства увидеть "то
>же самое под ...".
==> OpenGL

Успехов.
Ваша задачка блиска к моей практической деятельности.