]> Bernd Gehrmann

bernd@kdevelop.org

2001 2002 Bernd Gehrmann (перевод на русский - (С) 2004 Николай Шафоростов, http://program.net.ua) &FDLNotice; Документ содержит краткий обзор архтитектуры KDE Development Platform KDE архитектура разработка программирование tdecore tdecore - основа, каркас для любого приложения KDE. Она обеспечивает доступ к системе конфигурации, обработке командной строки, загрузке и управлению значками, межпроцессное взаимодействие и т.д. tdeui Библиотека tdeui содержит большое количество элементов управления и стандартных диалогов, которых нет в Qt или которые имеют расширенную функциональность по сравнению с их аналогами. tdeio Библиотека tdeio содержит удобства для асинхронного, сетевого файлового ввода/вывода и доступ к обработчику mimetype. Она также содержит диалог открытия файлов и его вспомогательные классы. kjs Библиотека kjs содержит реализацию JavaScript. tdehtml Библиотека tdehtml содержит компонент TDEHTML, виджет для отображения HTML, DOM API, включая интерфейсы к Java и JavaScript. Каркас приложения - классы, требуемые для любого KDE-приложения. инициализация и контроль приложения Позволяет запускать только один экземпляр приложения. Хранение и отображение информации об авторах программы. Обработка ключей командной строки. Доступ к иерархической базе данных конфигурации KDE, глобальные параметры и ресурсы приложения. Доступ к файлам конфигурации KDE. Простой доступ к простым файлам конфигурации. Доступ к файлам .desktop. Доступ к общим настройкам. Обработка имён файлов и URL - разбор URL по частям, временные файлы. Обработка URL. Работа с временными файлами. Сохранение файлов. Взаимодействие процессов - DCOP. Запуск и контроль дочерних процессов. Запуск дочерних процессов через оболочку. Связь с дочерними процессами через псевдотерминал. Простой механизм IPC, использующий X11 ClientMessages. Отправка сообщений DCOP. Класс-прослойка, для публикации Qt-свойств через DCOP. Класс-прослойка, для публикации интерфейса DCOP для действий. Вспомогательные классы - управление памятью, регулярные выражения, работа со строками, произвольные числа POSIX-совместимые регулярные выражения Тонкий интерфейс к работе со строками. Эффективное выделение памяти для больших групп маленьких объектов. (Псевдо)случайный генератор чисел (см. также /dev/random). Комбинации клавиш. Коллекция комбинаций клавиш. Простой доступ к стандартным комбинациям клавиш. Коллекция системных комбинаций клавиш. Обработка изображений - загрузка и управлений значками. Загрузка значков. Вспомогательные классы для TDEIconLoader. Класс растра. Растровые эффекты наподобие градиентов м заливки. Быстрое преобразование QImage в QPixmap. Drag and Drop. Перенос URL. Перенос цветов. Перетаскивание нескольких объектов одновременно. Автозавершение Общее завершение строк. Автозавершение строк URL. Автозавершение имён программ. Виджеты - классы элементов управления для списов, правил, выбора цветов и т.д.. Вариант QListView. Вариант QListBox. Вариант QIconView. Вариант QLineEdit с поддержкой завершения. Вариант QComboBox с поддержкой завершения. Выпадающий список для выбора шрифтов Выпадающий список для выбора цветов Кнопка для выбора цветов Выпадающий список для выбора файлов и URL. Выбор имён файлов и URL. Элемент управления линейки анимация. Ввод чисел. Ввод паролей. Диалоги. Выбор файла. Выбор цвета. Выбор шрифта. Выбор значка. Ввод комбинаций клавиш. Изменение панелей инструментов. Совет дня. Диалог "О программе". Простой диалог для ввода текста. Простой диалог для ввода URL. Вывод сообщений. Ввод паролей. Действия и XML GUI Абстракция для действия, котрое можно подключить к меню или панели инструментов. Набор действий. Часть GUI, состоящая из коллекций действий и дерева DOM, представляющего их расположение в GUI. Управление активацией клиентов XMLGUI. Модули и компоненты Динамически загружаемая библиотека. Загрузка совместно используемых библиотек. Фабрика объектов в модулях. Тип службы Служба Представляет MIME-тип. Пользовательские настройки для обработки MIME-типов. Запрос служб. Низкоуровневая графическая модель Qt основывается на возможностях, предоставляемых X11 или другими графическими моделями, в которые портирована Qt. Но в ней также есть расширенные функции, такие как произвольные преобразования для текста и растра. Центральный графический класс для двухмерного рисования с Qt называется QPainter. Он может рисовать на QPaintDevice. Реализовано 3 устройства для рисования: QWidget, представляющий элемент управления на экране, QPrinter, представляющий виджет в виде вывода Postscript, и QPicture, позволяющий записывать и воспроизводить команды рисования (с диска) в формате SVG. Такое рисование используется преимущественно в методе paintEvent() класса элемента управления. void FooWidget::paintEvent() { QPainter p(this); // Setup painter // Use painter } При рисовании на принтере не забудьте вызывать QPrinter::newPage() для сигнализации о необходимости смены страницы. Также, при печати, вы можете использовать метрику устройства для подсчёта координат. По умолчанию, при использовании QPainter, прорисовка происходит в системе координат устройства. Это значит, что если вы рисуете линию по оси абсцисс с длинов в 10 единиц, её длина на экране будет составлять 10 пикселей. Однако, QPainter может применить некоторое преобразование перед прорисовкой фигур и кривых. Оно переносит координаты x и y линейно в x' и y' соответственно. Матрицу 3x3 в этом равенстве можно получить с помощью QPainter::setWorldMatrix(), она имеет тип QWMatrix. Это должна быть тождественная матрица, т.е. m11 и m22 равны единице, остальные параметры - нулю. Три типа преобразований: Перемещает все точки объекта на определённую величину в определённом направлении. Трансляционная матрица может быть получена вызовом метода m.translate(dx, dy). Это отвечает матрице Растянуть или сжать координаты объекта, делая его больше или меньше и сохраняя пропорции. Масштабирование можно применить к матрице методом m.scale(sx, sy). Установкой любого из этих параметров в отрицательное значение, можно достичь зеркального отображения. Искажение координатной системы с двумя параметрами - m.shear(sh, sv) (англ.: "shearing" - сдвиг) Вращение обеспечивается методом m.rotate(alpha). Величина угла задаётся в градусах. Вращение - суть масштабирование и искажение Вот некоторые иллюстрации: a) Без преобразований b) Вращение на 30 градусов c) Искажение 0.4 d) Зеркальное отражение Преобразования можно совмещать с умножением элементарных матриц. Помните, что операции с матрицами не являются коммутативными, поэтому обращайте внимание порядок множителей. Прорисовка линий, кривых и контуров многоугольниковможет быть изменена установкой специального пера через QPainter::setPen(). Аргумент этого метода - объект типа QPen. Он содержит такие параметры как стиль, цвет, тип соединения и концов. Стиль пера - член enum Qt::PenStyle и может принимать следующие значения: Стиль соединение - член enum Qt::PenJoinStyle. Он указывает метод соединения нескольких линий. Он может принимать следующие значения: a) MiterJoin c) BevelJoin b) RoundJoin Стиль концов является членом enum Qt::PenCapStyle и определяет как рисовать концы линий. Возможные значения: a) FlatCap b) SquareCap c) RoundCap Тип заливки многоугольников, окружностей и прямоугольников можно изменить установкой специальной кисти через QPainter::setBrush(). Она берёт аргумент типа QBrush. QBrush::QBrush() - кисть, не заполняющая фигуры. QBrush::QBrush(BrushStyle) - чёрная кисть. QBrush::QBrush(const QColor &, BrushStyle) - Цветная кисть. QBrush::QBrush(const QColor &, const QPixmap) - Цветная кисть с заданным узором. Стиль кисти - enum Qt::BrushStyle. Иллюстрация всех стандартных узоров: Для ещё большего изменения поведения кисти используйте QPainter::setBrushOrigin(). В Qt цвета представлены классом QColor. Qt не поддерживает расширенную функциональность типа цветовых профилей ICC и сглаживание цветов. Цвета указываются по RGB. Также возможно использовать оттенки, насыщенность и величина (HSV). Эти параметры напрямую используются в диалоге выбора цвета GIMP. Оттенок отвечает уголку на полосе цвета, насыщенность отвечает расстоянию до центра окружности. Величину можно выбрать отдельным ползунком. Обычно, точки, которые вы рисуете заменяют те, которые были до них на том же месте. Например, если вы нарисуете квадрат красным цветом, а потом повторите действие, лишь изменив цвет на синий, вы увидите синий квадрат. Пока что Qt не поддерживает прозрачность. Тем не менее, существует простой путь совместить фон и передний план с булевыми операторами. Метод QPainter::setRasterOp() устанавливает используемый оператор, из enum RasterOp. По умолчанию установлен CopyROP, который игнорирует фон. Однако вы можете выбрать XorROP. Если вы нарисуете чёрную линию с этим оператором на цветном изображении, цвет покрываемой линией области будет обращён. Далее приводится список графических элементов, поддерживаемых QPainter. Большинство из них имеют несколько перегруженных версий, поэтому принимают различный набор аргументов. Например, методы, работающие с прямоугольниками обычно принимаю либо QRect, либо 4 числа. Рисование точки - drawPoint(). Рисование линий - drawLine(), drawLineSegments(), drawPolyLine(). Рисование и заполнение прямоугольников - drawRect(), drawRoundRect(), fillRect(), eraseRect(). Рисование и заполнение окружностей, эллипсов и их частей - drawEllipse(), drawArc(), drawPie, drawChord(). Рисование и заполнение многоугольников - drawPolygon(). Рисование кривых bezier - drawQuadBezier() [drawCubicBezier в Qt 3.0]. Qt предоставляет два различных класса для работы с изображениями. QPixmap отвечает растровым объектам X11. Растры - это объекты стороны сервера и могут - на новых графических картах - даже храниться в их памяти. Поэтому работа с ними происходит очень быстро. Растры также выступают эквивалентами элементов управления - класс QPixmap является подклассом QPaintDevice, так что вы можете рисовать на нём с QPainter. Элементарные операции рисования обычно оптимизируются современными графическими картами. Поэтому, можно использовать растры для двойной буферизации ("double buffering"). Это означает рисовать не прямо на элементе управления, а на временном растре, а потом вызывать функцию bitBlt чтобы передать его виджету. Для сложных перерисовок, это помогает предотвратить мигание. Объекты QImage располагаются на стороне клиента. Основное ударение поставлено на прямой доступ к точкам изображения. Это упрощает операции манипуляции с изображениями, загрузку и сохранение на диск (метод QPixmapload() берёт QImage как промежуточный). С другой стороны, рисование на элементе управления - дорогая операция, т.к. включает в себя передачу X-серверу. В зависимости от глубины цвета, преобразование из QImage в QPixmap может требовать dithering. Текст можно нарисовать одним из вариантов перегруженной функции QPainter::drawText(). Шрифт можно установить функцией QPainter::setFont(). Есть также параметр, представляющий их себя комбинацию флагов ORed из enums Qt::AlignmentFlags и Qt::TextFlags Начиная с версии 3.0, Qt также поддерживает языки с письмом справа налево. Чтобы отобразить текст с оформлением, воспользуйтесь классом QSimpleRichText. При этом в текст нужно включать базовую HTML-разметку (включающую, тем не менее даже таблицы). Стиль текста можно изменить с помощью QStyleSheet. Для прорисовки такого объекта используйте метод QSimpleRichText::draw(). QPainter обеспечивает мощную низкоуровневую модель для рисования на элементах управления и растрах. Однако, рисование более сложных объектов с его помощью может оказаться непосильной задачей. Каждый раз, когда элемент управления получает событие рисования, ему нужно проанализировать QPaintEvent::region() или QPaintEvent::rect(). Затем ему нужно установить QPainter и нарисовать все объекты, которые перекрывают эту область. Например, представьте себе программу векторной графики, позволяющую перетаскивать объекты типа многоугольников, окружностей, и их групп. Каждый раз при наименьшем перемещении объектов, обработчик событий мыши создаёт событие перерисовки для всей области, занимаемой объектами в старой и новой позициях. Вычисление необходимых перерисовок и их выполнение оптимальным способом может составлять трудность, и может конфликтовать с объектно-ориентированной структурой кода программы. Как выход, Qt предлагает класс QCanvas, в котором можно располагать графические объекты, такие как многоугольники, текст, растры. Дополнительные элементы можно создать созданием подкласса QCanvasItem или одного из его специализированных подклассов. Канва (от англ. холст) может отобаржаться одним или более элементами управления класса QCanvasView, которые вы должны пол=делить на подклассы для взаимодействия с пользователем. Qt заботится о всех перерисовках в представлении самостоятельно. Т.к. при этом используется двойная буферизация, это позволяет избавиться от мигания. Элементы канвы могут перекрывать один другого В этом случае видимость объектов определяется т.н. z-порядком, который можно изменять методом QCanvasItem::setZ(). Их можно вообще скрывать. Также, вы можете выбрать фон. Для ассоциации событий мыши в канве есть метод QCanvas::collisions(), возвращающий список элементов, перекрывающих данную точку: Здесь сетка нарисована на фоне. Кроме них там есть элементы QCanvasText и фиолетовый QCanvasPolygon. Бабочка представлена растром QCanvasPixmap. Он имеет прозрачные области. Руководство по использованию QCanvas для написания sprite-based игр можно найти тут. Стандартом де-факто для прорисовки трёхмерной графики на сегодня является OpenGL. Реализации этой спецификации поставляются с Microsoft Windows, Mac OS X и XFree86, и часто поддерживают аппаратное ускорение. OpenGL сам по себе только занимается прорисовкой на указанной области фреймбуфера через GL context и не взаимодействует с инструментарием среды. Qt предоставляет элемент управления QGLWidget, инкапсулирующий окно с ассоциированным контекстом GL. Используйте его, создавая его подкласс и переопределяя некоторые из его методов. Вместо повторной реализация paintEvent() и использования QPainter для прорисовки содержимого элемента управления, замещайте paintGL() и используйте команды GL для прорисовки сцены. QLWidget позаботится о создании его контекста GL перед вызовом paintGL() и очистит его. Виртуальный метод initializeGL() вызывается перед первым вызовом resizeGL() или paintGL(). Его можно использовать для конструкции списков отображения для объектов и других инициализаций. Вместо повторной реализации resizeEvent(), заместите resizeGL(). Это может быть использовано для установки соответствующей области просмотра. Вместо вызова update() по изменении состояния сцены - например при анимировании по таймеру - вызывайте updateGL(). Это приведёт к перерисовке. В общем, QGLWidget ведёт себя также, как и любой другой элемент управления, например вы можете обрабатывать события мыши как обычно, изменять размер и совмещать его с другими объектами. Qt поставляется с несколькими примерами использования QGLWidget в demo. Набор руководств на эту тематику можно найти здесь, и больше информации и справочник OpenGL доступно на сайте OpenGL. OpenGL является относительно низкоуровневым интерфейсом для рисования трёхмерной графики. Как QCanvas предоставляет интерфейс более высокого уровня для двухмерной графики, так Open Inventor является трёхмерным аналогом канвы. Изначально эта технология была реализована SGI, но на данный момент есть также версия с открытым исходным кодом Coin, сопровождающаяся связью с SoQt. Основна Open Inventor - сцена. Сцену можно загрузить с диска и сохранить в специальном формате, тесно связанным с VRML. Сцена состоит из набора объектов, называющихся узлами (nodes). Inventor уже предоставляет набор узлов таких как кубы, цилиндры и сплетения (нити), источники света, материалы, камеры и т.д. Узлы представлены классами C++ и могут комбинироваться и разделяться на подклассы. Введение в Inventor можно найти здесь (в общем, все упоминания SoXt в этой статье можно заменить на SoQt). Модель действия позволяет инкапсулировать действия, вызываемые пользователем в объекте, который может быть "подключён" где-нибудь в меню или панелях инструментов, но она не отвечает за составление меню как таковых. В частности, вам нужно построить все меню в коде C++ и явно вставить действия в определённом порядке. Таким образом, трудно сделать меню. Проблема решается набором классов XMLGUI. Это отделяет действия (в C++) от их отображения в меню и панелях инструментов (в XML). Без изменения исходного кода, меню можно легко подкорректировать изменением XML-файла. Более того, это позволяет удостовериться, что стандартные действия (типа ФайлОткрыть... или СправкаО программе) отображаются на месте, рекомендуемом руководством по стилю. XMLGUI особенно важны для модульных программ, где пункты, появляющиеся в меню могут обеспечиваться разными модулями и компонентами. Класс KDE верхнеуровневого окна, TDEMainWindow, наследует KXMLGUIClient и, следовательно, поддерживает XMLGUI. Все действия, созданные с ним должны иметь actionCollection() как родителя. ВызовcreateGUI() приведёт к построению целого набора меню и панелей инструментов, описанных в XML-файле (обычно с расширением.ui). Далее мы берём программу просмотра KDE KView в виде примера. Его файл ui.rc носит имя kviewui.rc, устанавливаемый заготовкой Makefile.am rcdir = $(kde_datadir)/kview rc_DATA = kviewui.rc Вот выдержка из kviewui.rc. Для простоты мы приводим только меню Вид. <!DOCTYPE kpartgui> <kpartgui name="kview"> <MenuBar> <Menu name="view" > <Action name="zoom50" /> <Action name="zoom100" /> <Action name="zoom200" /> <Action name="zoomMaxpect" /> <Separator/> <Action name="fullscreen" /> </Menu> </MenuBar> </kpartgui> Соответствующий код C++: KStdAction::zoomIn ( this, SLOT(slotZoomIn()), actionCollection() ); KStdAction::zoomOut ( this, SLOT(slotZoomOut()), actionCollection() ); KStdAction::zoom ( this, SLOT(slotZoom()), actionCollection() ); new TDEAction ( i18n("&Half size"), ALT+Key_0, this, SLOT(slotHalfSize()), actionCollection(), "zoom50" ); new TDEAction ( i18n("&Normal size"), ALT+Key_1, this, SLOT(slotDoubleSize()), actionCollection(), "zoom100" ); new TDEAction ( i18n("&Double size"), ALT+Key_2, this, SLOT(slotDoubleSize()), actionCollection(), "zoom200" ); new TDEAction ( i18n("&Fill Screen"), ALT+Key_3, this, SLOT(slotFillScreen()), actionCollection(), "zoomMaxpect" ); new TDEAction ( i18n("Fullscreen &Mode"), CTRL+SHIFT+Key_F, this, SLOT(slotFullScreen()), actionCollection(), "fullscreen" ); Меню View показано на снимке экрана: Файл XML начинается с объявления типа документа. DTD для kpartgui можно найти в исходниках tdelibs в tdeui/kpartgui.dtd. Дальний элемент файл содержим имя экземпляра приложения как атрибут. он может содержать версию в форме "version=2". Это полезно когда вы выпускаете новую версию программы с изменённым меню. Если вы увеличите номер версии в файле ui.rc, KDE убедиться, что любая изменённая версия отброшена и используется новый файл. Следующая строка, <MenuBar>, содержит объявление панели меню. Вы можете вставлять любое количество <ToolBar> для создания панелей инструментов. Меню содержит подменю "view". Это имя является предопределённым и поэтому вы видите нормальные названия пунктов на снимке. Если вы будете добавлять свои подменю, вам нужно будет явно указать их заголовки. Например, в KView есть подменю с заголовком "Image": <Menu name="image" > <text>&amp;Image</text> ... </Menu> В KDE, такие заголовки автоматически извлекаются и помещаются в .po-файлы, которые также содержат перевод этих заголовков на другие языки (оригинальным языком программы должен быть английский, а, например, русские сообщения должны помещаться в такие файлы - на земле больше людей, знающих английский). Не забудьте также вставить символ "&" (акселератор), в XML это будет "&amp;". Давайте вернёмся к примеру. Меню View содержим несколько действий: zoom50, zoom100, zoom200, zoomMaxpect и fullscreen, объявленные в элементе <Action>. Отделитель на снимке соответствует элементу <Separator>. Некоторые пункты меню не имеют соответствующих им записей в XML-файле. Это стандартные действия. Они создаются классом KStdAction. При создании таких действий (к4ак в нашем C++ примере выше), они автоматически вставляются в определённой последовательности, и уже имеют значок и комбинацию клавиш. Эти действия описаны в tdeui/ui_standards.rc в исходниках tdelibs. Следующий отрывок описывает панель адреса. <ToolBar name="locationToolBar" fullWidth="true" newline="true" > <text>Location Toolbar</text> <Action name="clear_location" /> <Action name="location_label" /> <Action name="toolbar_url_combo" /> <Action name="go_url" /> </ToolBar> Здесь намного больше атрибутов, чем в меню: fullWidth: Говорит XMLGUI, что панель имеет максимально доступную ширину. Если это равно "false", панель занимает столько, сколько необходимо, а на оставшемся месте ряда располагаются другие панели инструментов. newline: Если равно "true", панель всегда находится в начале ряда. noEdit: Обычно, пользователь может изменять панели инструментов через НастройкиНастроить панели инструментов.... Этот атрибут позволяет отменить это поведение. iconText: Говорит XMLGUI отображать значок и текст действия. Обычно, текст отображается только в всплывающей подсказке. Возможные значения этого атрибута - "icononly" (только значки), "textonly" (только текст), "icontextright" (текст справа от значка) "icontextbottom" (текст снизу от значка). hidden: Если имеет значение "true", панель инструментов не видна по умолчанию. position: По умолчанию - "top", что означает, что панель располагается рядом с меню (т.е. вверху окна). Для программ с большим количеством инструментария, например графических, имеет смысл установить этот атрибут в "left", "right" или "bottom". Очевидно, XML может только содержать статическое описание пользовательского интерфейса, но часто нужно изменить меню во время выполнения. Например, меню Адрес в Konqueror содержит набор пунктов Open with Foo, отвечающих программам, способным открыть текущий файл (текущий MIME-тип). В XMLGUI функции динамической работы с меню реализованы с понятием списков действий (action lists). Он объявляется как один пункт в XML -файле, но состоит из несколькихдействий, подключаемых в меню во время выполнения. Приведённый выше пример реализован со следующим объявлением в XML-файле Konqueror: <Menu name="file"> <text>&amp;Location</text> ... <ActionList name="openwith"> ... </Menu> Функция KXMLGUIClient::plugActionList() используется для добавления действий, аKXMLGuiClient::unplugActionList() удаляет все подключённые действия. Обновление: void MainWindow::updateOpenWithActions() { unplugActionList("openwith"); openWithActions.clear(); for ( /* iterate over the relevant services */ ) { TDEAction *action = new TDEAction( ...); openWithActions.append(action); } plugActionList("openwith", openWithActions); } В отличие от статических действий, созданные здесь не имеют коллекцию действий в как родителя, и вы должны явно их удалять. Для этого можно установить openWithActions.setAutoDelete(true) в примере выше. Примеры, приведённые выше содержали только случаи, где создавались главное меню приложения и его панели инструментов. Их построение полностью скрыто от вас в функции createGUI(). В XML-файле можно также описывать и контекстные меню. Получить указатель на контекстное меню можно в клиентской factory: void MainWindow::popupRequested() { QWidget *w = factory()->container("context_popup", this); QPopupMenu *popup = static_cast<QPopupMenu *>(w); popup->exec(QCursor::pos()); } Метод KXMLGUIFactory::container()ищет контейнер в XML-файле. Его описание может быть таким: ... <Menu name="context_popup"> <Action name="file_add"/> <Action name="file_remove"/> </Menu> ... Существует несколько уровней такой помощи: Всплывающие подсказки. Особенно важны для панелей инструментов, где вместо текста обычно находятся значки. "Что это?" ("What's this?") обычно содержит более длинное описание элемента графического интерфейса. Её можно вызвать нажатием ShiftF1 или щелчком на знаке вопроса в заголовке окна. При этом курсор превратится в знак вопроса и пользователю нужно будет щёлкнуть на элементе, по которому он желает получить справку Недостаток такого подхода состоит в том, что пользователь не может сразу узнать, предоставляет ли элемент управления справку. И после нескольких попыток получения такой справки (когда при щелчке на элементе она не будет появляться), пользователь утратит интерес к этому занятию. Одним из преимуществ является то, что такие справки могут содержать форматирование. Пример справки "Что это?": На конец, каждая программа должны иметь руководство. Его обычно читают (если читают - прим. перев.) вKHelpCenter (вызываемый через менюСправка). Также, можно воспользоваться tdeioslave'ом konqueror'а help:/. Руководство обычно не должно повторять информации, содержащейся в справке другой формы (всплывающие подсказки и т.д.), в нём должен быть цельный обзор возможностей прогаммы и т.п. Руководства для программ KDE должны быть в формате DocBook. Он основан на XML и, следовательно, является свободно конвертируемым - начиная от банального HTML и заканчивая PDF. С точки зрения программиста, Qt предоставляет простой API для интерактивной справки. Чтобы присвоить подсказку элементу управления, воспользуйтесь классом QToolTip. QToolTip::add(w, i18n("This widget does something.")) Если меню и панели инструментов созданы с помощью модели действий, текст подсказки передаётся в первом аргументе конструктора TDEAction: action = new TDEAction(i18n("&Delete"), "editdelete", SHIFT+Key_Delete, actionCollection(), "del") Здесь также возможно присвоить показываемый в панели состояния текст: action->setStatusText(i18n("Deletes the marked file")) API для "Что это?" аналогично. Для диалогов: QWhatsThis::add(w, i18n("<qt>This demonstrates <b>Qt</b>'s" " rich text engine.<ul>" "<li>Foo</li>" "<li>Bar</li>" "</ul></qt>")) Для пунктов меню: action->setWhatsThis(i18n("Deletes the marked file")) Запуск KHelpCenter доступен из класса TDEApplication. kapp->invokeHelp() Отобразить первую страницу справки с её содержанием. Для вывода конкретной страницы руководства передайтеinvokeHelp() дополнительный аргумент - ссылку-"якорь" для перехода. Понятие служба (service) - основа модульной архитектуры KDE. Нет строгой технической реализации, связанной с этим понятием - службами могут быть модули, (plugins) в форма совместно используемых библиотек, или это могут быть программы, управляемые посредством протокола DCOP. Т.е. заявление, что программа является службой определённого типа, говорит о доступности соответствующего API. В C++ тип службы можно представить в виде абстрактного класса, а саму службу - в виде реализации. Преимущество такого отделения очевидно: программа, поддерживающая определённый тип службы может использовать любую службу этого типа. Она просто вызывает функции, имена которых закреплены в "абстрактном классе". За счёт такой унификации, службы можно подменять, изменять без каких-либо действий над программой, использующей их. Некоторые примеры: Движок HTML, используемый в Konqueror - встраиваемый компонент, реализующий типа служб KParts/ReadOnlyPart и Browser/View. В KDevelop большая часть функций разделены по реализациям типа KDevelop/Part. При запуске программы, загружаются все (доступные) службы, расширяющие её функциональность. В режиме просмотра "В виде значков", Konqueror отображает - если это включено - миниатюрные представления изображений, HTML-страниц, PDF и текстовых файлов. Если вы хотите сделать такой миниатюрный просмотр файлов, редактируемых вашим приложением, имеющих некоторый MIME-тип, вы можете реализовать службу ThumbCreator. Служба характеризуется не только типом, который она реализует, а ещё некоторыми свойствами (properties). Например, ThumbCreator не только реализует класс C++ с типом ThumbCreator, он также имеет список MIME-типов, за которые он отвечает. Аналогично, компоненты (parts) KDevelop передают при загрузке основной программе язык, который они поддерживают. Для этого в KDE есть развитый CORBA-like trader со сложным языком запросов. Новые типы служб добавляются установкой их описания в каталог TDEDIR/share/servicetypes. В automake framework, это можно сделать заготовкой Makefile.am: kde_servicetypesdir_DATA = tdeveloppart.desktop EXTRA_DIST = $(kde_servicetypesdir_DATA) Определение tdeveloppart.desktop для компонента KDevelop: [Desktop Entry] Type=ServiceType X-TDE-ServiceType=KDevelop/Part Name=KDevelop Part [PropertyDef::X-KDevelop-Scope] Type=QString [PropertyDef::X-KDevelop-ProgrammingLanguages] Type=QStringList [PropertyDef::X-KDevelop-Args] Type=QString Кроме обычных записей, здесь есть объявление наличия свойств. Каждое определение свойства отвечает группе [PropertyDef::name] в файле настроек. В этой группе, Type объявляет тип свойства. Возможные типы - всё, что может храниться в QVariant. Они хранятся в каталоге TDEDIR/share/services: kde_servicesdir_DATA = kdevdoxygen.desktop EXTRA_DIST = $(kde_servicesdir_DATA) Файл kdevdoxygen.desktop объявляет модуль KDevDoxygen с типом службы KDevelop/Part: [Desktop Entry] Type=Service Comment=Doxygen Name=KDevDoxygen ServiceTypes=KDevelop/Part X-TDE-Library=libkdevdoxygen X-KDevelop-ProgrammingLanguages=C,C++,Java X-KDevelop-Scope=Project Кроме обычных записей, здесь есть X-TDE-Library. В ней должно содержаться имя библиотеки libtool (без расширения .la). Она также устанавливает (префиксом init_) имя символьного идентификатора библиотеки, возвращающего object factory. В нашем случае, библиотека должна содержать следующую функцию: extern "C" { void *init_libkdevdoxygen() { return new DoxygenFactory; } }; Тип класса factory DoxygenFactory зависит от типа службы. В примере с модулем KDevelop, factory должен быть типа KDevFactory (наследник KLibFactory). Более общим примером является KParts::Factory, который производит объекты KParts::ReadOnlyPart или, в большинстве случаев, KLibFactory. In order to use a shared library service in an application, you need to obtain a KService object representing it. This is discussed in the section about MIME types (and in a section about the trader to be written :-) Получив объект KService, остаётся загрузить библиотеку и получить указатель на объект factory: KService *service = ... QString libName = QFile::encodeName(service->library()); KLibFactory *factory = KLibLoader::self()->factory(libName); if (!factory) { QString name = service->name(); QString errorMessage = KLibLoader::self()->lastErrorMessage(); KMessageBox::error(0, i18n("There was an error loading service %1.\n" "The diagnostics from libtool is:\n%2") .arg(name).arg(errorMessage); } Дальнейшие действия зависят от типа службы. Обычно объекты создаются методом KLibFactory::create(). Для KParts, вам нужно будет передать указатель на factory KParts::Factory и использовать его метод create(): if (factory->inherits("KParts::Factory")) { KParts::Factory *partFactory = static_cast<KParts::Factory*>(factory); QObject *obj = partFactory->createPart(parentWidget, widgetName, parent, name, "KParts::ReadOnlyPart"); ... } else { cout << "Service does not implement the right factory" << endl; } Служба DCOP обычно реализуется в виде программы, запускаемой по запросу. Затем она переходит в цикл событий и ожидает запросов на соединение DCOP. Программа может быть интерактивной, а может полностью выполняться как демон. Примером последнего служит tdeio_uiserver, реализующий взаимодействие с пользователем типа диалога выполнения TDEIO. Преимущество такой реализации заключается в том, что процесс выполнения нескольких загрузок может быть отображён в одном окне, даже если они запущены разными программами. Служба DCOP объявляется указанием не библиотеки, как в прошлом случае, а имени приложения. Также, службы DCOP не указывают ServiceType, т.к. они обычно запускаются явным указанием их имени. Дополнительные свойства занимают две строки: X-DCOP-ServiceType определяет метод запуска. Значение Unique говорит о невозможности запуска нескольких экземпляров этой службы. Это значит, что если вы попытаетесь запуститьэту службу (например, через TDEApplication::startServiceByName(), и KDE обнаружит, что такая служба уже зарегистрирована в, то будет использована уже запущенная копия службы. В этом случае она должна быть реализована как KUniqueApplication. Значение Multi для X-DCOP-ServiceType говорит, что одновременно можно запускать несколько экземпляров службы, так что каждая попытка запустить её приведёт к новому запуску. Значение None говорит о необходимости немедленного запуска службы. X-TDE-StartupNotify обычно должно быть false. Иначе при запуске программы будет отображаться соответствующее уведомление. Объявление tdeio_uiserver: [Desktop Entry] Type=Service Name=tdeio_uiserver Exec=tdeio_uiserver X-DCOP-ServiceType=Unique X-TDE-StartupNotify=false Служба DCOP запускается несколькими методами класса TDEApplication: DCOPClient *client = kapp->dcopClient(); client->attach(); if (!client->isApplicationRegistered("tdeio_uiserver")) { QString error; if (TDEApplication::startServiceByName("tdeio_uiserver", QStringList(), &error)) cout << "Starting kioserver failed with message " << error << endl; } ... QByteArray data, replyData; QCString replyType; QDataStream arg(data, IO_WriteOnly); arg << true; if (!client->call("tdeio_uiserver", "UIServer", "setListMode(bool)", data, replyType, replyData)) cout << "Call to tdeio_uiserver failed" << endl; ... Обратите внимание, что пример вызова DCOP использует явное приведение аргументов. Чаще вам придётся использовать заглушку (stub), созданную dcopidl2cpp, т.к. это намного проще и меньше подвержено ошибкам. В пиведенном примере, служба была запущена по имени ("by name"), т.е. первым аргументом TDEApplication::startServiceByName() является имя, указываемое в записи Name файла .desktop. Как альтернативу, можно использовать TDEApplication::startServiceByDesktopName(), которому передаётся имя файла .desktop, например "tdeio_uiserver.desktop". Все эти вызовы берут список URL вторым аргументом. Третий аргумент - указатель на QString. Если произойдёт ошибка, в это строку будет занесено (локализованное) сообщение об ошибке. MIME- используются для описания типа содержимого файлов или потоков данных. Изначально они были введены для отправки изображений или звуковых файлов по e-mail (MIME расшифровывается как "Multipurpose Internet Mail Extensions"). Позднее, эта система также была использована в веб-браузерах для определения как обрабатывать данные, посылаемые веб-сервером. Например, HTML-страница имеет тип MIME "text/html", файл Postscript - "application/postscript". В KDE, эта идея используется повсеместно: В режиме просмотра Konqueror "В виде значков", файлы представляются значками. Каждый MIME-тип имеет ассоциированный с ним значок. При нажатии по файлу в окне Konqueror, либо он просматривается во встроенном представлении, либо открывается в отдельной программе, ассоциированной с ним. При переносе файлов (drag-and-drop) из одного окна в другое, последнее может принимать только определённые типы данных. Данные, хранящиеся в буфере обмена, также имеют MIME-тип. Традиционно, программисты "иксов" принимают только изображения и текст, но а Qt не существует ограничений на тип данных. С приведённых выше примеров видно, что работа с MIME - достаточно сложная задача. Сначала, нужно установить соответствие между маской файла и типом MIME. KDE позволяет определить тип MIME не только по имени файла, а и по его содержимому, для случаев когда имя файла недоступно, или оно без расширения. Далее, необходимо установить связи между MIME-типами и программами или библиотеками, позволяющими обрабатывать их. Существует большое разнообразие API для установления типа MIME данных или файлов. В общем случае, вам придётся выбирать между скоростью и достоверностью. Вы можете определить тип файла только из его расширения. Например, файл с именем foo.jpg скорее всего имеет тип "image/jpeg". Если же файл не имеет расширения, его тип придётся определять по его содержимому. Естественно, это занимает больше времени, особенно для удалённых файлов. Такой метод основывается на файле TDEDIR/share/mimelnk/magic и следовательно тяжелее расширить. В большинстве случаев, для объявления типа MIME, достаточно установить файл .desktop, который будет обрабатываться (с приемлемой скоростью) библиотеками KDE. Давайте объявим тип "application/x-foo" для нашей новой программы foobar. Прежде всего, нужно написать файл foo.desktop и установить его в TDEDIR/share/mimelnk/application. Это можно сделать добавлением следующего текста в Makefile.am: mimedir = $(kde_mimedir)/application mime_DATA = foo.desktop EXTRA_DIST = $(mime_DATA) Файл foo.desktop должен выглядеть так: [Desktop Entry] Type=MimeType MimeType=application/x-foo Icon=fooicon Patterns=*.foo; DefaultApp=foobar Comment=Foo Data File Comment[ru]=Данные для Foo Если это .desktop файл одного из пакетов KDE, запись "Comment[ru]" в нём не нужна, т.к. перевод комментариев производится другим образом (через .po-файлы, находящиеся в модуле CVS tde-i18n/ru/<пакет>/desktop_<имя>.po). .desktop указывает значок fooicon.png, представляющий файл программы, например в Konqueror. В библиотеках KDE, такое объявление типа устанавливается в экземпляре класса KMimeType: KMimeType::Ptr type = KMimeType::mimeType("application/x-foo"); cout << "Type: " << type->name() < endl; cout << "Icon: " << type->icon() < endl; cout << "Comment: " << type->icon() < endl; QStringList patterns = type->patterns(); QStringList::ConstIterator it; for (it = patterns.begin(); it != patterns.end(); ++it) cout << "Pattern: " << (*it) << endl; Самый быстрый метод определения типа файла - KMimeType::findByURL(). Как видно из названия, он определяется по передонному URL. Для некоторых протоколов (типа http, man, info), этот механизм не используется. Например, сценарии CGI на web-серверах написанные на Perl часто имеют расширение .pl, т.е. тип "text/x-perl". Тем не менее, сценарий передаёт клиенту обычный HTML. В таких случаях, KMimeType::findByURL() возвращает MIME -тип "application/octet-stream" (тоже самое - KMimeType::defaultMimeType()), что говорит о неудачной попытке определения типа. KMimeType::Ptr type = KMimeType::findByURL("/home/bernd/foobar.jpg"); if (type->name() == KMimeType::defaultMimeType()) cout << "Could not find out type" << endl; else cout << "Type: " << type->name() << endl; (у этого метода на самом деле больше аргументов, но они недокументированы) Определение типа файла по его содержимому реализуется классом KMimeMagic: KMimeMagicResult *result = KMimeMagic::self()->findFileType("/home/bernd/foobar.jpg"); if (!result || !result->isValid()) cout << "Could not find out type" << endl; else cout << "Type: " << result->mimeType() << endl; Также, можно определять тип области памяти. Это, например, используется в Kate для определения режима подсветки: QByteArray array; ... KMimeMagicResult *result = KMimeMagic::self()->findBufferType(array); if (!result || !result->isValid()) cout << "Could not find out type" << endl; else cout << "Type: " << result->mimeType() << endl; KMimeMagic поддерживает только локальные файлы. Для удалённых файлов: KURL url("http://developer.kde.org/favicon.ico"); QString type = TDEIO::NetAccess::mimetype(url); if (type == KMimeType::defaultMimeType()) cout << "Could not find out type" << endl; else cout << "Type: " << type << endl; Это приводит к загрузке части файла через TDEIO и его проверке. Помните, что это занимает некоторое время и блокирует программу. Используйте это только если KMimeType::findByURL() вернуло "application/octet-stream". Чтобы избежать блокирования программы, можно явно запустить TDEIO-задание и соединить слот с одним из его сигналов: void FooClass::findType() { KURL url("http://developer.kde.org/favicon.ico"); TDEIO::MimetypeJob *job = TDEIO::mimetype(url); connect( job, SIGNAL(result(TDEIO::Job*)), this, SLOT(mimeResult(TDEIO::Job*)) ); } void FooClass::mimeResult(TDEIO::Job *job) { if (job->error()) job->showErrorDialog(); else cout << "MIME type: " << ((TDEIO::MimetypeJob *)job)->mimetype() << endl; } При установке приложения, или компоненты наподобие KPart , также устанавливается и файл .desktop, содержащий список MIME-типов, которые оно может обрабатывать. Получить список программ и служб, обрабатывающих данный MIME-тип, можно через класс KServiceTypeProfile: KService::OfferList offers = KServiceTypeProfile::offers("text/html", "Application"); KService::OfferList::ConstIterator it; for (it = offers.begin(); it != offers.end(); ++it) { KService::Ptr service = (*it); cout << "Name: " << service->name() << endl; } KServiceTypeProfile::offers() возвращает список в определённом пользователем порядке. Изменить предпочитаемый порядок можно командой "keditfiletype text/html". В приведённом выше примере запрашивался список приложений, поддерживающих text/html. Это будут - среди прочих - редакторы HTML типа Quanta Plus. Вы можете изменить второй агумент "Application" на "KParts::ReadOnlyPart". В этом случае вы получите список встраиваемых компонентов, поддерживающих HTML, например TDEHTML. Чтобы получить приложение по умолчанию, воспользуйтесь этим кодом: KService::Ptr offer = KServiceTypeProfile::preferredService("text/html", "Application"); if (offer) cout << "Name: " << service->name() << endl; else cout << "No appropriate service found" << endl; Для более сложных запросов существует CORBA-like trader. Для запуска службы с URL, воспользуйтесь KRun: KURL::List urlList; urlList << "http://www.ietf.org/rfc/rfc1341.txt?number=1341"; urlList << "http://www.ietf.org/rfc/rfc2046.txt?number=2046"; KRun::run(offer.service(), urlList); В этом разделе мы приведём список API, относящихся к предыдущему обсуждению. Получить значок URL. KURL url("ftp://ftp.kde.org/pub/incoming/wibble.c"); QString icon = KMimeType::iconForURL(url); Выполненые URL. KURL url("http://dot.kde.org"); new KRun(url); Во время world wide web, программы должны иметь доступ к ресурсам сети - загружать файлы, передавать какие-либо данные. возможность получать доступ к файлам вне зависимости от их расположения называется сетевая прозрачность (network transparency). В прошлом было несколько попыток реализации этого. Старая файловая система NFS - одна из таких попыток на уровне POSIX API. Она приемлемо работала в локальных, тесно связанных сетях, но оказалась немасштабируемой до современных технологий. Здесь важна асинхронность. Пока вы ждёте загрузки страницы в вашем веб-браузере, пользовательский интерфейс не должен блокироваться. Также, прорисовка страниц не должна начинаться только после полной загрузки, а выполняться по мере поступления данных. В библиотеках KDE, сетевая прозрачность реализована в TDEIO API. Основная идея этой архитектуры - задание (job) ввода/вывода (IO - input/output). Задание может копировать, удалять, перемещать файлы и т.п. После запуска, задание работает в фоновом режиме и не блокирует приложение. Сообщение между заданием и приложением - например передача данных о степени выполнения - выполняется интегрировано с циклом событий Qt. Фоновые операции выполняются с помощью ioslaves. Они запускаются как отдельный процесс соединяются через доменные сокеты UNIX. Таким образом не требуется, многопотоковость и сбой slave'а не приведёт к сбою приложений, использующих его. Расположение файла определяется URL. В его начале пишется tdeioslave, обрабатывающий протокол, по которому доступен файл. Например, это может быть file, http, tar и т.д. Напримерфайл из архива tar, находящегося на http-сервере может иметь URL http://www-com.physik.hu-berlin.de/~bernd/article.tgz#tar:/paper.tex В большинстве случаев, задания создаются вызовом функций в пространстве имён TDEIO. Эти функции берут один или два URL как аргумент, и другое. После окончания задания, посылается сигнал result(TDEIO::Job*) и задание удаляется: void FooClass::makeDirectory() { SimpleJob *job = TDEIO::mkdir(KURL("file:/home/bernd/kiodir")); connect( job, SIGNAL(result(TDEIO::Job*)), this, SLOT(mkdirResult(TDEIO::Job*)) ); } void FooClass::mkdirResult(TDEIO::Job *job) { if (job->error()) job->showErrorDialog(); else cout << "mkdir went fine" << endl; } В зависимости от типа задания, можно соединить также два других сигнала. Краткий обзор доступных функций: TDEIO::mkdir(const KURL &url, int permission) Создать каталог, возможно указание прав доступа. TDEIO::rmdir(const KURL &url) Удалить каталог TDEIO::chmod(const KURL &url, int permissions) Изменить права доступа файла. TDEIO::rename(const KURL &src, const KURL &dest, bool overwrite) Переименовать файл. TDEIO::symlink(const QString &target, const KURL &dest, bool overwrite, bool showProgressInfo) Создать символическую ссылку. TDEIO::stat(const KURL &url, bool showProgressInfo) Информация о файле - размер, время изменения, права доступа. Информацию можно получить из TDEIO::StatJob::statResult() после завершения задания. TDEIO::get(const KURL &url, bool reload, bool showProgressInfo) Передать данные из URL. TDEIO::put(const KURL &url, int permissions, bool overwrite, bool resume, bool showProgressInfo) Передать данные в URL. TDEIO::http_post(const KURL &url, const QByteArray &data, bool showProgressInfo) Переслать данные. Специально для HTTP. TDEIO::mimetype(const KURL &url, bool showProgressInfo) Определить тип MIME. Получить его можно из TDEIO::MimetypeJob::mimetype() после окончания задания. TDEIO::file_copy(const KURL &src, const KURL &dest, int permissions, bool overwrite, bool resume, bool showProgressInfo) Скопировать один файл TDEIO::file_move(const KURL &src, const KURL &dest, int permissions, bool overwrite, bool resume, bool showProgressInfo) Переименовать (переместить) файл TDEIO::file_delete(const KURL &url, bool showProgressInfo) Удалить файл. TDEIO::listDir(const KURL &url, bool showProgressInfo) Содержание каталога. При каждом его изменении посылается сигнал TDEIO::ListJob::entries(). TDEIO::listRecursive(const KURL &url, bool showProgressInfo) Аналогично listDir(), но рекурсивно. TDEIO::copy(const KURL &src, const KURL &dest, bool showProgressInfo) Скопировать файл или каталог (рекурсивно). TDEIO::move(const KURL &src, const KURL &dest, bool showProgressInfo) Переименовать файл или каталог. TDEIO::del(const KURL &src, bool shred, bool showProgressInfo) Удалить файл или каталог. TDEIO::stat() и TDEIO::listDir() возвращают свой результат в типе UDSEntry, UDSEntryList соотв. Последний определён как QValueList<UDSEntry>. UDS расшифровывается как "Universal directory service". Принцип заключается в том, запись о каталоге содержит только ту информацию, доступную ioslave. Например, http slave не предоставляет информацию о правах доступа и владельцах файла. UDSEntry является списком UDSAtom'ов. Каждый атом содержит определённую часть информации. Он состоит из типа, хранящегося в m_uds и либо целого в m_long, либо строки в m_str, в зависимости от типа. Определены следующие типы: UDS_SIZE (integer) -Размер файла. UDS_USER (string) - Владелец файла. UDS_GROUP (string) - Группа файла. UDS_NAME (string) - Имя файла. UDS_ACCESS (integer) - Права доступа как в функции libc stat() в поле st_mode. UDS_FILE_TYPE (integer) - Тип файла, например, как записывается функцией stat() в поле st_mode. Вы можете использовать обычные макросы libc наподобие S_ISDIR для тестирования этого значения. Помните, что данные, предоставляемые ioslave'ами соответствуютstat(), не lstat(), т.е., например, в случае символической ссылки будет возвращаться тип файла, на который ссылка указывает. UDS_LINK_DEST (string) - В случае символической ссылки, имя файла, на который она ссылается. UDS_MODIFICATION_TIME (integer) - Время (тип time_t) последнего изменения файла, как сохраняется функцией stat() в поле st_mtime. UDS_ACCESS_TIME (integer) - Время последнего доступа, как записывается функцией stat() в поле st_atime. UDS_CREATION_TIME (integer) - Время создания файла, как, например, записывается функцией stat() в поле st_ctime. UDS_URL (string) - URL файла. UDS_MIME_TYPE (string) - MIME-тип файла UDS_GUESSED_MIME_TYPE (string) - MIME-тип файла, по предположению slave. В отличие от предыдущего, не всегда точный (т.к. в некоторых случаях точное определение типа требует больших затрат ресурсов). Например, класс KRun явно проверяет MIME-тип только если он не располагает точной информацией. Не смотря на всю гибкость хранения информации в UDSEntry, для программиста это всё же составляет некоторые трудности (задержки во времени реализации). Например, чтобы определить MIME-тип файла, вам нужно итерировать по всем атомам и проверить является ли m_uds UDS_MIME_TYPE. к счастью, существует более простой API: класс KFileItem. Часто, асинхронное API TDEIO слишком сложное для использования, и асинхронность не всегда важна. Например, в программе, которая может работать только с одним документом в одно время, можно сделать немногое в время загрузки файла. Для таких простых случаев, вы можете воспользоваться функциями класса TDEIO::NetAccess. Например, чтобы скопировать файл: KURL source, target; source = ...; target = ... TDEIO::NetAccess::copy(source, target); Функция возвратится после выполнения задания. Будет показана информация о прогрессе, а программа всё равно будет получать события прорисовки. Некоторый интерес также представляет комбинация функций removeTempFile() и download(). Последняя загружает файл по заданному URL и сохраняет его во временный файл с уникальным именем. Имя файла сохраняется во второй аргумент. Если URL ссылается на локальный файл, второй аргумент содержит локальное имя файла. ФункцияremoveTempFile()удаляет файл если он получился в результате загрузки. Вот заготовка кода для загрузки файла не смотря на его положение: KURL url; url = ...; QString tempFile; if (TDEIO::NetAccess::download(url, tempFile) { // load the file with the name tempFile // загрузить файл с именем tempFile TDEIO::NetAccess::removeTempFile(tempFile); } Интерфейс к заданиям TDEIO достаточно абстрактный. При создании задания, вы можете добавить метаданные к нему. Каждый элемент метаданных состоит из пары ключ-значение. Например, чтобы указать HTTP-slave не использовать кэш при загрузке страницы: void FooClass::reloadPage() { KURL url("http://www.kdevelop.org/index.html"); TDEIO::TransferJob *job = TDEIO::get(url, true, false); job->addMetaData("cache", "reload"); ... } Такой же механизм используется и в обратном направлении. Метод Job::queryMetaData() позволяет запрашивать данные. Например HTTP-slave может предоставить ключ"modified", содержащий (в виде строки) дату последнего изменения страницы. Пример: void FooClass::printModifiedDate() { KURL url("http://developer.kde.org/documentation/kde2arch/index.html"); TDEIO::TransferJob *job = TDEIO::get(url, true, false); connect( job, SIGNAL(result(TDEIO::Job*)), this, SLOT(transferResult(TDEIO::Job*)) ); } void FooClass::transferResult(TDEIO::Job *job) { QString mimetype; if (job->error()) job->showErrorDialog(); else { TDEIO::TransferJob *transferJob = (TDEIO::TransferJob*) job; QString modified = transferJob->queryMetaData("modified"); cout << "Last modified: " << modified << endl; } Используя TDEIO API, вам не нужно разбираться в подробностях запуска IO slave'ов и связи с ними. Чаще всего нужно просто запустить задание и обрабатывать посылаемые им сигналы. На самом деле, за занавесками всё намного сложнее. При создании задания оно помещается в очередь, когда приложение возвращается в главный цикл событий, TDEIO создаёт процессы slave для заданий в очереди. После завершения работы, задание не уничтожается, а находится в "подвешенном состоянии" около 3 минут - на случай если поступит запрос на новое задание с теми же протоколом и узлом. Если slave'ы запускаются по мере поступления запросов (т.е. параллельно), эта схема называется прямой. Это не всегда приемлемо т.к. требует дополнительных затрат памяти. Чтобы избежать этого, можно воспользоваться расписанием (schedule) заданий. При этом одновременно может выполняться только ограниченное число заданий (сейчас это 3). Следующие задания будут ставиться в очередь: KURL url("http://developer.kde.org/documentation/kde2arch/index.html"); TDEIO::TransferJob *job = TDEIO::get(url, true, false); TDEIO::Scheduler::scheduleJob(job); Третий вариант - ориентация на соединения. Например, для IMAP slave, не имеет смысла запускать несколько процессов для одного сервера. Поэтому нельзя запускать несколько заданий к одному серверу. Это можно сделать с помощью TDEIO::Scheduler: KURL baseUrl("imap://bernd@albert.physik.hu-berlin.de"); TDEIO::Slave *slave = TDEIO::Scheduler::getConnectedSlave(baseUrl); TDEIO::TransferJob *job1 = TDEIO::get(KURL(baseUrl, "/INBOX;UID=79374")); TDEIO::Scheduler::assignJobToSlave(slave, job1); TDEIO::TransferJob *job2 = TDEIO::get(KURL(baseUrl, "/INBOX;UID=86793")); TDEIO::Scheduler::assignJobToSlave(slave, job2); ... TDEIO::Scheduler::disconnectSlave(slave); После запуска такого задания, гарантируется, что они выполнятся полностью. Далее мы обсудим процесс создания ioslave. По аналогии со службами, установка заключается в написании небольшого конфигурационного файла. Следующая заготовка Makefile.am устанавливает протокол ftp: protocoldir = $(kde_servicesdir) protocol_DATA = ftp.protocol EXTRA_DIST = $(mime_DATA) Содержание ftp.protocol: [Protocol] exec=tdeio_ftp protocol=ftp input=none output=filesystem listing=Name,Type,Size,Date,Access,Owner,Group,Link, reading=true writing=true makedir=true deleting=true Icon=ftp Запись "protocol" определяет протоколы, за которые отвечает slave. "exec" - имя библиотеки, реализующей slave. Призпуске задания, "tdeinit" загружает указанную билиотеку. Строки "input" "output" не используются на данный момент. Оставшиеся строки в файле .protocol определяют возможности slave'а. Последние обычно намного проще, чем TDEIO API. Например, чтобы получить рекурсивный листинг каталога, запускается задание для сканирования верхнего каталога, затем для каждого подкаталога запускается ещё одно, отдельное, задание. При этом существует ограничение на количество одновременно запущенных заданий. Аналогично, чтобы скопировать файл с протоколом, не поддерживающим это напрямую, (напримерftp:), TDEIO читает файл и передаёт его по назначению. Т.к. slave' загружаются в виде совместно используемых библиотек, но действуют отдельно, их структура исходных файлов немного отличается от структуры обычной библиотеки. Функция, вызываемая для запуска называется kdemain(). В ней обычно выполняются некоторые инициализации, а затем она входит в цикл событий: extern "C" { int kdemain(int argc, char **argv); } int kdemain(int argc, char **argv) { TDELocale::setMainCatalogue("tdelibs"); TDEInstance instance("tdeio_ftp"); (void) TDEGlobal::locale(); if (argc != 4) { fprintf(stderr, "Usage: tdeio_ftp protocol " "domain-socket1 domain-socket2\n"); exit(-1); } FtpSlave slave(argv[2], argv[3]); slave.dispatchLoop(); return 0; } Slave'ы реализованы в виде подклассовTDEIO::SlaveBase. Следовательно, действия, перечисленные в.protocol отвечают определённым виртуальным функциям TDEIO::SlaveBase, которые должны реализовываться в slave'е, а именно: reading - читает данные из URL void get(const KURL &url) writing - записывает данные в URL и создаёт файл если его не существует. void put(const KURL &url, int permissions, bool overwrite, bool resume) moving - переименовывает файл. void rename(const KURL &src, const KURL &dest, bool overwrite) deleting - удаляет файл или каталог. void del(const KURL &url, bool isFile) listing - содержание каталога. void listDir(const KURL &url) makedir - создаёт каталог. void mkdir(const KURL &url, int permissions) Также, существуют виртуальные функции, которые не нужно заносить в файл .protocol - TDEIO автоматически может определить поддерживаются они или нет. Сведения о файле, аналогично stat() из C. void stat(const KURL &url) Изменяет права доступа файла. void chmod(const KURL &url, int permissions) Определяет MIME-тип файла. void mimetype(const KURL &url) Копирует файл. copy(const KURL &url, const KURL &dest, int permissions, bool overwrite) Создаёт символическую ссылку. void symlink(const QString &target, const KURL &dest, bool overwrite) Все реализации должны завершаться одним из двух вызовов - finished() или error() (с кодом ошибки в первом аргументе и строкой объяснения в втором). Коды ошибок перечислены в enum TDEIO::Error. Второй аргумент - обычно URL. Это используется например вTDEIO::Job::showErrorDialog(). Для slave'ов, реализующих сетевые протоколы, нужно реализовать функцию SlaveBase::setHost(). Она вызывается для передачи имени узла, порта, имени пользователя и пароля. Вообще, метаданные, предоставляемые приложением, можно получить с помощью SlaveBase::metaData(). Наличие их можно определить функцией SlaveBase::hasMetaData(). get() посылает блоки данных. Это сделано с помощью функции data(), аргументом которой является QByteArray. Если вы посылаете большой файл, вызовите data() с меньшими блоками. Функция finished() вызывается по завершению передачи. listDir() выдаёт сведения о содержимом каталога. Для этого вызовите listEntries() с аргументом типаTDEIO::UDSEntryList. Подобноdata(), вы можете сделать это несколько раз. В конце вызовите listEntry() с вторым аргументом равным true. Вы также можете вызватьtotalSize() для передачи количества элементов каталога. stat() выдаёт сведения о файле, например его размер, MIME-тип и т.д. Они упаковываются в один элемент типа TDEIO::UDSEntry, обсуждаемый ранее. Используйте statEntry() для передачи такого элемента приложению. mimetype() вызывает mimeType() с аргументом типа string. get() и copy() могут предоставлять информацию о процессе выполнения с помощью методов totalSize(), processedSize(), speed(). Общий и выполненный размеры передаются в байтах, скорость - в байтах в секунду. Вы можете посылать произвольные пары ключ-значение с помощью setMetaData(). Иногда slave должен взаимодействовать с пользователем. Это может быть в виде информационных сообщений, диалогов авторизации и подтверждения замены файла. infoMessage() - информационное сообщение, такое как "Retrieving data from <host>" http slave'а, обычно отображаемое в панели состояния. На стороне приложения, этот метод отвечает сигналу TDEIO::Job::infoMessage(). warning() - предупреждение в окне сообщений с KMessageBox::information(). messageBox() - расширенная версия предыдущего. Здесь можно устанавливать свои кнопки, текст заголовка. Для подробностей обратитесь к определению enum SlaveBase::MessageBoxType. openPassDlg() - Открыть диалог для ввода имени пользователя и пароля. &underFDL; &underGPL;