LXF108:KDE4

Материал из Linuxformat.

KDE 4 под микроскопом

ЧАСТЬ 1 Считаете, что для KDE 4 мало приложений? В ваших силах исправить ситуацию – благодаря новой серии учебников от Андрея Боровского!

Два года назад LXF публиковал цикл статей о программировании для KDE 3 (LXF81–85). Тогда это был зрелый рабочий стол, который готовился уступить место KDE 4, и писать о нем было легко, не не слишком интересно. Легко – поскольку KDE 3 на тот момент был хорошо (даже очень хорошо) документирован, а также потому, что существовало много примеров (в том числе написанных мною самим). С другой стороны, было понятно, что цикл разработки KDE 3 практически завершен, и в статьях о нем не удастся отразить живые моменты рождения новых технологий.

С KDE 4 все обстоит иначе. Его первый стабильный релиз появился в начале этого года, и сейчас KDE 4 активно развивается. Далеко не все идеи разработчиков получили окончательное воплощение; по-видимому, и сам список технологий, используемых в KDE 4, будет со временем меняться – я, например, не уверен, что система Decibel, о которой будет сказано ниже, войдет в последующие релизы. Что же касается документации и примеров, то стоит ли говорить, что для многих частей KDE 4 и то, и другое существует либо в зачаточной стадии, либо вовсе отсутствует. Именно поэтому писать о KDE 4 гораздо интереснее. У нас есть возможность проследить глазами программиста рождение нового рабочего стола, с которым пользователи Linux будут жить несколько ближайших лет. Как и в случае с Qt 4, мы будем предполагать, что вы уже знакомы с разработкой для KDE 3. На всякий случай, уроки в формате PDF есть на DVD этого номера.

А внутри у ней плазма

Библиотеки Qt 4.x во многом революционны, и было бы странно, если бы разработчики KDE 4 не подхватили этот «трудовой порыв». На внешних красотах KDE 4, усиленных мощью 3D-ускорителей, мы останавливаться не будем, а скорее поднимем капот (или снимем кожух?) и посмотрим, что же находится внутри. Один из важнейших элементов KDE, который сразу бросается в глаза (в нескольких смыслах слова) – это Plasma. С точки зрения программиста, она – развитие Qt Graphics View Framework (LXF105). Система Corona расширяет возможности QGraphicsScene, добавляя концепцию апплетов. В результате с элементами графической сцены (т.е. рабочего стола) можно связывать мини-приложения. Изначально разработчики Plasma ориентировались на Qt 4.2, в которой, напомню, еще не было встраиваемых виджетов; в результате пришлось придумывать аналогичный механизм для внедрения пиктограмм и кнопок. Теперь, когда данный функционал появился в самой Qt, можно ожидать более широкого использования встраиваемых виджетов в будущих версиях Plasma.

Минуя другие состояния вещества, перейдем от Plasma к технологии Solid. Это – кросс-платформенная подсистема, предназначенная для работы с устройствами. Правда, Solid не позволяет KDE-приложениям управлять ими, но предоставляет достаточно информации, чтобы программа могла подобрать нужные административные средства самостоятельно.

Еще одна интересная и пока что довольно загадочная новинка KDE 4 – Phonon. Это переносимая мультимедиа-подсистема, поставляемая с Qt начиная с версии 4.4. API Phonon состоит из классов высокого уровня, которые унифицируют доступ к различным библиотекам, связанным с мультимедиа. Судя по документации (которая на момент написания статьи была еще не завершена), важную роль в Phonon играют концепция прозрачного доступа к мультимедиа-ресурсам, независимо от того, где они расположены, и унаследованная от Qt система «модель-контроллер-вид».

