Журнал LinuxFormat - перейти на главную

LXF108:KDE4

Материал из Linuxformat
Версия от 17:11, 24 августа 2009; Yaleks (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

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 и многих других полезных вещей, но, судя по сайту проекта (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. Для этого наберите в окне консоли: 

qmake --version

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

cmake <project_path>

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

make

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

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

Если ваша программа называется 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/имя_приложения.

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

Выше я уже упоминал о том, что стандартный проект приложения 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();

Здесь создается объект 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.

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

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF108:KDE4&oldid=8530»
Персональные инструменты
купить
подписаться
Яндекс.Метрика