<listitem><para>tdecore - основа, каркас для любого приложения KDE. Она обеспечивает доступ к системе конфигурации, обработке командной строки, загрузке и управлению значками, межпроцессное взаимодействие и т.д. </para></listitem>
<listitem><para>Библиотека <literal>tdeui</literal> содержит большое количество элементов управления и стандартных диалогов, которых нет в Qt или которые имеют расширенную функциональность по сравнению с их аналогами. </para></listitem>
<listitem><para>Библиотека <literal>tdeio</literal> содержит удобства для асинхронного, сетевого файлового ввода/вывода и доступ к обработчику mimetype. Она также содержит диалог открытия файлов и его вспомогательные классы. </para></listitem>
<listitem><para>Библиотека <literal>tdehtml</literal> содержит компонент TDEHTML, виджет для отображения HTML, DOM API, включая интерфейсы к Java и JavaScript. </para></listitem>
<para>Низкоуровневая графическая модель Qt основывается на возможностях, предоставляемых X11 или другими графическими моделями, в которые портирована Qt. Но в ней также есть расширенные функции, такие как произвольные преобразования для текста и растра. </para>
<para>Центральный графический класс для двухмерного рисования с Qt называется <ulink url="kdeapi:qt/QPainter">QPainter</ulink>. Он может рисовать на <ulink url="kdeapi:qt/QPaintDevice">QPaintDevice</ulink>. Реализовано 3 устройства для рисования: <ulink url="kdeapi:qt/TQWidget">TQWidget</ulink>, представляющий элемент управления на экране, <ulink url="kdeapi:qt/QPrinter">QPrinter</ulink>, представляющий виджет в виде вывода Postscript, и <ulink url="kdeapi:qt/QPicture">QPicture</ulink>, позволяющий записывать и воспроизводить команды рисования (с диска) в формате SVG. </para>
<para>При рисовании на принтере не забудьте вызывать QPrinter::newPage() для сигнализации о необходимости смены страницы. Также, при печати, вы можете использовать <ulink url="kdeapi:qt/QPaintDeviceMetrics">метрику устройства</ulink> для подсчёта координат. </para>
<para>По умолчанию, при использовании QPainter, прорисовка происходит в системе координат устройства. Это значит, что если вы рисуете линию по оси абсцисс с длинов в 10 единиц, её длина на экране будет составлять 10 пикселей. Однако, QPainter может применить некоторое преобразование перед прорисовкой фигур и кривых. Оно переносит координаты x и y линейно в x' и y' соответственно. </para>
<para>Матрицу 3x3 в этом равенстве можно получить с помощью QPainter::setWorldMatrix(), она имеет тип <ulink url="kdeapi:qt/QWMatrix">QWMatrix</ulink>. Это должна быть тождественная матрица, т.е. m11 и m22 равны единице, остальные параметры - нулю. Три типа преобразований: </para>
<para>Перемещает все точки объекта на определённую величину в определённом направлении. Трансляционная матрица может быть получена вызовом метода m.translate(dx, dy). Это отвечает матрице </para>
<para>Растянуть или сжать координаты объекта, делая его больше или меньше и сохраняя пропорции. Масштабирование можно применить к матрице методом m.scale(sx, sy). </para>
<para>Преобразования можно совмещать с умножением элементарных матриц. Помните, что операции с матрицами не являются коммутативными, поэтому обращайте внимание порядок множителей. </para>
<para>Прорисовка линий, кривых и контуров многоугольниковможет быть изменена установкой специального пера через QPainter::setPen(). Аргумент этого метода - объект типа <ulink url="kdeapi:qt/QPen">QPen</ulink>. Он содержит такие параметры как стиль, цвет, тип соединения и концов. </para>
<para>Стиль соединение - член enum <ulink url="kdeapi:qt/Qt#PenJoinStyle-enum">TQt::PenJoinStyle</ulink>. Он указывает метод соединения нескольких линий. Он может принимать следующие значения: </para>
<para>Стиль концов является членом enum <ulink url="kdeapi:qt/Qt#PenCapStyle-enum">TQt::PenCapStyle</ulink> и определяет как рисовать концы линий. Возможные значения: </para>
<para>Тип заливки многоугольников, окружностей и прямоугольников можно изменить установкой специальной кисти через QPainter::setBrush(). Она берёт аргумент типа <ulink url="kdeapi:qt/QBrush">QBrush</ulink>. </para>
<para>В Qt цвета представлены классом <ulink url="kdeapi:qt/TQColor">TQColor</ulink>. Qt не поддерживает расширенную функциональность типа цветовых профилей ICC и сглаживание цветов. Цвета указываются по RGB. </para>
<para>Также возможно использовать оттенки, насыщенность и величина (HSV). Эти параметры напрямую используются в диалоге выбора цвета GIMP. Оттенок отвечает уголку на полосе цвета, насыщенность отвечает расстоянию до центра окружности. Величину можно выбрать отдельным ползунком. </para>
<para>Обычно, точки, которые вы рисуете заменяют те, которые были до них на том же месте. Например, если вы нарисуете квадрат красным цветом, а потом повторите действие, лишь изменив цвет на синий, вы увидите синий квадрат. Пока что Qt не поддерживает прозрачность. Тем не менее, существует простой путь совместить фон и передний план с булевыми операторами. Метод QPainter::setRasterOp() устанавливает используемый оператор, из enum <ulink url="kdeapi:qt/Qt#RasterOp-enum">RasterOp</ulink>. </para>
<para>По умолчанию установлен CopyROP, который игнорирует фон. Однако вы можете выбрать XorROP. Если вы нарисуете чёрную линию с этим оператором на цветном изображении, цвет покрываемой линией области будет обращён. </para>
<para>Далее приводится список графических элементов, поддерживаемых QPainter. Большинство из них имеют несколько перегруженных версий, поэтому принимают различный набор аргументов. Например, методы, работающие с прямоугольниками обычно принимаю либо <ulink url="kdeapi:qt/QRect">QRect</ulink>, либо 4 числа. </para>
<para>Qt предоставляет два различных класса для работы с изображениями. </para>
<para><ulink url="kdeapi:qt/QPixmap">QPixmap</ulink> отвечает растровым объектам X11. Растры - это объекты стороны сервера и могут - на новых графических картах - даже храниться в их памяти. Поэтому работа с ними происходит <emphasis>очень</emphasis> быстро. Растры также выступают эквивалентами элементов управления - класс QPixmap является подклассом QPaintDevice, так что вы можете рисовать на нём с QPainter. Элементарные операции рисования обычно оптимизируются современными графическими картами. Поэтому, можно использовать растры для двойной буферизации ("double buffering"). Это означает рисовать не прямо на элементе управления, а на временном растре, а потом вызывать функцию <ulink url="kdeapi:qt/QPaintDevice#bitBlt-1">bitBlt</ulink> чтобы передать его виджету. Для сложных перерисовок, это помогает предотвратить мигание. </para>
<para>Объекты <ulink url="kdeapi:qt/TQImage">TQImage</ulink> располагаются на стороне клиента. Основное ударение поставлено на прямой доступ к точкам изображения. Это упрощает операции манипуляции с изображениями, загрузку и сохранение на диск (метод QPixmapload() берёт TQImage как промежуточный). С другой стороны, рисование на элементе управления - дорогая операция, т.к. включает в себя передачу X-серверу. В зависимости от глубины цвета, преобразование из TQImage в QPixmap может требовать dithering. </para>
<para>Текст можно нарисовать одним из вариантов перегруженной функции QPainter::drawText(). Шрифт можно установить функцией QPainter::setFont(). Есть также параметр, представляющий их себя комбинацию флагов ORed из enums <ulink url="kdeapi:qt/Qt#AlignmentFlags-enum">TQt::AlignmentFlags</ulink> и <ulink url="kdeapi:qt/Qt#TextFlags-enum">TQt::TextFlags</ulink> </para>
<para>Начиная с версии 3.0, Qt также поддерживает языки с письмом справа налево. </para>
<para>Чтобы отобразить текст с оформлением, воспользуйтесь классом <ulink url="kdeapi:qt/QSimpleRichText">QSimpleRichText</ulink>. При этом в текст нужно включать базовую HTML-разметку (включающую, тем не менее даже таблицы). Стиль текста можно изменить с помощью <ulink url="kdeapi/qt/QStyleSheet">QStyleSheet</ulink>. Для прорисовки такого объекта используйте метод QSimpleRichText::draw(). </para>
<para>QPainter обеспечивает мощную низкоуровневую модель для рисования на элементах управления и растрах. Однако, рисование более сложных объектов сего помощью может оказаться непосильной задачей. Каждый раз, когда элемент управления получает событие рисования, ему нужно проанализировать QPaintEvent::region() или QPaintEvent::rect(). Затем ему нужно установить QPainter и нарисовать все объекты, которые перекрывают эту область. Например, представьте себе программу векторной графики, позволяющую перетаскивать объекты типа многоугольников, окружностей, и их групп. Каждый раз при наименьшем перемещении объектов, обработчик событий мыши создаёт событие перерисовки для всей области, занимаемой объектами в старой и новой позициях. Вычисление необходимых перерисовок и их выполнение оптимальным способом может составлять трудность, и может конфликтовать с объектно-ориентированной структурой кода программы. </para>
<para>Как выход, Qt предлагает класс <ulink url="kdeapi:qt/QCanvas">QCanvas</ulink>, в котором можно располагать графические объекты, такие как многоугольники, текст, растры. Дополнительные элементы можно создать созданием подкласса <ulink url="kdeapi:qt/QCanvasItem">QCanvasItem</ulink> или одного из его специализированных подклассов. Канва (от англ. холст) может отобаржаться одним или более элементами управления класса <ulink url="kdeapi:qt/QCanvas">QCanvasView</ulink>, которые вы должны пол=делить на подклассы для взаимодействия с пользователем. Qt заботится о всех перерисовках в представлении самостоятельно. Т.к. при этом используется двойная буферизация, это позволяет избавиться от мигания. </para>
<para>Элементы канвы могут перекрывать один другого В этом случае видимость объектов определяется т.н. z-порядком, который можно изменять методом QCanvasItem::setZ(). Их можно вообще скрывать. Также, вы можете выбрать фон. Для ассоциации событий мыши в канве есть метод QCanvas::collisions(), возвращающий список элементов, перекрывающих данную точку: </para>
<para>Здесь сетка нарисована на фоне. Кроме них там есть элементы QCanvasText и фиолетовый QCanvasPolygon. Бабочка представлена растром QCanvasPixmap. Он имеет прозрачные области. </para>
<para>Руководство по использованию QCanvas для написания sprite-based игр можно найти <ulink url="http://zez.org/article/articleview/2/1/">тут</ulink>. </para>
<para>Стандартом де-факто для прорисовки трёхмерной графики на сегодня является <ulink url="http://www.opengl.org">OpenGL</ulink>. Реализации этой спецификации поставляются с Microsoft Windows, Mac OS X и XFree86, и часто поддерживают аппаратное ускорение. OpenGL сам по себе только занимается прорисовкой на указанной области фреймбуфера через <emphasis>GL context</emphasis> и не взаимодействует с инструментарием среды. </para>
<para>Qt предоставляет элемент управления <ulink url="kdeapi:qt/QGLWidget">QGLWidget</ulink>, инкапсулирующий окно с ассоциированным контекстом GL. Используйте его, создавая его подкласс и переопределяя некоторые из его методов. </para>
<listitem><para>Вместо повторной реализация paintEvent() и использования QPainter для прорисовки содержимого элемента управления, замещайте paintGL() и используйте команды GL для прорисовки сцены. QLWidget позаботится о создании его контекста GL перед вызовом paintGL() и очистит его. </para></listitem>
<listitem><para>Виртуальный метод initializeGL() вызывается перед первым вызовом resizeGL() или paintGL(). Его можно использовать для конструкции списков отображения для объектов и других инициализаций. </para></listitem>
<listitem><para>Вместо повторной реализации resizeEvent(), заместите resizeGL(). Это может быть использовано для установки соответствующей области просмотра. </para></listitem>
<listitem><para>Вместо вызова update() по изменении состояния сцены - например при анимировании по таймеру - вызывайте updateGL(). Это приведёт к перерисовке. </para></listitem>
<para>В общем, QGLWidget ведёт себя также, как и любой другой элемент управления, например вы можете обрабатывать события мыши как обычно, изменять размер и совмещать егос другими объектами. </para>
<para>Qt поставляется с несколькими примерами использования QGLWidget в <literal>demo</literal>. Набор руководств на эту тематику можно найти <ulink url="http://www.libsdl.org/opengl/intro.html">здесь</ulink>, и больше информации и справочник OpenGL доступно на <ulink url="http://www.opengl.org">сайте OpenGL</ulink>. </para>
<para>OpenGL является относительно низкоуровневым интерфейсом для рисования трёхмерной графики. Как QCanvas предоставляет интерфейс более высокого уровня для двухмерной графики, так Open Inventor является трёхмерным аналогом канвы. Изначально эта технология была реализована SGI, но на данный момент есть также версия с открытым исходным кодом <ulink url="http://www.coin3d.org">Coin</ulink>, сопровождающаяся связью с SoQt. </para>
<para>Основна Open Inventor - <emphasis>сцена</emphasis>. Сцену можно загрузить с диска и сохранить в специальном формате, тесно связанным с <ulink url="http://www.vrml.org">VRML</ulink>. Сцена состоит из набора объектов, называющихся <emphasis>узлами</emphasis> (<emphasis>nodes</emphasis>). Inventor уже предоставляет набор узлов таких как кубы, цилиндры и сплетения (нити), источники света, материалы, камеры и т.д. Узлы представлены классами C++ и могут комбинироваться и разделяться на подклассы. </para>
<para>Введение в Inventor можно найти <ulink url="http://www.motifzone.com/tmd/articles/OpenInventor/OpenInventor.html">здесь</ulink> (в общем, все упоминания SoXt в этой статье можно заменить на SoQt). </para>
<para><link linkend="userinterface-actionpattern">Модель действия</link> позволяет инкапсулировать действия, вызываемые пользователем в объекте, который может быть "подключён" где-нибудь в меню или панелях инструментов, но она не отвечает за составление меню как таковых. В частности, вам нужно построить все меню в коде C++ и явно вставить действия в определённом порядке. Таким образом, трудно сделать меню. </para>
<para>Проблема решается набором классов <literal>XMLGUI</literal>. Это отделяет действия (в C++) от их отображения в меню и панелях инструментов (в XML). Без изменения исходного кода, меню можно легко подкорректировать изменением XML-файла. Более того, это позволяет удостовериться, что стандартные действия (типа <menuchoice><guimenu>Файл</guimenu><guimenuitem>Открыть...</guimenuitem></menuchoice> или <menuchoice><guimenu>Справка</guimenu><guimenuitem>О программе</guimenuitem></menuchoice>) отображаются на месте, рекомендуемом руководством по стилю. XMLGUI особенно важны для модульных программ, где пункты, появляющиеся в меню могут обеспечиваться разными модулями и компонентами. </para>
<para>Класс KDE верхнеуровневого окна, <ulink url="kdeapi:tdeui/TDEMainWindow.html">TDEMainWindow</ulink>, наследует <ulink url="kdeapi:tdeui/KXMLGUIClient.html">KXMLGUIClient</ulink> и, следовательно, поддерживает XMLGUI. Все действия, созданные с ним должны иметь <literal>actionCollection()</literal> как родителя. Вызов<literal>createGUI()</literal> приведёт к построению целого набора меню и панелей инструментов, описанных в XML-файле (обычно с расширением<literal>.ui</literal>). </para>
<para>Далее мы берём программу просмотра KDE <application>KView</application> в виде примера. Его файл <literal>ui.rc</literal> носит имя <filename>kviewui.rc</filename>, устанавливаемый заготовкой <filename>Makefile.am</filename> </para>
<para>Файл XML начинается с объявления типа документа. DTD для kpartgui можно найти в исходниках tdelibs в <filename>tdeui/kpartgui.dtd</filename>. Дальний элемент файл содержим имя экземпляра приложения как атрибут. он может содержать версию в форме "version=2". Это полезно когда вы выпускаете новую версию программы с изменённым меню. Если вы увеличите номер версии в файле <literal>ui.rc</literal>, KDE убедиться, что любая изменённая версия отброшена и используется новый файл. </para>
<para>Следующая строка, <literal><MenuBar></literal>, содержит объявление панели меню. Вы можете вставлять любое количество <literal><ToolBar></literal> для создания панелей инструментов. Меню содержит подменю "view". Это имя является предопределённым и поэтому вы видите нормальные названия пунктов на снимке. Если вы будете добавлять свои подменю, вам нужно будет явно указать их заголовки. Например, в <application>KView</application> есть подменю с заголовком "Image": </para>
<para>В KDE, такие заголовки автоматически извлекаются и помещаются в <ulink url="tde-i18n-howto.html"><literal>.po</literal></ulink>-файлы, которые также содержат перевод этих заголовков на другие языки (оригинальным языком программы должен быть английский, а, например, русские сообщения должны помещаться в такие файлы - на земле больше людей, знающих английский). Не забудьте также вставить символ "&" (акселератор), в XML это будет "&amp;". </para>
<para>Давайте вернёмся к примеру. Меню <guimenu>View</guimenu> содержим несколько действий: <literal>zoom50</literal>, <literal>zoom100</literal>, <literal>zoom200</literal>, <literal>zoomMaxpect</literal> и <literal>fullscreen</literal>, объявленные в элементе <literal><Action></literal>. Отделитель на снимке соответствует элементу <literal><Separator></literal>. </para>
<para>Некоторые пункты меню не имеют соответствующих им записей в XML-файле. Это <emphasis>стандартные действия</emphasis>. Они создаются классом <ulink url="kdeapi:tdeui/KStdAction.html">KStdAction</ulink>. При создании таких действий (к4ак в нашем C++ примере выше), они автоматически вставляются в определённой последовательности, и уже имеют значок и комбинацию клавиш. Эти действия описаны в <filename>tdeui/ui_standards.rc</filename> в исходниках tdelibs. </para>
<listitem><para><literal>fullWidth</literal>: Говорит XMLGUI, что панель имеет максимально доступную ширину. Если это равно "false", панель занимает столько, сколько необходимо, а на оставшемся месте ряда располагаются другие панели инструментов. </para></listitem>
<listitem><para><literal>newline</literal>: Если равно "true", панель всегда находится в начале ряда. </para></listitem>
<listitem><para><literal>noEdit</literal>: Обычно, пользователь может изменять панели инструментов через <menuchoice><guimenu>Настройки</guimenu><guimenuitem>Настроить панели инструментов...</guimenuitem></menuchoice>. Этот атрибут позволяет отменить это поведение. </para></listitem>
<listitem><para><literal>iconText</literal>: Говорит XMLGUI отображать значок и текст действия. Обычно, текст отображается только в всплывающей подсказке. Возможные значения этого атрибута - "icononly" (только значки), "textonly" (только текст), "icontextright" (текст справа от значка) "icontextbottom" (текст снизу от значка). </para></listitem>
<listitem><para><literal>hidden</literal>: Если имеет значение "true", панель инструментов не видна по умолчанию. </para></listitem>
<listitem><para><literal>position</literal>: По умолчанию - "top", что означает, что панель располагается рядом с меню (т.е. вверху окна). Для программ с большим количеством инструментария, например графических, имеет смысл установить этот атрибут в "left", "right" или "bottom". </para></listitem>
<para>Очевидно, XML может только содержать статическое описание пользовательского интерфейса, но часто нужно изменить меню во время выполнения. Например, меню <guimenu>Адрес</guimenu> в <application>Konqueror</application> содержит набор пунктов <guimenuitem>Open with Foo</guimenuitem>, отвечающих программам, способным открыть текущий файл (текущий MIME-тип). В XMLGUI функции динамической работы с меню реализованы с понятием <emphasis>списков действий</emphasis> (<emphasis>action lists</emphasis>). Он объявляется как один пункт в XML -файле, но состоит из несколькихдействий, подключаемых в меню во время выполнения. Приведённый выше пример реализован со следующим объявлением в XML-файле <application>Konqueror</application>: </para>
<para>Функция <function>KXMLGUIClient::plugActionList()</function> используется для добавления действий, а<function>KXMLGuiClient::unplugActionList()</function> удаляет все подключённые действия. Обновление: </para>
<para>В отличие от статических действий, созданные здесь <emphasis>не</emphasis> имеют коллекцию действий в как родителя, и вы должны явно их удалять. Для этого можно установить <literal>openWithActions.setAutoDelete(true)</literal> в примере выше. </para>
<para>Примеры, приведённые выше содержали только случаи, где создавались главное меню приложения и его панели инструментов. Их построение полностью скрыто от вас в функции <function>createGUI()</function>. В XML-файле можно также описывать и контекстные меню. Получить указатель на контекстное меню можно в клиентской factory: </para>
<listitem><para>Всплывающие подсказки. Особенно важны для панелей инструментов, где вместо текста обычно находятся значки. </para></listitem>
<listitem><para>"Что это?" ("What's this?") обычно содержит более длинное описание элемента графического интерфейса. Её можно вызвать нажатием <keycombo><keycap>Shift</keycap><keycap>F1</keycap></keycombo> или щелчком на знаке вопроса в заголовке окна. При этом курсор превратится в знак вопроса и пользователю нужно будет щёлкнуть на элементе, по которому он желает получить справку </para></listitem>
<listitem><para>Недостаток такого подхода состоит в том, что пользователь не может сразу узнать, предоставляет ли элемент управления справку. И после нескольких попыток получения такой справки (когда при щелчке на элементе она не будет появляться), пользователь утратит интерес к этому занятию. </para>
<para>Одним из преимуществ является то, что такие справки могут содержать <ulink url="kdeapi:qt/QStyleSheet">форматирование</ulink>. </para>
<listitem><para>На конец, каждая программа должны иметь руководство. Его обычно читают (если читают - прим. перев.) в<application>KHelpCenter</application> (вызываемый через меню<guimenu>Справка</guimenu>). Также, можно воспользоваться tdeioslave'ом konqueror'а help:/. Руководство обычно не должно повторять информации, содержащейся в справке другой формы (всплывающие подсказки и т.д.), в нём должен быть цельный обзор возможностей прогаммы и т.п. Руководства для программ KDE должны быть в формате <ulink url="http://i18n.kde.org">DocBook</ulink>. Он основан на XML и, следовательно, является свободно конвертируемым - начиная от банального HTML и заканчивая PDF. </para></listitem>
<para>С точки зрения программиста, Qt предоставляет простой API для интерактивной справки. Чтобы присвоить подсказку элементу управления, воспользуйтесь классом <ulink url="kdeapi:qt/QToolTip">QToolTip</ulink>. </para>
<para>Если меню и панели инструментов созданы с помощью <ulink url="actionpattern.html">модели действий</ulink>, текст подсказки передаётся в первом аргументе конструктора <ulink url="kdeapi:tdeui/TDEAction.html">TDEAction</ulink>: </para>
<para>Отобразить первую страницу справки с её содержанием. Для вывода конкретной страницы руководства передайте<function>invokeHelp()</function> дополнительный аргумент - ссылку-"якорь" для перехода. </para>
<para>Понятие <emphasis>служба</emphasis> (<emphasis>service</emphasis>) - основа модульной архитектуры KDE. Нет строгой технической реализации, связанной с этим понятием - службами могут быть модули, (plugins) в форма совместно используемых библиотек, или это могут быть программы, управляемые посредством протокола <ulink url="dcop.html">DCOP</ulink>. Т.е. заявление, что программа является <emphasis>службой определённого типа</emphasis>, говорит о доступности соответствующего API. В C++ тип службы можно представить в виде абстрактного класса, а саму службу - в виде реализации. </para>
<para>Преимущество такого отделения очевидно: программа, поддерживающая определённый тип службы может использовать любую службу этого типа. Она просто вызывает функции, имена которых закреплены в "абстрактном классе". За счёт такой унификации, службы можно подменять, изменять без каких-либо действий над программой, использующей их. </para>
<listitem><para>Движок HTML, используемый в <application>Konqueror</application> - встраиваемый компонент, реализующий типа служб <literal>KParts/ReadOnlyPart</literal> и <literal>Browser/View</literal>. </para></listitem>
<listitem><para>В <application>KDevelop</application> большая часть функций разделены по реализациям типа <literal>KDevelop/Part</literal>. При запуске программы, загружаются все (доступные) службы, расширяющие её функциональность. </para></listitem>
<listitem><para>В режиме просмотра "В виде значков", <application>Konqueror</application> отображает - если это включено - миниатюрные представления изображений, HTML-страниц, PDF и текстовых файлов. Если вы хотите сделать такой миниатюрный просмотр файлов, редактируемых вашим приложением, имеющих некоторый MIME-тип, вы можете реализовать службу <classname>ThumbCreator</classname>. </para></listitem>
<para>Служба характеризуется не только типом, который она реализует, а ещё некоторыми <emphasis>свойствами</emphasis> (<emphasis>properties</emphasis>). Например, ThumbCreator не только реализует класс C++ с типом <classname>ThumbCreator</classname>, он также имеет список MIME-типов, за которые он отвечает. Аналогично, компоненты (parts) KDevelop передают при загрузке основной программе язык, который они поддерживают. Для этого в KDE есть развитый CORBA-like <emphasis>trader</emphasis> со сложным языком запросов. </para>
<para>Новые типы служб добавляются установкой их описания в каталог <filename>TDEDIR/share/servicetypes</filename>. В automake framework, это можно сделать заготовкой <filename>Makefile.am</filename>: </para>
<para>Кроме обычных записей, здесь есть объявление наличия свойств. Каждое определение свойства отвечает группе <literal>[PropertyDef::name]</literal> в файле настроек. В этой группе, <literal>Type</literal> объявляет тип свойства. Возможные типы - всё, что может храниться в <ulink url="kdeapi:qt/QVariant">QVariant</ulink>. </para>
<para>Файл <filename>kdevdoxygen.desktop</filename> объявляет модуль <literal>KDevDoxygen</literal> с типом службы <literal>KDevelop/Part</literal>: </para>
<para>Кроме обычных записей, здесь есть <literal>X-TDE-Library</literal>. В ней должно содержаться имя библиотеки libtool (без расширения <literal>.la</literal>). Она также устанавливает (префиксом <literal>init_</literal>) имя символьного идентификатора библиотеки, возвращающего object factory. В нашем случае, библиотека должна содержать следующую функцию: </para>
<para>Тип класса factory <classname>DoxygenFactory</classname> зависит от типа службы. В примере с модулем KDevelop, factory должен быть типа <classname>KDevFactory</classname> (наследник <classname>KLibFactory</classname>). Более общим примером является <ulink url="kdeapi:tdeparts/KParts::Factory">KParts::Factory</ulink>, который производит объекты <ulink url="kdeapi:tdeparts/KParts::ReadOnlyPart">KParts::ReadOnlyPart</ulink> или, в большинстве случаев, <ulink url="kdeapi:tdecore/KLibFactory">KLibFactory</ulink>. </para>
<title>Использование служб совместно используемых библиотек</title>
<para>In order to use a shared library service in an application, you need to obtain a <ulink url="kdeapi:tdeio/KService.html">KService</ulink> object representing it. This is discussed in the <ulink url="mime.html">section about MIME types</ulink> (and in a section about the trader to be written :-) </para>
<para>Получив объект <classname>KService</classname>, остаётся загрузить библиотеку и получить указатель на объект factory: </para>
<para>Дальнейшие действия зависят от типа службы. Обычно объекты создаются методом <ulink url="kdeapi:tdecore/KLibFactory.html#ref3">KLibFactory::create()</ulink>. Для KParts, вам нужно будет передать указатель на factory KParts::Factory и использовать его метод create(): </para>
<para>Служба DCOP обычно реализуется в виде программы, запускаемой по запросу. Затем она переходит в цикл событий и ожидает запросов на соединение DCOP. Программа может быть интерактивной, а может полностью выполняться как демон. Примером последнего служит <literal>tdeio_uiserver</literal>, реализующий взаимодействие с пользователем типа диалога выполнения TDEIO. Преимущество такой реализации заключается в том, что процесс выполнения нескольких загрузок может быть отображён в одном окне, даже если они запущены разными программами. </para>
<para>Служба DCOP объявляется указанием не библиотеки, как в прошлом случае, а имени приложения. Также, службы DCOP не указывают ServiceType, т.к. они обычно запускаются явным указанием их имени. Дополнительные свойства занимают две строки: </para>
<para><literal>X-DCOP-ServiceType</literal> определяет метод запуска. Значение <literal>Unique</literal> говорит о невозможности запуска нескольких экземпляров этой службы. Это значит, что если вы попытаетесь запуститьэту службу (например, через <ulink url="kdeapi:tdecore/TDEApplication.html#startServiceByName">TDEApplication::startServiceByName()</ulink>, и KDE обнаружит, что такая служба уже зарегистрирована в, то будет использована уже запущенная копия службы. В этом случае она должна быть реализована как <ulink url="kdeapi:tdecore/KUniqueApplication.html">KUniqueApplication</ulink>. </para>
<para>Значение <literal>Multi</literal> для <literal>X-DCOP-ServiceType</literal> говорит, что одновременно можно запускать несколько экземпляров службы, так что каждая попытка запустить её приведёт к новому запуску. Значение <literal>None</literal> говорит о необходимости немедленного запуска службы. </para>
<para><literal>X-TDE-StartupNotify</literal> обычно должно быть false. Иначе при запуске программы будет отображаться соответствующее уведомление. </para>
<para>Обратите внимание, что пример вызова DCOP использует явное приведение аргументов. Чаще вам придётся использовать заглушку (stub), созданную dcopidl2cpp, т.к. это намного проще и меньше подвержено ошибкам. </para>
<para>В пиведенном примере, служба была запущена по имени ("by name"), т.е. первым аргументом <function>TDEApplication::startServiceByName()</function> является имя, указываемое в записи <literal>Name</literal> файла .desktop. Как альтернативу, можно использовать <function>TDEApplication::startServiceByDesktopName()</function>, которому передаётся имя файла .desktop, например <literal>"tdeio_uiserver.desktop"</literal>. </para>
<para>Все эти вызовы берут список URL вторым аргументом. Третий аргумент - указатель на <classname>TQString</classname>. Если произойдёт ошибка, в это строку будет занесено (локализованное) сообщение об ошибке. </para>
<para>MIME- используются для описания типа содержимого файлов или потоков данных. Изначально они были введены для отправки изображений или звуковых файлов по e-mail (MIME расшифровывается как "Multipurpose Internet Mail Extensions"). Позднее, эта система также была использована в веб-браузерах для определения как обрабатывать данные, посылаемые веб-сервером. Например, HTML-страница имеет тип MIME "text/html", файл Postscript - "application/postscript". В KDE, эта идея используется повсеместно: </para>
<listitem><para>В режиме просмотра <application>Konqueror</application> "В виде значков", файлы представляются значками. Каждый MIME-тип имеет ассоциированный с ним значок. </para></listitem>
<listitem><para>При нажатии по файлу в окне <application>Konqueror</application>, либо он просматривается во встроенном представлении, либо открывается в отдельной программе, ассоциированной с ним. </para></listitem>
<listitem><para>При переносе файлов (drag-and-drop) из одного окна в другое, последнее может принимать только определённые типы данных. </para></listitem>
<listitem><para>Данные, хранящиеся в буфере обмена, также имеют MIME-тип. Традиционно, программисты "иксов" принимают только изображения и текст, но а Qt не существует ограничений на тип данных. </para></listitem>
<para>С приведённых выше примеров видно, что работа с MIME - достаточно сложная задача. Сначала, нужно установить соответствие между маской файла и типом MIME. KDE позволяет определить тип MIME не только по имени файла, а и по его содержимому, для случаев когда имя файла недоступно, или оно без расширения. Далее, необходимо установить связи между MIME-типами и программами или библиотеками, позволяющими обрабатывать их. </para>
<para>Существует большое разнообразие API для установления типа MIME данных или файлов. В общем случае, вам придётся выбирать между скоростью и достоверностью. Вы можете определить тип файла только из его расширения. Например, файл с именем <filename>foo.jpg</filename> скорее всего имеет тип "image/jpeg". Если же файл не имеет расширения, его тип придётся определять по его содержимому. Естественно, это занимает больше времени, особенно для удалённых файлов. Такой метод основывается на файле <filename>TDEDIR/share/mimelnk/magic</filename> и следовательно тяжелее расширить. В большинстве случаев, для объявления типа MIME, достаточно установить файл <literal>.desktop</literal>, который будет обрабатываться (с приемлемой скоростью) библиотеками KDE. </para>
<para>Давайте объявим тип <literal>"application/x-foo"</literal> для нашей новой программы <application>foobar</application>. Прежде всего, нужно написать файл <filename>foo.desktop</filename> и установить его в <filename>TDEDIR/share/mimelnk/application</filename>. Это можно сделать добавлением следующего текста в <filename>Makefile.am</filename>: </para>
<para>Если это .desktop файл одного из пакетов KDE, запись <literal>"Comment[ru]"</literal> в нём не нужна, т.к. перевод комментариев производится другим образом (через .po-файлы, находящиеся в модуле CVS tde-i18n/ru/<пакет>/desktop_<имя>.po). <filename>.desktop</filename> указывает значок <filename>fooicon.png</filename>, представляющий файл программы, например в <application>Konqueror</application>. </para>
<para>В библиотеках KDE, такое объявление типа устанавливается в экземпляре класса <ulink url="kdeapi:tdeio/KMimeType.html">KMimeType</ulink>: </para>
<programlisting>KMimeType::Ptr type = KMimeType::mimeType("application/x-foo");
<para>Самый быстрый метод определения типа файла - <function>KMimeType::findByURL()</function>. Как видно из названия, он определяется по передонному URL. Для некоторых протоколов (типа http, man, info), этот механизм не используется. Например, сценарии CGI на web-серверах написанные на Perl часто имеют расширение <literal>.pl</literal>, т.е. тип <literal>"text/x-perl"</literal>. Тем не менее, сценарий передаёт клиенту обычный HTML. В таких случаях, <function>KMimeType::findByURL()</function> возвращает MIME -тип <literal>"application/octet-stream"</literal> (тоже самое - <function>KMimeType::defaultMimeType()</function>), что говорит о неудачной попытке определения типа. </para>
<programlisting>KMimeType::Ptr type = KMimeType::findByURL("/home/bernd/foobar.jpg");
<para>Также, можно определять тип области памяти. Это, например, используется в <application>Kate</application> для определения режима подсветки: </para>
<para>Это приводит к загрузке части файла через TDEIO и его проверке. Помните, что это занимает некоторое время и блокирует программу. Используйте это только если <function>KMimeType::findByURL()</function> вернуло <literal>"application/octet-stream"</literal>. </para>
<title>Установка связи MIME-типа с приложением или службой</title>
<para>При установке приложения, или компоненты наподобие KPart , также устанавливается и файл <literal>.desktop</literal>, содержащий список MIME-типов, которые оно может обрабатывать. Получить список программ и служб, обрабатывающих данный MIME-тип, можно через класс <classname>KServiceTypeProfile</classname>: </para>
<para><function>KServiceTypeProfile::offers()</function> возвращает список в определённом пользователем порядке. Изменить предпочитаемый порядок можно командой <command>"keditfiletype text/html"</command>. </para>
<para>В приведённом выше примере запрашивался список приложений, поддерживающих <literal>text/html</literal>. Это будут - среди прочих - редакторы HTML типа <application>Quanta Plus</application>. Вы можете изменить второй агумент <literal>"Application"</literal> на <literal>"KParts::ReadOnlyPart"</literal>. В этом случае вы получите список встраиваемых компонентов, поддерживающих HTML, например TDEHTML. </para>
<para>Чтобы получить приложение по умолчанию, воспользуйтесь этим кодом: </para>
<para>Во время world wide web, программы должны иметь доступ к ресурсам сети - загружать файлы, передавать какие-либо данные. возможность получать доступ к файлам вне зависимости от их расположения называется <emphasis>сетевая прозрачность</emphasis> (<emphasis>network transparency</emphasis>). </para>
<para>В прошлом было несколько попыток реализации этого. Старая файловая система NFS - одна из таких попыток на уровне POSIX API. Она приемлемо работала в локальных, тесно связанных сетях, но оказалась немасштабируемой до современных технологий. Здесь важна <emphasis>асинхронность</emphasis>. Пока вы ждёте загрузки страницы в вашем веб-браузере, пользовательский интерфейс не должен блокироваться. Также, прорисовка страниц не должна начинаться только после полной загрузки, а выполняться по мере поступления данных. </para>
<para>В библиотеках KDE, сетевая прозрачность реализована в TDEIO API. Основная идея этой архитектуры - <emphasis>задание</emphasis> (<emphasis>job</emphasis>) ввода/вывода (IO - input/output). Задание может копировать, удалять, перемещать файлы и т.п. После запуска, задание работает в фоновом режиме и не блокирует приложение. Сообщение между заданием и приложением - например передача данных о степени выполнения - выполняется интегрировано с циклом событий Qt. </para>
<para>Фоновые операции выполняются с помощью <emphasis>ioslaves</emphasis>. Они запускаются как отдельный процесс соединяются через доменные сокеты UNIX. Таким образом не требуется, многопотоковость и сбой slave'а не приведёт к сбою приложений, использующих его. </para>
<para>Расположение файла определяется URL. Вего начале пишется tdeioslave, обрабатывающий протокол, по которому доступен файл. Например, это может быть file, http, tar и т.д. Напримерфайл из архива tar, находящегося на http-сервере может иметь URL </para>
<para>В большинстве случаев, задания создаются вызовом функций в пространстве имён TDEIO. Эти функции берут один или два URL как аргумент, и другое. После окончания задания, посылается сигнал <literal>result(TDEIO::Job*)</literal> и задание удаляется: </para>
<listitem><para>Информация о файле - размер, время изменения, права доступа. Информацию можно получить из TDEIO::StatJob::statResult() после завершения задания. </para></listitem>
<para>TDEIO::stat() и TDEIO::listDir() возвращают свой результат в типе UDSEntry, UDSEntryList соотв. Последний определён как QValueList<UDSEntry>. UDS расшифровывается как "Universal directory service". Принцип заключается в том, запись о каталоге содержит только ту информацию, доступную ioslave. Например, http slave не предоставляет информацию о правах доступа и владельцах файла. UDSEntry является списком UDSAtom'ов. Каждый атом содержит определённую часть информации. Он состоит из типа, хранящегося в m_uds и либо целого в m_long, либо строки в m_str, в зависимости от типа. </para>
<listitem><para>UDS_GROUP (string) - Группа файла. </para></listitem>
<listitem><para>UDS_NAME (string) - Имя файла. </para></listitem>
<listitem><para>UDS_ACCESS (integer) - Права доступа как в функции libc stat() в поле st_mode. </para></listitem>
<listitem><para>UDS_FILE_TYPE (integer) - Тип файла, например, как записывается функцией stat() в поле st_mode. Вы можете использовать обычные макросы libc наподобие S_ISDIR для тестирования этого значения. Помните, что данные, предоставляемые ioslave'ами соответствуютstat(), не lstat(), т.е., например, в случае символической ссылки будет возвращаться тип файла, на который ссылка указывает. </para></listitem>
<listitem><para>UDS_LINK_DEST (string) - В случае символической ссылки, имя файла, на который она ссылается. </para></listitem>
<listitem><para>UDS_MODIFICATION_TIME (integer) - Время (тип time_t) последнего изменения файла, как сохраняется функцией stat() в поле st_mtime. </para></listitem>
<listitem><para>UDS_ACCESS_TIME (integer) - Время последнего доступа, как записывается функцией stat() в поле st_atime. </para></listitem>
<listitem><para>UDS_CREATION_TIME (integer) - Время создания файла, как, например, записывается функцией stat() в поле st_ctime. </para></listitem>
<listitem><para>UDS_GUESSED_MIME_TYPE (string) - MIME-тип файла, по предположению slave. В отличие от предыдущего, не всегда точный (т.к. в некоторых случаях точное определение типа требует больших затрат ресурсов). Например, класс KRun явно проверяет MIME-тип только если он не располагает точной информацией. </para></listitem>
<para>Не смотря на всю гибкость хранения информации в <classname>UDSEntry</classname>, для программиста это всё же составляет некоторые трудности (задержки во времени реализации). Например, чтобы определить MIME-тип файла, вам нужно итерировать по всем атомам и проверить является ли <literal>m_uds</literal> <literal>UDS_MIME_TYPE</literal>. к счастью, существует более простой API: класс <classname>KFileItem</classname>. </para>
<para>Часто, асинхронное API TDEIO слишком сложное для использования, и асинхронность не всегда важна. Например, в программе, которая может работать только с одним документом в одно время, можно сделать немногое в время загрузки файла. Для таких простых случаев, вы можете воспользоваться функциями класса TDEIO::NetAccess. Например, чтобы скопировать файл: </para>
<para>Функция возвратится после выполнения задания. Будет показана информация о прогрессе, а программа всё равно будет получать события прорисовки. </para>
<para>Некоторый интерес также представляет комбинация функций <function>removeTempFile()</function> и <function>download()</function>. Последняя загружает файл по заданному URL и сохраняет его во временный файл с уникальным именем. Имя файла сохраняется во второй аргумент. <emphasis>Если</emphasis> URL ссылается на локальный файл, второй аргумент содержит локальное имя файла. Функция<function>removeTempFile()</function>удаляет файл если он получился в результате загрузки. Вот заготовка кода для загрузки файла не смотря на его положение: </para>
<para>Интерфейс к заданиям TDEIO достаточно абстрактный. При создании задания, вы можете добавить метаданные к нему. Каждый элемент метаданных состоит из пары ключ-значение. Например, чтобы указать HTTP-slave не использовать кэш при загрузке страницы: </para>
<para>Такой же механизм используется и в обратном направлении. Метод <function>Job::queryMetaData()</function> позволяет запрашивать данные. Например HTTP-slave может предоставить ключ<literal>"modified"</literal>, содержащий (в виде строки) дату последнего изменения страницы. Пример: </para>
<para>Используя TDEIO API, вам не нужно разбираться в подробностях запуска IO slave'ов и связи с ними. Чаще всего нужно просто запустить задание и обрабатывать посылаемые им сигналы. </para>
<para>На самом деле, за занавесками всё намного сложнее. При создании задания оно помещается в очередь, когда приложение возвращается в главный цикл событий, TDEIO создаёт процессы slave для заданий в очереди. После завершения работы, задание не уничтожается, а находится в "подвешенном состоянии" около 3 минут - на случай если поступит запрос на новое задание с теми же протоколом и узлом. </para>
<para>Если slave'ы запускаются по мере поступления запросов (т.е. параллельно), эта схема называется <emphasis>прямой</emphasis>. Это не всегда приемлемо т.к. требует дополнительных затрат памяти. </para>
<para>Чтобы избежать этого, можно воспользоваться <emphasis>расписанием</emphasis> (<emphasis>schedule</emphasis>) заданий. При этом одновременно может выполняться только ограниченное число заданий (сейчас это 3). Следующие задания будут ставиться в очередь: </para>
<para>Третий вариант - <emphasis>ориентация на соединения</emphasis>. Например, для IMAP slave, не имеет смысла запускать несколько процессов для одного сервера. Поэтому нельзя запускать несколько заданий к одному серверу. Это можно сделать с помощью TDEIO::Scheduler: </para>
<para>Далее мы обсудим процесс создания ioslave. По аналогии со службами, установка заключается в написании небольшого конфигурационного файла. Следующая заготовка Makefile.am устанавливает протокол ftp: </para>
<para>Запись <literal>"protocol"</literal> определяет протоколы, за которые отвечает slave. <literal>"exec"</literal> - имя библиотеки, реализующей slave. Призпуске задания, <command>"tdeinit"</command> загружает указанную билиотеку. </para>
<para>Строки "input" "output" не используются на данный момент. </para>
<para>Оставшиеся строки в файле <literal>.protocol</literal> определяют возможности slave'а. Последние обычно намного проще, чем TDEIO API. Например, чтобы получить рекурсивный листинг каталога, запускается задание для сканирования верхнего каталога, затем для каждого подкаталога запускается ещё одно, отдельное, задание. При этом существует ограничение на количество одновременно запущенных заданий. Аналогично, чтобы скопировать файл с протоколом, не поддерживающим это напрямую, (например<literal>ftp:</literal>), TDEIO читает файл и передаёт его по назначению. </para>
<para>Т.к. slave' загружаются в виде совместно используемых библиотек, но действуют отдельно, их структура исходных файлов немного отличается от структуры обычной библиотеки. Функция, вызываемая для запуска называется <function>kdemain()</function>. В ней обычно выполняются некоторые инициализации, а затем она входит в цикл событий: </para>
<programlisting>extern "C" { int kdemain(int argc, char **argv); }
<para>Slave'ы реализованы в виде подклассов<classname>TDEIO::SlaveBase</classname>. Следовательно, действия, перечисленные в<literal>.protocol</literal> отвечают определённым виртуальным функциям <classname>TDEIO::SlaveBase</classname>, которые должны реализовываться в slave'е, а именно: </para>
<para>Также, существуют виртуальные функции, которые не нужно заносить в файл <literal>.protocol</literal> - TDEIO автоматически может определить поддерживаются они или нет. </para>
<para>Все реализации должны завершаться одним из двух вызовов - <literal>finished()</literal> или <literal>error()</literal> (с кодом ошибки в первом аргументе и строкой объяснения в втором). Коды ошибок перечислены в enum <type>TDEIO::Error</type>. Второй аргумент - обычно URL. Это используется например в<function>TDEIO::Job::showErrorDialog()</function>. </para>
<para>Для slave'ов, реализующих сетевые протоколы, нужно реализовать функцию <function>SlaveBase::setHost()</function>. Она вызывается для передачи имени узла, порта, имени пользователя и пароля. Вообще, метаданные, предоставляемые приложением, можно получить с помощью <function>SlaveBase::metaData()</function>. Наличие их можно определить функцией <function>SlaveBase::hasMetaData()</function>. </para>
<listitem><para><function>get()</function> посылает блоки данных. Это сделано с помощью функции <function>data()</function>, аргументом которой является <classname>QByteArray</classname>. Если вы посылаете большой файл, вызовите <function>data()</function> с меньшими блоками. Функция <function>finished()</function> вызывается по завершению передачи. </para></listitem>
<listitem><para><function>listDir()</function> выдаёт сведения о содержимом каталога. Для этого вызовите <function>listEntries()</function> с аргументом типа<classname>TDEIO::UDSEntryList</classname>. Подобно<function>data()</function>, вы можете сделать это несколько раз. В конце вызовите <function>listEntry()</function> с вторым аргументом равным true. Вы также можете вызвать<function>totalSize()</function> для передачи количества элементов каталога. </para></listitem>
<listitem><para><function>stat()</function> выдаёт сведения о файле, например его размер, MIME-тип и т.д. Они упаковываются в один элемент типа <classname>TDEIO::UDSEntry</classname>, обсуждаемый ранее. Используйте <function>statEntry()</function> для передачи такого элемента приложению. </para></listitem>
<listitem><para><function>mimetype()</function> вызывает <function>mimeType()</function> с аргументом типа string. </para></listitem>
<listitem><para><function>get()</function> и <function>copy()</function> могут предоставлять информацию о процессе выполнения с помощью методов <function>totalSize()</function>, <function>processedSize()</function>, <function>speed()</function>. Общий и выполненный размеры передаются в байтах, скорость - в байтах в секунду. </para></listitem>
<listitem><para>Вы можете посылать произвольные пары ключ-значение с помощью <function>setMetaData()</function>. </para></listitem>
<para>Иногда slave должен взаимодействовать с пользователем. Это может быть в виде информационных сообщений, диалогов авторизации и подтверждения замены файла. </para>
<listitem><para><function>infoMessage()</function> - информационное сообщение, такое как "Retrieving data from <host>" http slave'а, обычно отображаемое в панели состояния. На стороне приложения, этот метод отвечает сигналу <function>TDEIO::Job::infoMessage()</function>. </para></listitem>
<listitem><para><function>warning()</function> - предупреждение в окне сообщений с <function>KMessageBox::information()</function>. </para></listitem>
<listitem><para><function>messageBox()</function> - расширенная версия предыдущего. Здесь можно устанавливать свои кнопки, текст заголовка. Для подробностей обратитесь к определению enum <type>SlaveBase::MessageBoxType</type>. </para></listitem>
<listitem><para><function>openPassDlg()</function> - Открыть диалог для ввода имени пользователя и пароля. </para></listitem>
