Программирование графики для linux

Создание графических приложений

Цилюрик О.И.

Настоящая статья является дополнением к книге «Инструменты Linux для Windows-программистов». Это не описание как делать GUI приложения в Linux, это описание того, как ПРИСТУПИТЬ к созданию графических приложений в Linux, и, хотелось бы надеяться что это прозвучит — чем принципиально программирование графики в Linux отличается от того же занятия в Windows. Главным требованием здесь была простота. Сделав простейший шаблон GUI прложения, дальше двигаться уже гораздо проще. Кроме того, все эти простейшие приёмы программирования показаны сравнительно: на основе основных графических технологий (библиотек), используемых в UNIX.

Все примеры к тексту вы можете скачать в виде общего архива.

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

• реализация алгоритмов цифровой обработки сигналов (DSP): быстрые спектральные преобразования (FFT и другие), вэйвлеты, авторегрессионные разложения. ;
• обработка аудио-потоков (пакеты: sox, ogg, speex и другие);
• задачи IP-телефонии, SIP протокола, реализация разнообразных программных SoftSwitch;

Это сравнительный ряд автономных областей развития приведен как пример таких частных классов, одним из которых является и разработка GUI приложений. И как частный класс, со своей спецификой инструментов и средств, он не заслуживал бы отдельного упоминания, если бы не одно обстоятельство — принципиально отличающееся, диаметрально противоположное отношение к GUI в операционных системах семейства Windows и в UNIX (и в Linux, как его частный вид):

• В Windows каждое приложение является принципиально GUI, неотъемлемым атрибутом любого приложения в Win32 API (низкого уровня) является главное окно приложения, уже само приложение «вяжется» вокруг его главного окна. Операционная система регистрирует классы окон и уже далее к ним соотносит конкретные приложения. Не может существовать приложения (взаимодействующего с пользователем, не системные службы) без окна, с этим были связаны и первоначальные сложности Windows в реализации консольных (терминальных) приложений.
• в UNIX картина принципиально обратная: первичным является приложение, которое, по умолчанию, является консольным, текстовым, вся графическая система не является составной частью операционной системы, а является надстройкой пользовательского уровня. Чаще всего такой графической надстройкой является X11 (в реализации Xorg или X11R5), но и это не обязательно: практиковались и другие графические системы, хороший пример тому графические системы Qwindow, а затем Photon в операционной системе QNX, сосуществующие там одновременно с X11.
• Показательно в этом смысле то, что вся оригинальная часть реализации X11 работает в пространстве пользователя, не в привилегированном режиме ядра (супервизора): работа с аппаратурой видеоадаптеров, устройствами ввода и другое. Отдельные реализации (видеосистемы NVIDIA или ATI Radeon) могут быть реализованы в режиме ядра (модули), но это а) сторонние относительно X11 разработки, и б) решение вопросов только производительности.

Из-за обозначенной специфики, разработка GUI приложений в UNIX (Linux) принципиально отличается:

• вся работа GUI приложений ведётся через промежуточные слои (библиотеки) пользовательского уровня;
• из-за того, что это ординарный пользовательский уровень, для разработчика предлагается широкий спектр альтернативных инструментов (библиотек), практически равнозначных, и конкурирующих друг с другом: Xlib, GTK+, Qt, wxWorks и многие другие.
• базовый API работы с X11 предоставляет Xlib, все другие используют уже её функционал, как это показано на рисунке.

• разработчик имеет возможность широкого выбора тех уровня и инструментов, которые он предполагает использовать, начиная от Xlib и выше (хотя уровень Xlib и слишком низок и работа с ним громоздкая).

Из-за названной специфики GUI приложений в Linux, все они, независимо от используемых средств создания, имеют абсолютно сходную структуру. Рассмотрим, для сравнения, код нескольких простейших GUI приложений, подготовленных с помощью различных инструментов. Важнейшей задачей такой экспозиции будут команды компиляции и сборки, чтобы, исходя из таких примеров, показать возможность начать создавать свои собственные GUI приложения.

Средства Xlib (архив Xlib.tgz ):

