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

LXF112:KDE4

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
м (Новая: {{Цикл/KDE4}} == Солидная аппаратура == : ''ЧАСТЬ 5 Plasma, о которой мы много говорили на прошлых уроках – самая ...)

Версия 16:33, 4 октября 2009

Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Солидная аппаратура

ЧАСТЬ 5 Plasma, о которой мы много говорили на прошлых уроках – самая яркая, но далеко не единственная подсистема KDE4. В качестве финального аккорда Андрей Боровский припас для вас слой аппаратной абстракции под названием Solid.

Не так давно один известный в Рунете писатель задал сооб- ществу программистов Linux вопрос: почему новые версии KDE все более и более громоздки и прожорливы? Ведь улучшение программы предполагает, в том числе, оптимизацию ее кода... Можно, конечно, ответить – мол, новые версии оболочки удовлетворяют растущим потребностям пользователей. Что, я пола- гаю, будет лукавством: не так уж сильно эти потребности и выросли. Вспомните, когда в последний раз менялся интерфейс самой попу- лярной текстовой оболочки – Midnight Commander? Следует при- знать, что в стремлении к свободному творчеству, которое и при- влекает многих программистов в мир открытого ПО, разработчики будут охотнее добавлять новые функции, нежели оптимизировать старые. Вот почему KDE постоянно растет и вширь, и вглубь, и, в частности, обзавелся системой управления устройствами Solid. Зачем нужен Solid? Разумеется, его смысл и польза заключаются вовсе не в том, чтобы удовлетворять амбиции KDE-программистов. Как вы, конечно, знаете, KDE портируется на множество ОС, в том числе Windows и Mac OS X, и у каждой из них есть собственные средства управления оборудованием. Solid представляет собой универсальный способ взаимодействия с устройствами всюду, где работает KDE. В идеале, система Solid должна сократить количе- ство непереносимого кода в вашем приложении (хотя свести его к нулю все равно не удастся). В этом и заключается ответ на вопрос о том, не лучше ли использовать HAL (на котором основана система Solid) напрямую. Linux HAL поддерживается не на всех платформах, которые намерен завоевать KDE. Кроме того, Linux HAL базируется на Dbus, и эффективная работа с ним предполагает хорошее зна- ние этой своеобразной системы. В процессе же общения с Solid мы находимся в знакомой среде с сигналами, слотами и объектной моделью Qt/KDE. Исследуем дерево устройств Центральным классом Solid является Solid::Device (все классы Solid объявлены в пространстве имен Solid), который представляет устройство. Дать четкое определение того, что является устрой- ством с точки зрения Solid, не так-то просто. Это и процессор, и его загружаемый микрокод, и видеокамера, и ее аудиоподсисте- ма, оптический привод и диск в нем, винчестер и каждый его раз- дел... Если такая модель кажется вам запутанной, вспомните, что в других системах дело обстоит не лучше (в Диспетчер оборудо- вания Windows давно заглядывали?). Устройства Solid образуют иерархию, корнем которой является, конечно, Computer. Чтобы еще больше вас запутать – каждое устройство предоставляет один или несколько интерфейсов, представляемых потомками класса Solid::DeviceInterface. Пока вы еще не успели разочароваться в Solid, поспешим уточ- нить, что может и чего не может эта система. Solid позволяет полу- чать различные сведения об устройствах, в том числе отслеживать их состояние в режиме реального времени. При этом Solid не пре- доставляет собственных средств для обмена данными с устрой- ствами. С помощью Solid вы можете получить имя файла, соответ- ствующего устройству, его идентификатор или другую информа- цию, необходимую для того, чтобы наладить обмен информацией, но его придется выполнять с помощью интерфейса, предостав- ляемого операционной системой. Например, все известные Solid устройства, способные записывать и воспроизводить аудиоданные, предоставляют интерфейс Solid::AudioInterface. У него есть метод driverHandle(), который возвращает значение типа QVariant. Для устройств, которые обслуживают драйверы ALSA, фактическим зна- чением driverHandle() будет запись, содержащая имя звуковой кар- ты (в системе ALSA) и номера первичного и вторичного устройств. Если устройство работает под управлением драйвера OSS, метод driverHandle() вернет строку с именем файла устройства. Практическое знакомство с Solid мы начнем с программы обзо- ра всех устройств, присутствующих в системе. Приложение devtree, чьи исходные тексты вы найдете на диске, покажет вам полный спи- сок устройств с учетом их иерархии (рис. 1).