Технология под названием Decibel должна упростить жизнь разработчикам IP-телефонов, видеофонов, чатов и т.п. Она написана с использованием чистого Qt 4 (т.е. не зависит от KDE), включает в себя реализацию Telepathy и многих других полезных вещей, но, судя по сайту проекта (http://decibel.kde.org), работа над ним застопорилась примерно год назад. Текущая версия – 0.5, что будет дальше – посмотрим.

Инструменты разработчика

Чтобы программировать для KDE 4, нам, конечно, понадобится сама среда. Проще всего воспользоваться дистрибутивом, в котором KDE 4 доступен по умолчанию, но и тут могут возникнуть неожиданные проблемы. Например, в «живом» OpenSUSE 11.0 KDE Four Live с KDE 4.1 Beta2 обнаружилась одна серьезная и надоедливая ошибка – любое приложение KDE 4, выводящее стандартное диалоговое окно, вызывает фатальный сбой в KNotify (о чем тут же сообщает еще один диалог). Поэтому нам придется довольствоваться KDE 4.04, входящим в состав OpenSUSE 11.0. Помимо собственно графической среды, нам, разумеется, понадобятся пакеты разработчика Qt 4.x и KDE 4.x.

На момент написания этой статьи стабильного KDevelop 4 еще не существовало, а нестабильный работал только с тестовой версией KDE 4.1, от использования которой мы с вами отказались. В Сети можно найти трюки, с помощью которых можно создавать приложения KDE 4 в KDevelop 3.x, но мы на них останавливаться не будем: думаю, что KDevelop 4 уже скоро обретет стабильность, и данные советы морально устареют. Лучше потратим сэкономленную журнальную площадь на KDevelop 4, когда он выйдет. Пока же будем применять инструменты низкого уровня: это позволит нам глубже проникнуть в суть вещей в KDE 4. Не считая стандартных инструментов разработчика, нам понадобятся две консольные утилиты: cmake и kapptemplate – мастер, с вызова которого и начинается процесс разработки. Kapptemplate создает заготовки для простого приложения KDE, приложения KDE со сложным главным окном или KPart.

Далее утилита просит указать имя и расположение нового проекта. Программа также захочет «познакомиться» – узнать ваши имя и e-mail. В этом смысле kapptemplate отличается крайней навязчивостью и задает личные вопросы при каждом запуске.

Директория, в которой kapptemplate сохраняет файлы заготовки программы, содержит много интересного (об этом – чуть позже), но в ней отсутствуют Make-файл и сценарий configure, то есть те скрипты, которые мы привыкли использовать для сборки программ KDE 3. Здесь нам на помощь приходит CMake. Этот кросс-платформенный независимый инструмент от компании Kitware стал частью инструментария KDE 4 совсем недавно. Утилита cmake выполняет для проектов KDE (и не только KDE) ту же работу, что qmake для Qt – т.е. создает Make-файл проекта. Cmake вызывает qmake по ходу процесса, и вы должны убедиться, что утилита с таким именем в вашей системе относится к Qt 4, а не 3.x. Для этого наберите в окне консоли:

Рис. 1. Минималистичное приложение KDE 4.

qmake --version

Если qmake «не тот», ситуацию следует исправить с помощью переменной PATH. В самом простом случае (который мы и рассматриваем) для генерации Make-файлов для проекта KDE 4 достаточно скомандовать

cmake <project_path>

где project_path – это путь к проекту. Имейте в виду, что cmake создает выходные файлы, в том числе и Makefile, не в project_path, а в той директории, откуда он был вызван. Теперь, наконец, можно скомандовать

make

и насладиться окном нашего первого приложения KDE 4 (рис. 1). Что же это за зверь такой, сурово указывающий на несвежесть файлов проекта?

find_package(KDE4 REQUIRED)

Через увеличительное стекло

Если ваша программа называется kapp4, то объявление класса главного окна содержится в файле kapp4.h (а его методы – в kapp4. cpp). Класс, реализующий центральный элемент главного окна – KApp4View – располагается в файлах kapp4view.h/kapp4view.cpp и наследует от Ui::kapp4view_base, объявление которого (файл ui_ kapp4view_base.h) генерируется автоматически на основе описания интерфейса программы, содержащегося в kapp4view_base.ui. В этой структуре нельзя не заметить влияния Qt 4.x, и (как вы, наверное, уже догадались) класс kapp4view_base.ui не является потомком QWidget, но содержит инструкции, позволяющие настроить таковой (LXF104). Помимо kapp4view_base.ui, в нашем проекте есть еще один ui-файл – prefs_base.ui, который содержит описание интерфейса окна настроек. Забегая вперед, отмечу, что в KDE 4 вы «бесплатно» получаете мощную систему конфигурации приложения пользователем (правда, все равно уступающую таковой в программе-часах из LXF106).

Вы, наверное, уже озадачились вопросом: как редактировать ui-файлы, если KDevelop отсутствует? Отвечаем: для визуального проектирования интерфейса можно воспользоваться редактором Qt Designer 4.x – он поддерживает и виджеты KDE 4. Файлы settings.h и settings.cpp содержат, соответственно, объявление и определение класса Settings. Он наследует от KConfigSkeleton и является основой движка настройки нашего приложения. Наконец, файл main.cpp, как нетрудно догадаться, предоставляет функцию main() нашей программы.

При анализе исходных текстов мы будем двигаться сверху вниз, т.е. от main() к различным классам. Если отбросить ненужные нам в настоящий момент элементы, то функцию main() можно свести к следующей схеме:

int main(int argc, char **argv) {
KApplication app;
KApp4 *widget = new KApp4;
widget->show();
return app.exec();
}

Класс KApp4 реализует главное окно нашего приложения. Мы не сообщаем объекту app класса KApplication, что widget указывает на главный визуальный объект программы. Рассмотрим объявление Kapp4 подробнее:

class KApp4 : public KXmlGuiWindow
{
Q_OBJECT
public:
/**
* Default Constructor
*/
KApp4();
/**
* Default Destructor
*/
virtual ~KApp4();
private slots:
void fileNew();
void optionsPreferences();
private:
void setupActions();
private:
Ui::prefs_base ui_prefs_base ;
KApp4View *m_view;
QPrinter *m_printer;
KToggleAction *m_toolbarAction;
KToggleAction *m_statusbarAction;
};

Класс главного окна является потомком KXmlGuiWindow, который происходит от класса KMainWindow, наследующего от QMainWindow, наряду с KXmlGuiBuilder и KXmlGuiClient. Ниже приводится листинг конструктора класса главного окна

KApp4::KApp4()
: KXmlGuiWindow(), m_view(new KApp4View(this)), m_printer(0) {
// accept dnd
setAcceptDrops(true);
// tell the KXmlGuiWindow that this is indeed the main widget
setCentralWidget(m_view);
// then, setup our actions
setupActions();
// add a status bar
statusBar()->show();
// a call to KXmlGuiWindow::setupGUI() populates the GUI
// with actions, using KXMLGUI.
// It also applies the saved mainwindow settings, if any, and ask the
// mainwindow to automatically save settings if changed: window size,
// toolbar position, icon size, etc.
setupGUI();
}

Я специально не стал убирать из листинга комментарии, добавленные в него программой-генератором, чтобы показать, что файлы-заготовки, созданные kapptemplate, не только освобождают нас от рутинной работы, но и сообщают полезную для новичков информацию о том, что делают вызываемые функции. Для настройки внешнего вида главного окна, как и в KDE 3, используется система KXMLGUI. Напомню, что главное окно хранит данные о меню, панелях инструментов и командах в файлах *ui.rc, имеющих формат XML. Для нашего приложения тоже был создан такой – это kapp4ui. rc, расположенный в той же директории, что и исполняемый файл. Тем не менее, при каждом запуске программы на консоль будет выводиться сообщение о том, что файл kapp4ui.rc не найден (это не приводит к завершению программы, поскольку, не найдя свой собственный rc-файл, приложение берет стандартный из KDE 4). Наша программа не может найти файл kapp4ui.rc потому, что ищет его не там, где он лежит. Глобально установленные приложения, доступные всем пользователям, хранят свои файлы *ui.rc в общедоступной директории (например, /usr/share/kde4/apps/имя_приложения). Для сохранения ваших персональных настроек следует воспользоваться каталогом ~/.kde4/share/apps/имя_приложения.

Система настройки

Рис. 2. Окно настройки программы KApp4.

Рис. 3. Смена оформления KApp4.

Выше я уже упоминал о том, что стандартный проект приложения KDE 4 по умолчанию снабжается системой настройки. Ее можно разделить на две части: настройка панелей инструментов, сочетаний горячих клавиш – с одной стороны, и конфигурация специфических параметров работы приложения – с другой. Особенность настройки первого типа заключается в том, что, по существу, она одинакова для всех приложений KDE и может быть легко формализована. Однако разработчики KDE на этом не успокоились и сделали все возможное, чтобы охватить и процесс создания средств специфической настройки приложений. Окно специальных настроек (рис. 2) открывается по команде Configure KApp4... меню Settings.

Как мы видим, здесь можно настроить цвет шрифта и фона чей областью, ведь он ничего не делает!) и возраст проекта в днях. В результате внешний вид программы может довольно сильно измениться (рис. 3).