Средства GTK+ (архив GTK+.tgz ):

$ gcc gtk.c -o gtk `pkg-config —cflags —libs gtk+-2.0`

Средства Qt (архив Qt.tgz ):

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

Теперь проделываем последовательно:

Исходя из «подручных» файлов исходных кодов, у нас сгенерировался файл проекта и, далее, сценарий сборки ( Makefile ). Далее проделываем традиционную сборку, а заодно и посмотрим опции компиляции и сборки, которые нам сгенерировал проект:

g++ -c -pipe -Wall -W -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector —param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables

g++ -o Qt index.o -L/usr/lib/qt-3.3/lib -lqt-mt -lXext -lX11 -lm

index.cc index.o Makefile Qt Qt.pro

Средства wxWidgets (архив wxWidgets.tgz):

$ g++ simple.cc `wx-config —cxxflags` `wx-config —libs` -o simple

Средства GLUT (архив glut.tgz):

OpenGL Utility Toolkit, как и следует из названия, это средства использования технологии OpenGL в приложениях, которая требует определённой поддержки со стороны видео оборудования.

$ gcc glut.c -o glut -lX11 -lglut

То, что показано выше, это фактически не приложения, а скелеты приложений, но они позволяют: а) сравнить подобие всех GUI технологий в X11, и б) быть отправной точкой для сборки более содержательных GUI приложений. Показано только несколько GUI технологий, применяемых в X11 (большинство из них являются кросс-платформенными, и применимы в большинстве существующих операционных систем). Каждая из этих технологий, а названы только немногие из значительно большего числа, присутствующих в UNIX, могут быть полной альтернативой любой другой из этого же ряда, они взаимно заменимы, и даже взаимно дополняемые.

В данной статье были показаны образцы кода GUI приложений. Естественно, визуальные образы таких приложений строятся не путём непосредственного кодирования, а при использовании некоторых визуальных построителей, в составе тех или иных интегрированных средств разработки (IDE).

Источник

Создание GUI в Linux. Часть 1

Создание графических интерфейсов в Linux с помощью библиотек Qt и GTK.

В этой статье мы поговорим о создании графического интерфейса для вашей Linux-программы. Как вы знаете, средствами одного С нормальный GUI (Graphical User Interface – Графический интерфейс пользователя, ГИП) не построишь, тем более что после Windows пользователь очень требователен не только к наличию этого самого GUI, но еще и к дизайну формы (окна программы). Поэтому без дополнительных библиотек вам не обойтись. Самыми распространенными библиотеками для создания GUI являются библиотеки GTK и Qt. Рекомендуется использовать только эти библиотеки, поскольку велика вероятность того, что они уже будут установлены у пользователя (уж GNOME и KDE установлены почти у всех), чтобы не сложилась такая ситуация, когда размер вашей программы 300К, а используемая нею библиотека «весит» 20М. Вот подумайте, зачем пользователю ваша программа и станет ли он закачивать ее из сети? Конечно, если для вашего шедевра нет аналогов в мире, вы можете изрядно поиздеваться над пользователем, используя нестандартную библиотеку GUI. В первой части этой статьи будет рассмотрена библиотека GTK, а во второй – Qt. Сразу следует заметить, что эта статья – не русскоязычное руководство по библиотекам GTK и Qt. Это, скорее, небольшой обзор возможностей библиотек.

Скорее всего, GTK уже будет у вас установлена, но вам нужно будет установить пакет gtk+-devel, содержащий необходимые файлы для разработки GTK-программ.

Не хочется в этой статье рассматривать банальный пример окошка с кнопкой hello world!. Уж слишком уж это просто, да и этот пример вы сможете найти в документации по Gtk.

Сейчас напишем небольшой конфигуратор, который будет вносить изменения в файл /etc/resolv.conf. Напомню вам формат этого файла:

Директива domain определяет наш домен, а две директивы nameserver – первый и второй DNS-серверы, соответственно. Вместо директивы domain можно использовать директиву search, но это кому как нравится. Файл может содержать до 4 директив nameserver, но обычно указываются только два сервера DNS, поэтому мы не будем перегружать себя лишней работой. Но файл resolv.conf не главное в нашей статье – ведь мы разрабатываем GUI. Наш конфигуратор не будет вносить изменения в настоящий файл /etc/resolv.conf – для этого нужны права root, можно, конечно, вызвать auth для аутентификации, но мы не будем этого делать, чтобы не усложнять код программы.

Теперь небольшое вступление в GTK. Элементы ГИП – кнопки, поля ввода, переключатели и тому подобное называется виджитами. Если вы когда-нибудь работали в Delphi, виджиты подобны визуальным компонентам Delphi.

Как и в Delphi, основным элементом GUI является окно (форма в Delphi). Виджиты для размещения в окне помещаются в контейнер. В самом окне выравнивать виджиты можно с помощью вертикальных/горизонтальных боксов или же таблиц. Мне больше нравится второй способ, поэтому мы будем использовать именно таблицы.

Виджиты могут реагировать на сигналы, например, щелчок мышью. При этом вызывается функция-обработчик события (сигнала), если вы определили ее.

В качестве примера нарисуем кнопку и определим обработчик ее нажатия:

А вот функция hello():

Хватит теории, перейдем к практике. На рисунке 1 изображена уже готовая программа. Работает она так. Когда пользователь введет что-нибудь в поле ввода и нажмет Enter, программа отобразит введенный им текст на консоли. Когда пользователь нажмет Ок, введенная им информация будет еще раз выведена на консоль и записана в файл. При нажатии кнопки Quit программа завершит свою работу. Она должна также завершить работу при нажатии кнопки закрытия окна – в GTK программист сам определяет реакции на стандартные кнопки.

Вот текст программы. Внимательно читайте комментарии.

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

Сначала указываются координаты по X, затем – по Y. Вот координаты кнопки Ok: 2,3,0,1. Это означает, что кнопка будет расположена в последнем столбике (2,3), но в первом ряду (0,1). Чтобы было понятнее: ОК по Х находится между 2 и 3, а по Y – между 0 и 1.

Теперь откомпилируем нашу программу:

Можно не использовать опцию -g, добавляющую отладочную информацию – размер файла станет меньше. Программа gtk-config сообщает компилятору всю необходимую информацию о библиотеке gtk. Обратите внимание на директиву #include . Обычно файлы заголовков gtk находятся в другом каталоге, например, gtk-1.2, но это совсем не имеет значения – все необходимые параметры укажет программа gtk-config.

У вас некорректно отображаются русские названия надписей и кнопок? Эта проблема очень быстро устраняется с помощью GNOME Control Center – вам всего лишь нужно выбрать другой шрифт.

Источник

OpenGL. Программирование графики в Linux

Опубликован новый учебный курс, посвященный созданию графических приложений с помощью OpenGL. Рассматриваются различные темы: от простейшего рисования квадрата и GL_QUADS сотоварищи до паттернов, анимации и двойной буферизации. В качестве оконного инструментария используется Qt.

Re: OpenGL. Программирование графики в Linux

Уже пролистал, достаточно интересно.

Re: OpenGL. Программирование графики в Linux

Жалко только что под Qt3 а не Qt4. Впрочем кто знает, там отличий немного, если не глубоко копать.

Re: OpenGL. Программирование графики в Linux

Занимательно. Как-нить поиграюсь на выходных 🙂

Re: OpenGL. Программирование графики в Linux

> Жалко только что под Qt3 а не Qt4.

В комплекте с Qt4 есть Qt4 Demo, Там достаточно примеров использования OpenGL, да и код правильнее.

Re: OpenGL. Программирование графики в Linux

>#include > >int main(int argc,char** argv) > < >QApplication app(argc,argv); > QWidget qwgt; > > app.setMainWidget(&qwgt); > qwgt.show(); > return app.exec(); >>

не собралось под qt4

P.S. а мож че не так делал 🙂

Re: OpenGL. Программирование графики в Linux

Дмитрий Пантелеичев красавчиг, молодец, спасибо за доку.

Re: OpenGL. Программирование графики в Linux

