Как написать оболочку для линукс

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

Цилюрик О.И.

Настоящая статья является дополнением к книге «Инструменты 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).

Источник

Разработка графических приложений под Linux для Windows Программистов. С чего начать? (перевод)

Разработка графических приложений под Linux для Windows Программистов.

С чего начать?

Переходя с Windows на Linux вы начинате путаться в куче опций. QT или GTK+? Какой язык использовать: c/c++/java/perl/tcl/python/ruby или javascript? Должен ли я использовать коммерческие/проприетарные laypout/rad инструмента (QT или Kylix), либо opensource? А Mozilla? Я умею программировать в Visual Basic и Lotus Notes (Basic, Java, C / C + + API). С чего мне начать?

Начинайте с того что нравится

Я знал, что я люблю язык программирования Python, с его способностью сделать программирование «как можно более простым, но не простейшим» (Эйнштейн). Он позволяет программировать на высоком уровне и ваш разум освобождается для работы по другим вопросам. Поскольку структура кода является неотъемлемой частью языка я считаю, что такой код другим людям гораздо легче читать и понимать. Отсутствие необходимости компилировать экономит мне время на отладку и тестирование. Сбор мусора — это то, что я считать само собой разумеющимся. Так же я могу выбрать подходящий для меня стиль программирования, будь то процедурное, функциональное, объектно-ориентированное или смесь — за счет чего я могу выполнить работу более быстро и эффективно. Приложения могут быть заморожены — сделать для облегчения распространения. Наконец, «batteries included» характерное для Python библиотек способствует повторному использованию кода и скорости развития.

Тем не менее, язык программирования, в идеале не должно быть вашим главным критерием в отборе GUI Toolkit — так что я сделал обследование имеющихся инструментов.

Выбор инструментов

Я рассмотрел TK(2), GTK+(3), QT(4), wxWindows(5), MFC, Windows Forms (.NET), Swing (Java), и FOX(6) и пришел к следующим критериям оценки инструментов:

1. Шаблонизация (Kylix, QT, GLADE)
2. Интерфейс — Объектно-ориентированный язык или полу-OO
3. Завершенность инструмента
4. Количество и типы виджетов
5. Качество виджетов/контролов
6. Потребление ресурсов и Быстродействие
7. Поддержка кроссплатформенности
8. Лицензия
9. Поддержка кросс-языковости

Нативный вид (часто важно для пользователя)

Масштабность сообщества разработчиков

Документация

Легкость изучения

Оценка до 5	TK	GTK+	QT -Kylix	QT	wxWindows	MFC	Windows Forms	Swing	FOX
Шаблонизация (Kylix, QT, GLADE)	2	4	5	5	4	3	5	4	3
Интерфейс — Объектно-ориентированный или полу-OO	2	2	5	5	5	3	5	5	5
Завершенность инструмента	4	4	5	5	4	5	3	3	3
Количество и типы виджетов	3	4	5	5	4	3	5	3	?
Качество виджетов/контролов	3	4	5	5	5	4	5	4	?
Потребление ресурсов и Быстродействие	4	5	5	5	5	5	5	2	?
Поддержка кроссплатформенности	5	5	4	4	5	1	1	2	5
Лицензия	5	5	1	1	5	4	2	2	5
Поддержка кросс-языковости	5	5	1	4	5	2	4	1	?
Нативный вид (часто важно для пользователя)	1	3	5	5	5	5	5	1	5
Масштабность сообщества разработчиков	3	4	4	4	4	5	5	4	3
Документация	4	3	4	5	4	2	3	4	2
Легкость изучения	4	3	4	4	4	1	3	2	?
Весомый итог	55	61	60	64	69	48	54	41
Невесомый итог	45	51	54	58	59	43	51	37

Проприетарная помощь

Три или четыре варианта попираются на вершину. QT и Kylix оба предлагают великолепные, довольно простые в использовании RAD среды. Тем не менее, я использовал FoxPro и Lotus Notes — и я очень устала от собственных решений (оба поддерживают Unix, но я забросил это дело). Закрытость инструмента может очень негативно сказаться на вашем приложении в будущем. Компании создавшие ваше ПО могут принять решение об изменении направления и больше не вкладывать средства в ваш инструмент — и ваше приложение или устаревает, или умирает. Если вы разрабатываете приложение с открытым кодом на QT — вы ограничены в соответствии с лицензией на открытый код. Дорогое лицензии могут быть необходимы для портирования кода на Mac или Windows. Некоторые компании и инструменты (Java & Notes) ограничивают ваше право на распространение кода без дополнительной оплаты лицензий.

Мне нравится нативный вид

GTK+ и TK довольно неуклюже работают под windows и я хотел бы чтобы то что я пишу выглядело замечательно как на windows так и на mac. Посмотрим правде в глаза — большинство пользователей привыкли к использованию родных виджетов и, как правило оценивают приложение, по внешнему виду. Если вы хотите придерживаться стиля Unix то платформа GTK + и PyGTK являются хорошим выбором.

Mozilla — XUL
Другой вариант, кажется интригующим. Им является XUL — XML код, который создает основу для GUI Mozilla.
Среди его преимуществ — кроссплатформенный набор виджетов и возможность установки через браузер (. XPI-файлы) или можно запускать прямо с сервера (на XULPlanet есть прекрасный учебник). Я обнаружил protozilla — который дает способом создания локальных сценариев CGI или с использованием IPC (pipe), — но он показался мне нестабильным. Я также обнаружил, что вы можете получить доступ к COM-объектам через интерфейс IDispatch. Код в настоящее время выключен и не является частью программы Mozilla. Кроме того,код очень сырой, и тщательно не протестирован.
из почтовой рассылки:

Нестабильность Mozilla как платформы для разработки заставила отложить её до лучших времен. Возможно, что все изменится в будущем.

wxWindows

wxWindows это открытый c++ инструмент который работает как тонкая прослойка между родными виджетами — GTK+, WIN32, Mac OS, Motif и т.п. У него имеется интерфейсы для c++, perl, python и ruby. Мне нравится идея набора виджетов, который представляет собой тонкую оболочку вокруг других — тем самым защищая вас от изменений и позволяющий вести кроссплатформенную разработку. Вначале были проблемы запуска WxPython под управлением Linux — Python — WxWindows, но Робин Данни улучшил установку для Linux — и теперь это доступно как обычная установка пакетом.

WxPython была создана Robin, который сделал инструмент, который помогает автоматизировать создание Python классов C или C + + API и WxPython — Python интерфейс для WxWindows. Существуют также интерфейсы для Perl & Ruby для тех, кто предпочитает эти языки. Еще одним преимуществом является возможность использования XML для программирования интерфейса (например, GTK +, QT, XUL). В теории это позволяет отделить графический вид программы от логики отображения. Также я бы хотел отметить, что очень быстро и легко можно создать графический интерфейс приложения. С другой стороны, хотя существует множество фрагментов и примеров кода, имеющихся пособий, большая часть документации, направлена на C + + программистов. Также замечу, что порт на Mac OS X не является полным.

В конце хочется спросить, «Что используют люди поумнее?»

Open Source Applications Foundation приняли решение об использовании WxPython через год раздумий
GNU Entreprise — используют WxPython в качестве основы для приложений клиент-сервер.
Многие другие организации используют WxWindows в той или иной форме

Итак. Какие виджеты я использую?

XRC:
Простой редактор xml widget

Boa:
IDE
Слышал только хорошее и даже немного с ним поигрался

Источник