Доступ к полному списку устройств, поддерживаемых Solid, можно получить с помощью статического метода Solid::Device::allDevices(). Он возвращает нам объект типа QList<Solid::Device>. Простая конструкция 

foreach (const Solid::Device &device, Solid::Device::allDevices()) {
...
}

позволит перебрать все элементы данного списка (роль итератора играет переменная device). Однако последовательный перебор перечня устройств не так уж и интересен. Дело в том, что расположе- ние устройств в списке Solid::Device::allDevices() не учитывает иерар- хических отношений между ними. В программе devtree мы использу- ем рекурсивный метод заполнения виджета QTreeWidget элементами списка (он не самый эффективный, но самый простой – альтернативу рассмотрим в конце статьи): void devtreeView::enumDevices() { ui_devtreeview_base.treeWidget->setColumnCount(3); QStringList hsl; hsl << "UDI" << "Vendor" << "Name"; ui_devtreeview_base.treeWidget->setHeaderLabels(hsl); QTreeWidgetItem * root = NULL; foreach (const Solid::Device &device, Solid::Device::allDevices()) { QStringList sl; if(device.parentUdi() == "") { sl << device.udi() << device.vendor() << device.product(); root = new QTreeWidgetItem(ui_devtreeview_base.treeWidget, sl); break; } } findChildren(root); } void devtreeView::findChildren(QTreeWidgetItem * root) { foreach (const Solid::Device &device, Solid::Device::allDevices()) { if(device.parentUdi() == root->text(0)) { QStringList sl; sl << device.udi() << device.vendor() << device.product(); findChildren(new QTreeWidgetItem(root, sl)); } } } Один из наиболее часто используемых методов класса Solid::Device, udi(), возвращает уникальный идентификатор устрой- ства. В Linux, где Solid основан на FreeDesktop HAL, идентифика- тором устройства служит HAL-адрес устройства (строка вида “/ org/freedestop/Hal/...”). Нам не обязательно разбираться в том, как формируются эти адреса: важно знать, что именно они идентифи- цируют устройства. Метод parentUdi() класса Solid::Device возвра- щает идентификатор родительского устройства, а соответствую- щий ему объект класса Solid::Device можно получить с помощью метода Solid::Device::parent(). Для корневого устройства метод parentUdi() возвращает пустую строку, чем мы и пользуемся в мето- де enumDevices(). После того как корневое устройство найдено, мы вызываем рекурсивно метод findChildren(), который добавляет в виджет ui_devtreeview_base.treeWidget устройства, являющиеся непосредственными потомками корневого. Для каждого найденного устройства наша программа отображает три элемента данных: иден- тификатор устройства, наименование изготовителя (возвращается методом Solid::Device::vendor()) и описание устройства (возвраща- ется методом product()). У класса Solid::Device есть еще и метод icon(), который возвращает строку с именем пиктограммы устрой- ства (пока что непустая строка возвращается только для корневого устройства Computer). Если бы система Solid позволяла только перечислить имею- щиеся в наличии устройства, пользы от нее было бы не очень много. Однако основная задача Solid заключается в том, что- бы информировать систему о различных событиях, связанных с устройствами. Делается это, естественно, с помощью сигналов и слотов. Сигналы, оповещающие систему о событиях, связанных с устройствами, эмитируются объектами специальных классов. На момент написания статьи их существовало три: Solid::DeviceNotifier, Solid::Networking::Notifier и Solid::PowerManagement::Notifier. Объект класса Solid::DeviceNotifier информирует программу о подключении и отключении устройств. Объект класса Solid::Networking::Notifier сообщает о подключении и отключении системы от сети, а объект класса Solid::PowerManagement::Notifier позволяет программе отсле- живать режим работы системы питания. Особняком стоит класс WebcamWatcher, который выполняет функции Solid::DeviceNotifier исключительно для web-камер. На первый взгляд может показаться, что возможности Solid в плане оповещения программ о событиях устройств крайне скромны, но это не так. Помните, что устройствами в Solid считаются самые разные вещи. Объект класса Solid::DeviceNotifier может оповещать программу о таких событиях, как установка нового CD-диска в при- вод, подключение USB-устройства или монтирование нового разде- ла файловой системы. Вполне логично задействовать объект класса Solid::DeviceNotifier в программе devtree для обновления дерева устройств в случае изменения оного. Система Solid предоставляет каждой программе один объект класса Solid::DeviceNotifier. Для получения указателя на него мы воспользуемся статическим методом Solid::DeviceNotif ier::instance(): Solid::DeviceNotifier * dn = Solid::DeviceNotifier::instance(); Объект класса Solid::DeviceNotifier эмитирует два сигнала: deviceAdded() (добавлено новое устройство) и deviceRemoved() (устройство отключено). В качестве аргумента оба сигнала передают строку с идентификатором устройства. Мы связываем оба сигнала со слотом update(), который мы добавили в главный класс нашей программы: dn->connect(dn, SIGNAL(deviceAdded(const QString)), this, SLOT(update())); dn->connect(dn, SIGNAL(deviceRemoved(const QString)), this, SLOT(update())); Слот update() не обрабатывает переданный ему параметр, а про- сто очищает виджет ui_devtreeview_base.treeWidget и заново строит дерево устройств. Разумеется, такой подход нельзя назвать самым эффективным. Для ускорения работы программы можно было бы найти для добавленного/удаленного родительское устройство и перестроить только соответствующую ему часть дерева. Для сборки программы devtree в файл CMakeLists.txt следу- ет добавить данные о заголовочных файлах и библиотеках Solid. Вопреки тому, что говорит документация, все заголовочные фай- лы Solid API хранятся в поддиректории solid стандартной директо- рии include. Переменная CMake KDE4_INCLUDE_DIR уже содержит ее имя. Единственное изменение, которое нужно внести в файл CMakeLists.txt по сравнению со стандартным файлом приложения KDE 4 – это добавить переменную KDE4_SOLID_LIBS в качестве аргумента команды target_link_libraries(). Теперь программу devtree можно компилировать. Интерфейсы устройств В модели Solid объекты класса Solid::Device соответствуют общему понятию «устройство» и позволяют непосредственно получить толь- ко те данные, которые имеют смысл для всех устройств, независи- мо от их типа. Более подробную информацию о каждом устройстве можно извлечь с помощью интерфейсов, которые представлены в Solid объектами класса Solid::DeviceInterface и его потомков. Каждое устройство (то есть корректно созданный объект Solid::Device) пре- доставляет как минимум один интерфейс. Узнать, поддерживает ли устройство определенный интерфейс, можно с помощью метода isDeviceInterface() класса Solid::Device. Его аргументом должно быть значение типа Solid::DeviceInterface::Type, указывающее тип требуе- мого интерфейса. Полный список типов интерфейсов можно найти в документации Solid и файле solid/deviceinterface.h. Например, тип Processor определяет интерфейс ЦП, Block – блочное устройство, StorageVolume – раздел на диске, Battery – аккумулятор. Учитывая структуру Solid, вы не должны удивляться, что среди поддержива- емых типов интерфейсов одновременно присутствуют интерфейсы логических и физических устройств. Если объект Solid::Device поддерживает запрошенный интерфейс, метод isDeviceInterface() воз- вращает значение true. После того как вы выяснили, поддерживает ли устройство неко- торый интерфейс, вы, скорее всего, захотите получить объект, его реализующий. Сделать это можно с помощью метода Solid::Device:

asDeviceInterface(), аргументом которого выступает тип требуемого

интерфейса. В случае успеха метод возвращает указатель на объ- ект класса, производного от Solid::DeviceInterface, соответствующе- го запрошенному интерфейсу. Имейте в виду, что не для каждого значения Solid::DeviceInterface::Type существует свой класс (так, по крайней мере, обстояло дело на момент написания статьи). В приложениях, использующих Solid, довольно часто требует- ся получить список устройств, поддерживающих определенный интерфейс (вполне логично, что программа, которая обрабатыва- ет изображение, поступающее с видеокамер, захочет иметь пол- ный список устройств, поддерживающих интерфейс Camera, а не вообще всех устройств). Для этого можно было бы, конечно, пере- брать полный список устройств системы (как мы делали выше), проверяя, поддерживает ли каждое из них требуемый интерфейс, однако Solid предоставляет нам более простой и эффективный способ. Класс Solid::Device экспортирует несколько статических методов, предназначенных для управления не конкретным устрой- ством, а всем списком устройств Solid (с одним из них, allDevices(), мы уже знакомы). Статические методы Solid::Device::listFromType() и Solid::Device::listFromQuery() позволяют получить подмножество списка устройств, заданное специальными признаками. Нас инте- ресует метод listFromType(), который возвращает список устройств, поддерживающих определенный интерфейс (говоря «устройство», я, разумеется, имею в виду объект класса Solid::Device). Вот как, например, мы можем получить список устройств, поддерживающих интерфейс NetworkInterface: QList<Solid::Device> devlist = Solid::Device::listFromType(Solid::DeviceInterface::NetworkInterface, QString()); Если во втором параметре listFromType() передать идентифика- тор устройства, в результирующий список войдут только сетевые устройства, являющиеся потомками заданного (пустая строка, раз- умеется, означает, что нас интересуют все сетевые устройства). Solid и Plasma Работу с интерфейсами устройств мы продемонстрируем на при- мере динамического плазмоида. Как уже говорилось в LXF110, плазмоиды хорошо подходят для того, чтобы информировать поль- зователя о важных событиях, происходящих в системе. Solid, как мы уже видели, может служить источником такого рода событий.