> не собралось под qt4

Так оно под Qt3 🙂

Re: OpenGL. Программирование графики в Linux

надо запускать qmake от qt3

Re: OpenGL. Программирование графики в Linux

> надо запускать qmake от qt3

Таки да. И иметь QTDIR, показывающий на Qt3 тоже не помешает 🙂

Re: OpenGL. Программирование графики в Linux

glut нынче не в моде? :))

Re: OpenGL. Программирование графики в Linux

Re: OpenGL. Программирование графики в Linux

Дожили, млять! Уже ОпенДжиэЛ с КоТяхом за нумером 3 и 4 четко ассоциируется. Мельчают девелоперы, ой мельчают, скоро без обертки на вижуалвасике и helloworld написать не смогут.

Re: OpenGL. Программирование графики в Linux

Ни хрена не компилится под qt3, пишет кучу Undefned reference на QApplication, QGlist и т.д.

Re: OpenGL. Программирование графики в Linux

А для чего нужен Qt в данном случае? Не проще ли создать окно средствами X или вообще используя SDL — будет работать на любой платформе. Довесок мизерный, в сравнении с Qt.

Re: OpenGL. Программирование графики в Linux

нет, примеры для куте3 компиляются

другое дело, что там не всё в конфиге проекта прописано

Re: OpenGL. Программирование графики в Linux

> А для чего нужен Qt в данном случае? Не проще ли создать окно средствами X или вообще используя SDL — будет работать на любой платформе. Довесок мизерный, в сравнении с Qt.

Не проще. Родное API glx достаточно мерзкое + неперносимое. Qt или GLUT позволяют абстрагироваться от этих деталей и сконцентрироваться на OpenGL-коде. Сдается мне, эту тему тут обсуждали две недели назад.

Re: OpenGL. Программирование графики в Linux

> Дожили, млять! Уже ОпенДжиэЛ с КоТяхом за нумером 3 и 4 четко ассоциируется. Мельчают девелоперы, ой мельчают, скоро без обертки на вижуалвасике и helloworld написать не смогут.

Вот какую тему не гляну — обязательно там есть тролль Gharik, которому, как он сам выразился, «нечего делать, пока компилится Gentoo, вот и остается только флеймить на форуме». Gharik, ей-богу, Вы б лучше это время потратили на написание простенькой демки с вращающимся кубом — тогда Ваши слова будут иметь под собой хоть какой-то вес. Или, еще лучше — напишите приложение к туториалу, где в качестве оконного инструментария был бы glut. А то, сдается мне, Вы, как svu, не очень хорошо себе представляете роль Qt в приложении OpenGL. И, в отличие от svu, вообще не слишком хорошо себе представляете, как пишутся программы.

Re: OpenGL. Программирование графики в Linux

> А для чего нужен Qt в данном случае? Не проще ли создать окно средствами X или вообще используя SDL — будет работать на любой платформе. Довесок мизерный, в сравнении с Qt.

Реальный пример: тебе надо сложное GUI приложение (кнопочки, рюшечки и прочие виджеты), а также OpenGL-окно (ну в качестве примера — какой-нить 3Д-редактор и прочие утилитки). Сделать это всё на SDL — запаришся велосипед (GUI) изобретать. Проще использовать Qt, который в этом плане крут.

SDL больше подходит для игр (также как и чистое GLX в иксах). Glut подходит разве что для демок простых. А Qt соответственно для GUI-приложений с трехмерным очком.

Re: OpenGL. Программирование графики в Linux

>Таковы обоснования моего выбора (хотя выбор во многом был >случайным).

После читать трудно. ИМХО для изучения OpenGL нужно именно SDL.
GUI к которому достаточно много. GLUT вобще заброшен.
Опять же GUI приложение с окошечком или областью на OpenGL мало кому нужно чаще всё таки нужно одно opengl окно и всё там.
ИМХО ракетой гвозди забиваем и пример даём на очень узкой областе.

Re: OpenGL. Программирование графики в Linux

Освищение, материалы не описанны.
Текстуры тоже в топке.
Про шедеры я молчу.