Глобальные установки хранятся в директории /usr/share/kde4/config, а локальные – в ~/.kde4/share/config. После нескольких запусков программы KApp4 я нашел в ней два файла: KApp4rc, где хранятся параметры рабочей области, и kapp4rc, содержащий данные о геометрии главного окна и видимости его элементов. Следует отметить, что многие программы KDE 4 хранят свои параметры конфигурации сразу в нескольких файлах.

Для управления настройками создается глобальный объект класса Settings. Получить указатель на него можно с помощью статического метода Settings::self(). Рассмотрим фрагмент исходного текста класса KApp4, управляющий созданием диалогового окна настроек:

KConfigDialog *dialog = new KConfigDialog(this, "settings",Settings::self());
QWidget *generalSettingsDlg = new QWidget;
ui_prefs_base.setupUi(generalSettingsDlg);
dialog->addPage(generalSettingsDlg, i18n("General"), "package_setting");
connect(dialog, SIGNAL(settingsChanged(QString)), m_view, SLOT(settingsChanged()));
dialog->setAttribute( Qt::WA_DeleteOnClose );
dialog->show();

Рис. 4. Система настройки программы KApp4.

Здесь создается объект dialog класса KConfigDialog, который реализует диалоговое окно. Конструктору класса передается указатель на объект Settings. Далее создается объект generalSettingsDlg класса QWidget. Он должен стать главной страницей окна настроек. Внешний вид объекта generalSettingsDlg задается методом ui_prefs_base.setupUi() (так же, как и в Qt 4). Затем, с помощью метода addPage() новая страница добавляется в окно настроек. Остается только связать сигнал settingsChanged объекта dialog с одноименным слотом объекта m_view (рабочая область окна программы). Обработчик сигнала settingsChanged может извлекать данные об изменениях настроек из строки, переданной ему в качестве параметра, или непосредственно из объекта Settings, который существует глобально (именно так и поступает слот settingsChanged() в рассматриваемой программе). Взаимоотношения между окном KConfigDialog, объектом Settings и рабочей областью окна можно проиллюстрировать графически (рис. 4).

