>>А я использую 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
Успехов.
Ваша задачка блиска к моей практической деятельности.
Вариант для распечатки
Программирование под UNIX (Public)
on
23-Сен-03, 12:59 (MSK)