Re: OpenGL. Программирование графики в Linux

> Освищение, материалы не описанны. > Текстуры тоже в топке. > Про шедеры я молчу.

А вот господин Gharik обсолютно прав насичёт этого, в отличие от e_val, который сидит в танке и не понимает сути постов, при этом мерзскоязычно пытаясь отвечать на них.

Re: OpenGL. Программирование графики в Linux

> Реальный пример: тебе надо сложное GUI приложение (кнопочки, рюшечки и прочие виджеты), а также OpenGL-окно (ну в качестве примера — какой-нить 3Д-редактор и прочие утилитки). Сделать это всё на SDL — запаришся велосипед (GUI) изобретать. Проще использовать Qt, который в этом плане крут.

Лучше уж имхо тогда GTK юзать, и C++ обертки к нему, чем наслаждатся изучением мета-языка к C++ в QT.

Re: OpenGL. Программирование графики в Linux

> А вот господин Gharik обсолютно прав насичёт этого, в отличие от e_val, который сидит в танке и не понимает сути постов, при этом мерзскоязычно пытаясь отвечать на них.

И в чем интересно конкретно прав г-н Gharik? 😉

Re: OpenGL. Программирование графики в Linux

> Лучше уж имхо тогда GTK юзать, и C++ обертки к нему, чем наслаждатся изучением мета-языка к C++ в QT.

Так нету у GTK+ Gl-виджетов. или они мне неизвестны. Реальные альтернативы Qt здесь — это GLUT и SDL. Qt, на мой взгляд, позволяет наиболее быстро создать Gl-виджет и приступить неспосредственно к изучению OpenGL, которому, собственно, и посвящен курс. А glBegin() — он везде glBegin().

Re: OpenGL. Программирование графики в Linux

В случае Qt хорошо что есть поддержка Pixel Buffer встроенная (которой нет в SDL), это хорошо для кроссплатформенности. Помню долго прикручивал GLX пикселбуфферы к SDL, получился грязный хак, и естественно утратилась кроссплатформенность.

Re: OpenGL. Программирование графики в Linux

> А glBegin() — он везде glBegin().

То есть, понятным всем языком. Набор команд для рисования веера из треугольников абсолютно одинаков и в GLUT, и в Qt (за SDL не скажу — не работал). Курс посвящен _OpenGL_, а не Qt. Выбор Qt как оконного инструментария имеет свои преимущества, и в рамках курса, и сам по себе, но не нравится Вам — Бога ради, используйте хоть голый GLX 😉 OpenGL от этого не меняется.

А вот текстуры и материалы с освещением — это замечания по существу, спасибо.

Re: OpenGL. Программирование графики в Linux

> Так нету у GTK+ Gl-виджетов. или они мне неизвестны.

Re: OpenGL. Программирование графики в Linux

Значит, неизвестны 🙂 Рад за GTK+

Re: OpenGL. Программирование графики в Linux

> А вот текстуры и материалы с освещением — это замечания по существу, спасибо.

а — так будут ещё статьи в этом курсе? Если да, то это хорошо, в новости об этом не сказано. Тогда действительно пофиг, QT или другой враппер используется.

libgtkgl2.0-dev — Gimp Toolkit OpenGL area widget include files and static library

libgtkglext1-dev — OpenGL Extension to GTK (development files)

Re: OpenGL. Программирование графики в Linux

помоему чем заморачиватся с чистым opengl, лучше взять любой движок и начать ваять на нем. Благо их щас выбирай на любой вкус — Crystal Space, Irrlicht, Ogre etc

Re: OpenGL. Программирование графики в Linux

> Реальный пример: тебе надо сложное GUI приложение

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

Я сам сторонник Qt, как весьма удобного инструментария написания GUI-приложений. Но в данном случае, действительно проще было бы использовать SDL. Проще для понимания «учеником» именно OpenGL, а не обертки. IMHO, есссно 🙂

Re: OpenGL. Программирование графики в Linux

> помоему чем заморачиватся с чистым opengl, лучше взять любой движок и начать ваять на нем