Скорее всего, разработчики KDE 4 почувствовали то же, что чувствуете сейчас вы: программирование всех этих классов настройки вручную слишком утомительно. Поэтому они решили автоматизировать процесс. Для создания класса Settings и его вспомогательного класса была использована специальная консольная утилита – kconfig_compiler. На самом деле это, конечно, не компилятор, а генератор исходных текстов, которые потом компилируются GCC. Исходниками для kconfig_compiler являются два файла – kapp4.kcfg и kapp4.kcfgc. Если вы откроете файл kapp4.kcfg в стандартном окне просмотра Dolphin (мы ведь работаем в KDE 4, не так ли?), то увидите только невразумительное:

color of the background black color of the foreground yellow size of a ball 2

Дело в том, что kapp4.kcfg – файл в формате XML. Чтобы понять, как он выглядит на самом деле, нужно выбрать команду View Document Source. Основные тэги файла *.kcfg – это <kcfgfile>, <group> и <entry>. Тэг <kcfgfile> принимает в качестве параметра имя файла, где будут сохраняться настройки программы. Тэг <group> описывает группу настроек. Его дочерние элементы – тэги <entry> – представляют собой отдельные настройки (имя переменной, в которой будет храниться значение конфигурационного параметра, тип данных, имя настройки, предназначенное для пользователя и значение по умолчанию). Кроме того, файлы *.kcfgc содержат указания для генератора kconfig_compiler. Их можно сравнить с Make-файлами GCC.

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