Для передачи данных от Solid плазмоиду мы воспользуемся стан- дартным механизмом поставщиков данных Plasma (LXF110). Наш плазмоид будет информировать пользователя о состоянии сетевых интерфейсов системы (рис. 2). Полные исходные тексты поставщика данных (архив networkengine) и плазмоида ncview вы найдете на LXFDVD. Networkengine предоставляет один источник по имени NCs. Данные представляют собой массив строк (QStringList), в котором содер- жится перечень сетевых устройств, имена соответствующих сете- вых интерфейсов Linux и MAC-адреса устройств (это, собственно говоря, вся информация, которую можно извлечь из интерфейса NetworkInterface). Рассмотрим объявление главного класса постав- щика данных NetStatEngine: class NetStatEngine : public Plasma::DataEngine { Q_OBJECT public: NetStatEngine(QObject* parent, const QVariantList&); protected: bool sourceRequestEvent(const QString& name); bool updateSourceEvent(const QString& source); private slots: void updateDevices(); }; Основные элементы этого класса должны быть знакомы вам по LXF110 ( в отличие от той статьи, здесь мы используем только син- таксис KDE 4.1.x: пришла пора обновиться, если вы до сих пор этого не сделали). Новый элемент здесь – только слот updateDevices(). В конструкторе класса мы вызываем метод updateSourceEvent(), как и в любом поставщике данных, а затем получаем указатель на гло- бальный объект Solid::DeviceNotifier: NetStatEngine::NetStatEngine(QObject* parent, const QVariantList&)

Plasma::DataEngine(parent)