Зависит от целей тех, кому предназначен данный материал. Для написания игрушки — да, возможно. Для написание блендера — маловероятно, что игровые движки подойдут 🙂

Re: OpenGL. Программирование графики в Linux

> Для написание блендера — маловероятно, что игровые движки подойдут 🙂

В блендере, если кто забыл, весь интерфейс отрисовывается средствами OpenGL.

Re: OpenGL. Программирование графики в Linux

> В блендере, если кто забыл, весь интерфейс отрисовывается средствами OpenGL.

Ну хорошо, пусть будет не Blender, а Varicad 🙂

Re: OpenGL. Программирование графики в Linux

>> Для написание блендера — маловероятно, что игровые движки подойдут 🙂

> В блендере, если кто забыл, весь интерфейс отрисовывается средствами OpenGL

Гм. Может ты чего не то отквотил или как-то не так понял написанное ? Или в блендере используется движок от FPS-игрушки ? 😀

Re: OpenGL. Программирование графики в Linux

>> В блендере, если кто забыл, весь интерфейс отрисовывается средствами OpenGL

> Гм. Может ты чего не то отквотил или как-то не так понял написанное ? Или в блендере используется движок от FPS-игрушки ? 😀

это в пику тем, кто говорит, что GLX не портируемый — ессно, под Win используются WINAPI для OpenGL.

Re: OpenGL. Программирование графики в Linux

> это в пику тем, кто говорит, что GLX не портируемый — ессно, под Win используются WINAPI для OpenGL.

2anonymous: извините, неудачно процитировал, игровой движок ессесно не имелся ввиду :).

Re: OpenGL. Программирование графики в Linux

> это в пику тем, кто говорит, что GLX не портируемый — ессно, под Win используются WINAPI для OpenGL.

Имелось ввиду, что кусок кода, ответственный за поддержку пикселбуферов, при использовании SDL, прийдется переписать и под Win32 и под MacOS, а при использовании Qt переписыватьт не прийдется.

P. S. В современных видеокартах на замену пикселбуфферам пришел FBO (frame buffer object), позволяющий писать платфоменнонезависимый код, но на наличие современных видеокарт, пока, расчитывать не приходеццо.

Re: OpenGL. Программирование графики в Linux

>Реальный пример: тебе надо сложное GUI приложение (кнопочки, рюшечки и прочие виджеты), а также OpenGL-окно (ну в качестве примера — какой-нить 3Д-редактор и прочие утилитки). Сделать это всё на SDL — запаришся велосипед (GUI) изобретать. Проще использовать Qt, который в этом плане крут.

Ровно как и FLTK1/2 (Fl_Gl_*) или FOX (FXGL*). Просто Qt в разы более распространён.

Re: OpenGL. Программирование графики в Linux

>Ровно как и FLTK1/2 (Fl_Gl_*) или FOX (FXGL*). Просто Qt в разы более распространён.

Кстати оба кросcплатформенные как и Qt

Re: OpenGL. Программирование графики в Linux

>Зависит от целей тех, кому предназначен данный материал. Для написания игрушки — да, возможно. Для написание блендера — маловероятно, что игровые движки подойдут 🙂

А как вы думаете, кого больше — писателей игр или писателей, например, систем инженерных расчётов с трёхмерной движущейся визуализацией?

Re: OpenGL. Программирование графики в Linux

> Gharik, ей-богу, Вы б лучше это время потратили на написание простенькой демки с вращающимся кубом

Стандартные алгоритмы на разных языках переписывать только велосипедостроители из когорты КДЕшнегов могут. А если вспомнить на чем основано КДЕ, то выводы и вовсе очевидны, о мой хороший друг.

> А то, сдается мне, Вы, как svu, не очень хорошо себе представляете роль Qt в приложении OpenGL.

Вы случайно не философ от марксистско-ленинского пантеона? А то помню, одна такая зараза у меня требовала в своё время описать роль оного в производстве стальных канатов, руки чесались повесить на этом самом канате. Фтопку КуТэ, реальный софт использует Motif/Tk и без вариантов.

