Разработка оконных приложений linux

Kornienko Bohdan’s Blog

2012-08-20

GTK+: Первое оконное приложение в Linux

Цель: написать оконное приложение с использдованием библиотек GTK;
Операционная система: Fedora 17;
Язык программирования: С/С++;
Инструменты: Gedit, дебаггер gdb, кмпилятор gcc 4.7.0, termintal
Используемые источники дополнительной информации:

1. http://www.gtk.org/documentation.php;
2. Ален И. Голуб Правила программирование Си и Си++ 2001;
3. http://developer.gnome.org/gtk-tutorial/stable/c39.html;
4. www.unknownroad.com/rtfm/gdbtut/gdbuse.html;

. Начнем.
Статья взята из [3]. Практически, она является переводм. Но здесь я использую свое толкование.
Итак, нам необходимо написать оконное приложеное. На первый взгляд это может оказаться сложниым. Но в рузультате вы прийдете к выводу, что это даже проще, чем на Window, даже пользуясь удобными средствами разработки.
Начну с теории. В трех словах. Простая программа с использованием GTK может быть легко написана в одном файле. Для создания оконного оприложения необходимо предворительно установтиь библиотеки (установка которых, в данной статье не обсуждается, автор предполагает, что на компьютере уже установленно все необходимое). Используя диррективу включения необходимо подключить библиотеку gtk.h. В ней находится все необходимое для создания базовых окон и элементов управления и работы с собитиями.
Так же как и в консольном приложении (в принципе во всех программах С/С++), так и в окнном, точкой входа в программу является функция main(argc, argv[]).
Наше приложение будет состоять из окна с одной кнопкой по середине. При нажатии на нее в консоль дебаггера будет выводитсья строка «Hello World. «. Ну конечно! Именно эта строка, а вы как подумали? Это же первое приложение, а традиции нарушать нельзя.
Одной из особенностей оконных приложений является то, что все действия выполняемые в программой начинаются после возникновения определенного события. Отследив событие тому или иному элементу управления, можно запрограммировать действия программы. При нажатие на кнопке будет отслеживаться собыитие «clicked». Для каждого события создается определенная функция, которая вызывается в результате того или иного события.
После инициализации приложения, события отслеживатются специальной функцией gtk_main().
Мы будем отслеживать два события: клик мыши на кнопке, и закрытие окна. Кстати при закрытии окна, на вывод дебаггера будет вызываться функция, которая будет выводить на экран с текстом — «delete event occurred».

Так, основное я довел, а теперь практика.
Подключаем библиотеку GTK:
Теперь опишем функцию, которая будет выполняться при возникновении событи нажатия мыши по кнопке на форме:
На первый взгдя такой стиль описания функций может показаться странным, но он улучшает читабельность программы. К тому же можно написать коментарий к каждому аргументу функции. Функция g_print() выводит текст в консоль при работе дебаггера. Очевидно, что аргументом этой функции является выводимый текст.
Правило 38. Используйте штриховую линию для зрительного разделения подпрограмм из [2]. Штриховая линия помагает визуально отделить функции друг от друга, и улучшает читабельность программы.
Также примечательно обратить внимание на правило 42. Выравнивайте скобки вертикально по левой границе [2]. На первый взгляд стиль Кэрнигана может показаться удобным, но это оказывается наоборот, когда размер текста программы увеличивается.

Продолжаем. Событие, закрытия окна:
Функция gtk_main_quit() выполняет выходи из приложения. После выполнения этого кода, на экран дбеггера выведется текст сообщения и приложение закончит свою работу.

Теперь пишем функцию входа в приложение:
Весь нижеприведнный код помещать внутри этой функци.
Первая строка создает объект окна, вторая элемент управления кнопка.
Далее необходимо обработать аргументы запуска программы, если таковы были:
Теперь выполняем код создания окна, непосредственно:
После создания окна необходимо прописать все действия необходимых событий.
Вызов функции delete_event() при закрытии окна
Функция g_signal_connect() используется для обработки событий. Перывый аргумент указывает соыбтие какого элемента упрваления следует отлавливать. Второй аргумент указывает, какое событи необходимо обработать, в нашем случае это уничтожение окна. Третий — указывает на функцию, вызываемую при возникновении события. Четвертый — указатель на данные передваемые вызываемой функции. Вы наверняка заметили, что у hello() и delete_event() есть аргумент gpointer data. Вот именно в этот аргумент передаются данные.
Может возникнуть вопрос, — «как это окно является элементом управления, ведь window — это окно?». Вообще говоря, все элемнты управления, кнопки, скроллбары, переключатели и т.д., в том числе и окна воспринимаются как окна. Так что, в принципе их можно рассматривать как одно и то же.
Теперь делаем границу 10 пикселей от краев окна:
Создаем кнопку:
Как вы уже смогли понять, вышеуказання функция создает кнопку с меткой «Hello World».
Теперь опишем обработку сигнала нажатия кнопки:
Далее, добавляем созданную кнопку на окно:
gtk_container_add( GTK_CONTAINER( window ), button );

Отображем кнопку и окно:
Затем вызываем функцию, отлавилвающую все события окна. По сути дела, функция gtk_main() и запускает работу приложения.
Ну и на последок возвращаем ноль, при оконочании работы приложения:
Сохраняем файл под именем «base.cpp». Теперь нам необходимо скомпелировать наше приложение с возможностью отладки. Делается это так:
gcc -g base.cpp -o base `pkg-config —cflags —libs gtk+-2.0`

Есть два замечания. Первое, парамент -g нужно ставить перед именем исходно файла, в противном случае компилятор просто выдаст ошибку. Второе — ковычки нужно использовать именно такие, как показано в строке выше. Если использовать символ single quote, компиляции не будет.
Теперь запускаем программу удобным для вас способом, и наслаждаемся своим произведением искусства.

Источник

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

Цилюрик О.И.

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

Источник