{ updateSourceEvent("NCs"); Solid::DeviceNotifier * dn = Solid::DeviceNotifier::instance(); dn->connect(dn, SIGNAL(deviceAdded(const QString)), this, SLOT(updateDevices())); dn->connect(dn, SIGNAL(deviceRemoved(const QString)), this, SLOT(updateDevices())); } Как и в рассмотренном выше случае, этот объект нужен нам для того, чтобы связать слот updateDevices() с сигналами deviceAdded() и deviceRemoved(). Рабочая лошадка нашего поставщика данных – метод updateSourceEvent(): bool NetStatEngine::updateSourceEvent(const QString &name) { if (name == "NCs") { QList<Solid::Device> devlist = Solid::Device::listFromType(Solid::DeviceInterface::NetworkInterface, QString()); QStringList sl; foreach (const Solid::Device &device, devlist) { sl << "Device: " + device.parent().product(); Solid::NetworkInterface * ni = (Solid::NetworkInterface *) device.as DeviceInterface(Solid::DeviceInterface::NetworkInterface); sl << "Interface: " + ni->ifaceName(); sl << "Address: " + ni->hwAddress(); sl << QString("Type: ") + (ni->isWireless() ? "Wireless" : "Wired"); } setData(name, sl); return true; } return false; } Наша первая задача – получить список устройств, поддер- живающих интерфейс NetworkInterface, как было описано выше.

Далее мы перебираем все элементы списка сетевых устройств и для каждого из них получаем указатель на объект класса Solid::NetworkInterface посредством метода asDeviceInterface(). Данные, полученные с помощью интерфейсов, заносятся в список QStringList, который передается методу setData(). Метод ifaceName() класса Solid::NetworkInterface возвращает строку с именем интер- фейса (“eth0”, “eth1” и т.д.). С помощью метода hwAddress() мы можем получить MAC-адрес устройства в текстовом виде (метод macAddress() возвращает MAC-адрес в виде числа). Метод isWireless() вернет значение true, если сетевой интерфейс является беспроводным, и false – в противном случае. Чтобы сделать спи- сок сетевых устройств более информативным, мы выводим назва- ние каждого устройства. Его можно получить с помощью метода product() класса Solid::Device; однако для всех устройств, соответ- ствующих сетевым интерфейсам, он возвращает строку “Network Interface”, что, конечно, не очень интересно. Для получения имени физического устройства, предоставляющего сетевой интерфейс, мы вызываем метод product() устройства, являющегося «родите- лем» сетевого интерфейса. Нам осталось рассмотреть вопрос о том, как поставщик данных оповещает плазмоид о подключении и отключении сетевых интер- фейсов (в LXF110, напомним, это происходило в результате перио- дического опроса). Для такого нечастого события, как добавление и удаление сетевых интерфейсов, регулярный опрос, выполняемый плазмоидом, явно избыточен. Для нерегулярных и нечастых собы- тий лучше подходит модель, при которой поставщик сам информи- рует заинтересованный плазмоид об изменении данных. Наладить этот механизм очень просто. Ниже приводится исходный текст сло- та updateDevices(), который обрабатывает сигналы deviceAdded() и deviceRemoved(): void NetStatEngine::updateDevices() { updateSourceEvent("NCs"); } Не удивляйтесь – это действительно все, что необходимо для оповещения плазмоида. Метод updateSourceEvent() вызывает метод setData(), который с помощью соответствующего сигнала активиру- ет слот dataUpdated() в плазмоиде. Наконец, зная про метод listFromType(), мы можем написать улучшенный вариант метода findChildren() для программы devtree: void devtreeView::findChildren(QTreeWidgetItem * root) { QList<Solid::Device> children = Solid::Device::listFromType(Solid::DeviceInterface::GenericInterface, root->text(0)); foreach (const Solid::Device &device, children) { QStringList sl; sl << device.udi() << device.vendor() << device.product(); findChildren(new QTreeWidgetItem(root, sl)); } } Значение Solid::DeviceInterface::GenericInterface соответствует интерфейсу базового типа, который поддерживается всеми устройствами.

На тему программирования для KDE 4 можно было бы написать еще очень много, но мы завершаем наш обзор. Того, что вы узнали о новой версии KDE из этих уроков, вполне достаточно, чтобы написать расширение KDE, которое, возможно, даже оправдает утяжеление будущего дистрибутива на несколько мегабайт. Не забудьте сообщить нам, если получится что-то стоящее!

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