> И, в отличие от svu, вообще не слишком хорошо себе представляете, как пишутся программы.

Не поверишь, дядя, но смотрю «как пишутся большие и серьёзные программы» и рыдаю. До того дошёл, что уволился нафиг, теперь буду в универе преподавать, лишь бы в долбаное ИТ снова не соваться. А самые правильные программы давным давно написаны, причем строго в vim/emacs. А те «программы», что пишутся сейчас большинством «программонапейсателей» (ТМ), годятся разве что на ритуальные распечатки на туалетной бумаге для последующей утилизации.

Re: OpenGL. Программирование графики в Linux

GLUT издох, кстати, а про QT как обёртку — никто и не спорит. Но давайте таки не путать тёплое с мягким, покажите мне хотя бы один кутешный, сдл-ный или глют-овый вызов, скажем, в нативном glxgears.

Ибо «прикрутка юзер интерфейса» и «программирование графики» — неколько разные таки вещи, первое вообще в vi для подсоса в libglade за 5 минут ваяется.

Re: OpenGL. Программирование графики в Linux

Статья, конечно, полезная, но LOR есть LOR, буду ругать:
шаблоны, по моему, вещь слишком специфичная и редко используемая(да и вообще устаревшая), чтоб уделять им целую главу(в отличии от освещения),
про полигоны, отличные от треугольников, тоже лучше особо и не думать,
а вместо 2d IMXO лучше допустить лишнюю сущность — glu (ради gluLookAt (и примеров моделей)), но зато сразу изучать OpenGL в «естественных условиях»

Re: OpenGL. Программирование графики в Linux

> Не поверишь, дядя, но смотрю «как пишутся большие и серьёзные программы» и рыдаю. До того дошёл, что уволился нафиг, теперь буду в универе преподавать, лишь бы в долбаное ИТ снова не соваться.

Ну тогда вопросов больше не имею. Человек, осознавший, что этот мир плох — страшный человек 🙂 Как преподаватель вуза очень хочу надеяться, что Вам не удастся заразить студентов ни своим фанатизмом, ни своим пессимизмом. Ибо и то, и другое — смерть для разработчика, что Вы своим примером (см. цитату выше) и демонстрируете.

Re: OpenGL. Программирование графики в Linux

> Ибо «прикрутка юзер интерфейса» и «программирование графики» — неколько разные таки вещи, первое вообще в vi для подсоса в libglade за 5 минут ваяется.

Вот я именно это и стараюсь втолковать. Курс посвящен программированию графики (с использованием OpenGL), а какой там оконный инструментарий — дело десятое.

А что касается теплого с мягким

> покажите мне хотя бы один кутешный, сдл-ный или глют-овый вызов, скажем, в нативном glxgears.

Покажите мне glxgears, который компилируется и работает на X, Mac и Win и при этом не содержит в себе тонны #ifdef’ов 😉

Re: OpenGL. Программирование графики в Linux

ЗЫ
а в конце- нет освещения, так может для восприятия объема хотя-бы туман включить и/или режим WireFrame(всего-ведь одна понятная команда) — а то сейчас глаза болят даже на скриншоты смотреть

Re: OpenGL. Программирование графики в Linux

> Покажите мне glxgears, который компилируется и работает на X, Mac и Win и при этом не содержит в себе тонны #ifdef’ов 😉

Дык на жабе, естественно! Там даже фреймворк под это дело был 😉

Re: OpenGL. Программирование графики в Linux

> Ну тогда вопросов больше не имею. Человек, осознавший, что этот мир плох — страшный человек 🙂 Как преподаватель вуза очень хочу надеяться, что Вам не удастся заразить студентов ни своим фанатизмом, ни своим пессимизмом. Ибо и то, и другое — смерть для разработчика, что Вы своим примером (см. цитату выше) и демонстрируете.

Мы не разработчики и даже не админы, мы инженеры-механики и торговцы нефтью — не стоит упускать сие из виду 🙂

Re: OpenGL. Программирование графики в Linux

>Дык на жабе, естественно! Там даже фреймворк под это дело был 😉

Источник