>tdecore - основа, каркас для любого приложения KDE. Она обеспечивает доступ к системе конфигурации, обработке командной строки, загрузке и управлению значками, межпроцессное взаимодействие и т.д. </para
> содержит большое количество элементов управления и стандартных диалогов, которых нет в Qt или которые имеют расширенную функциональность по сравнению с их аналогами. </para
></listitem>
</varlistentry>
<varlistentry>
<term
><ulink url="kdeapi:kio/index.html"
>kio</ulink
></term>
<listitem
><para
>Библиотека <literal
>kio</literal
> содержит удобства для асинхронного, сетевого файлового ввода/вывода и доступ к обработчику mimetype. Она также содержит диалог открытия файлов и его вспомогательные классы. </para
></listitem>
</varlistentry>
<varlistentry>
<term
><ulink url="kdeapi:kjs/index.html"
>kjs</ulink
></term>
<listitem
><para
>Библиотека <literal
>kjs</literal
> содержит реализацию JavaScript. </para
></listitem>
</varlistentry>
<varlistentry>
<term
><ulink url="kdeapi:khtml/index.html"
>khtml</ulink
></term>
<listitem
><para
>Библиотека <literal
>khtml</literal
> содержит компонент KHTML, виджет для отображения HTML, DOM API, включая интерфейсы к Java и JavaScript. </para
></listitem>
</varlistentry>
</variablelist>
</simplesect>
<simplesect id="structure-grouped">
<title
>Сгруппированные классы</title>
<para
>Каркас приложения - классы, требуемые для любого KDE-приложения. </para>
>Пользовательские настройки для обработки MIME-типов. </para>
</formalpara
></listitem>
<listitem
><formalpara
><title
><ulink url="kdeapi:kio/KServiceTypeProfile"
>KTrader</ulink
></title>
<para
>Запрос служб. </para>
</formalpara
></listitem>
</itemizedlist>
</simplesect>
</chapter>
<chapter id="graphics">
<title
>Графика</title>
<sect1 id="graphics-qpainter">
<title
>Низкоуровневая графика с QPainter</title>
<simplesect id="qpainter-rendering">
<title
>Прорисовка с QPainter</title>
<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/QWidget"
>QWidget</ulink
>, представляющий элемент управления на экране, <ulink url="kdeapi:qt/QPrinter"
>QPrinter</ulink
>, представляющий виджет в виде вывода Postscript, и <ulink url="kdeapi:qt/QPicture"
>QPicture</ulink
>, позволяющий записывать и воспроизводить команды рисования (с диска) в формате SVG. </para>
<para
>Такое рисование используется преимущественно в методе paintEvent() класса элемента управления. </para>
<programlisting
>void FooWidget::paintEvent()
{
QPainter p(this);
// Setup painter
// Use painter
}
</programlisting>
<para
>При рисовании на принтере не забудьте вызывать QPrinter::newPage() для сигнализации о необходимости смены страницы. Также, при печати, вы можете использовать <ulink url="kdeapi:qt/QPaintDeviceMetrics"
>метрику устройства</ulink
> для подсчёта координат. </para>
</simplesect>
<simplesect id="qpainter-transformations">
<title
>Преобразования</title>
<para
>По умолчанию, при использовании QPainter, прорисовка происходит в системе координат устройства. Это значит, что если вы рисуете линию по оси абсцисс с длинов в 10 единиц, её длина на экране будет составлять 10 пикселей. Однако, QPainter может применить некоторое преобразование перед прорисовкой фигур и кривых. Оно переносит координаты x и y линейно в x' и y' соответственно. </para>
>Матрицу 3x3 в этом равенстве можно получить с помощью QPainter::setWorldMatrix(), она имеет тип <ulink url="kdeapi:qt/QWMatrix"
>QWMatrix</ulink
>. Это должна быть тождественная матрица, т.е. m11 и m22 равны единице, остальные параметры - нулю. Три типа преобразований: </para>
<itemizedlist>
<listitem
><formalpara>
<title
>Сдвиги</title>
<para
>Перемещает все точки объекта на определённую величину в определённом направлении. Трансляционная матрица может быть получена вызовом метода m.translate(dx, dy). Это отвечает матрице </para>
>Растянуть или сжать координаты объекта, делая его больше или меньше и сохраняя пропорции. Масштабирование можно применить к матрице методом m.scale(sx, sy). </para>
>Преобразования можно совмещать с умножением элементарных матриц. Помните, что операции с матрицами не являются коммутативными, поэтому обращайте внимание порядок множителей. </para>
</simplesect>
<simplesect id="qpainter-strokeattributes">
<title
>Изменение параметров штрихов</title>
<para
>Прорисовка линий, кривых и контуров многоугольниковможет быть изменена установкой специального пера через QPainter::setPen(). Аргумент этого метода - объект типа <ulink url="kdeapi:qt/QPen"
>QPen</ulink
>. Он содержит такие параметры как стиль, цвет, тип соединения и концов. </para>
<para
>Стиль пера - член enum <ulink url="kdeapi:qt/Qt#PenStyle-enum"
>Тип заливки многоугольников, окружностей и прямоугольников можно изменить установкой специальной кисти через QPainter::setBrush(). Она берёт аргумент типа <ulink url="kdeapi:qt/QBrush"
>QBrush</ulink
>. </para>
<itemizedlist>
<listitem>
<para
>QBrush::QBrush() - кисть, не заполняющая фигуры.</para>
>Для ещё большего изменения поведения кисти используйте QPainter::setBrushOrigin(). </para>
</simplesect>
<simplesect id="qpainter-color">
<title
>Цвет</title>
<para
>В Qt цвета представлены классом <ulink url="kdeapi:qt/QColor"
>QColor</ulink
>. Qt не поддерживает расширенную функциональность типа цветовых профилей ICC и сглаживание цветов. Цвета указываются по RGB. </para>
<para
>Также возможно использовать оттенки, насыщенность и величина (HSV). Эти параметры напрямую используются в диалоге выбора цвета GIMP. Оттенок отвечает уголку на полосе цвета, насыщенность отвечает расстоянию до центра окружности. Величину можно выбрать отдельным ползунком. </para>
</simplesect>
<simplesect id="qpainter-paintsettings">
<title
>Прочие параметры</title>
<para
>Обычно, точки, которые вы рисуете заменяют те, которые были до них на том же месте. Например, если вы нарисуете квадрат красным цветом, а потом повторите действие, лишь изменив цвет на синий, вы увидите синий квадрат. Пока что Qt не поддерживает прозрачность. Тем не менее, существует простой путь совместить фон и передний план с булевыми операторами. Метод QPainter::setRasterOp() устанавливает используемый оператор, из enum <ulink url="kdeapi:qt/Qt#RasterOp-enum"
>RasterOp</ulink
>. </para>
<para
>По умолчанию установлен CopyROP, который игнорирует фон. Однако вы можете выбрать XorROP. Если вы нарисуете чёрную линию с этим оператором на цветном изображении, цвет покрываемой линией области будет обращён. </para>
</simplesect>
<simplesect id="qpainter-primitives">
<title
>Рисование примитивных фигур</title>
<para
>Далее приводится список графических элементов, поддерживаемых QPainter. Большинство из них имеют несколько перегруженных версий, поэтому принимают различный набор аргументов. Например, методы, работающие с прямоугольниками обычно принимаю либо <ulink url="kdeapi:qt/QRect"
>QRect</ulink
>, либо 4 числа. </para>
<itemizedlist>
<listitem>
<para
>Рисование точки - drawPoint().</para>
</listitem>
<listitem>
<para
>Рисование линий - drawLine(), drawLineSegments(), drawPolyLine().</para>
</listitem>
<listitem>
<para
>Рисование и заполнение прямоугольников - drawRect(), drawRoundRect(), fillRect(), eraseRect().</para>
</listitem>
<listitem>
<para
>Рисование и заполнение окружностей, эллипсов и их частей - drawEllipse(), drawArc(), drawPie, drawChord().</para>
</listitem>
<listitem>
<para
>Рисование и заполнение многоугольников - drawPolygon().</para>
</listitem>
<listitem>
<para
>Рисование кривых bezier - drawQuadBezier() [drawCubicBezier в Qt 3.0].</para>
</listitem>
</itemizedlist>
</simplesect>
<simplesect id="qpainter-pixmaps">
<title
>Рисование растра и изображений</title>
<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/QImage"
>QImage</ulink
> располагаются на стороне клиента. Основное ударение поставлено на прямой доступ к точкам изображения. Это упрощает операции манипуляции с изображениями, загрузку и сохранение на диск (метод QPixmapload() берёт QImage как промежуточный). С другой стороны, рисование на элементе управления - дорогая операция, т.к. включает в себя передачу X-серверу. В зависимости от глубины цвета, преобразование из QImage в QPixmap может требовать dithering. </para>
</simplesect>
<simplesect id="qpainter-drawingtext">
<title
>Рисование текста</title>
<para
>Текст можно нарисовать одним из вариантов перегруженной функции QPainter::drawText(). Шрифт можно установить функцией QPainter::setFont(). Есть также параметр, представляющий их себя комбинацию флагов ORed из enums <ulink url="kdeapi:qt/Qt#AlignmentFlags-enum"
>Qt::AlignmentFlags</ulink
> и <ulink url="kdeapi:qt/Qt#TextFlags-enum"
>Qt::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>
</simplesect>
</sect1>
<sect1 id="graphics-qcanvas">
<title
>Сложная графика с QCanvas</title>
<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>
<mediaobject>
<imageobject
><imagedata fileref="canvas.png"/></imageobject>
</mediaobject>
<para
>Здесь сетка нарисована на фоне. Кроме них там есть элементы QCanvasText и фиолетовый QCanvasPolygon. Бабочка представлена растром QCanvasPixmap. Он имеет прозрачные области. </para>
<para
>Руководство по использованию QCanvas для написания sprite-based игр можно найти <ulink url="http://zez.org/article/articleview/2/1/"
>тут</ulink
>. </para>
</sect1>
<sect1 id="graphics-qglwidget">
<title
>3D-графика с OpenGL</title>
<simplesect id="qglwidget-lowlevel">
<title
>Низкоуровневый интерфейс</title>
<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>
<itemizedlist>
<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>
</itemizedlist>
<para
>В общем, QGLWidget ведёт себя также, как и любой другой элемент управления, например вы можете обрабатывать события мыши как обычно, изменять размер и совмещать егос другими объектами. </para>
<mediaobject>
<imageobject
><imagedata fileref="opengl.png"/></imageobject>
</mediaobject>
<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>
</simplesect>
<simplesect id="qglwidget-highlevel">
<title
>Высокоуровневые интерфейсы</title>
<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>
</simplesect>
</sect1>
</chapter>
<chapter id="userinterface">
<title
>Пользовательский интерфейс</title>
<sect1 id="userinterface-actionpattern">
<title
>Действия</title>
<para
></para>
</sect1>
<sect1 id="userinterface-xmlgui">
<title
>Задание меню и панелей инструментов в XML</title>
<simplesect id="xmlgui-intro">
<title
>Введение</title>
<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>
>. Дальний элемент файл содержим имя экземпляра приложения как атрибут. он может содержать версию в форме "version=2". Это полезно когда вы выпускаете новую версию программы с изменённым меню. Если вы увеличите номер версии в файле <literal
>ui.rc</literal
>, KDE убедиться, что любая изменённая версия отброшена и используется новый файл. </para>
<para
>Следующая строка, <literal
><MenuBar></literal
>, содержит объявление панели меню. Вы можете вставлять любое количество <literal
><ToolBar></literal
> для создания панелей инструментов. Меню содержит подменю "view". Это имя является предопределённым и поэтому вы видите нормальные названия пунктов на снимке. Если вы будете добавлять свои подменю, вам нужно будет явно указать их заголовки. Например, в <application
>-файлы, которые также содержат перевод этих заголовков на другие языки (оригинальным языком программы должен быть английский, а, например, русские сообщения должны помещаться в такие файлы - на земле больше людей, знающих английский). Не забудьте также вставить символ "&" (акселератор), в 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
>. При создании таких действий (к4ак в нашем C++ примере выше), они автоматически вставляются в определённой последовательности, и уже имеют значок и комбинацию клавиш. Эти действия описаны в <filename
>Здесь намного больше атрибутов, чем в меню: </para>
<itemizedlist>
<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>
</itemizedlist>
</simplesect>
<simplesect id="xmlgui-dynamical">
<title
>Динамические меню</title>
<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>
<programlisting
><Menu name="file">
<text>&amp;Location</text>
...
<ActionList name="openwith">
...
</Menu>
</programlisting>
<para
>Функция <function
>KXMLGUIClient::plugActionList()</function
> используется для добавления действий, а<function
>KXMLGuiClient::unplugActionList()</function
> удаляет все подключённые действия. Обновление: </para>
<programlisting
>void MainWindow::updateOpenWithActions()
{
unplugActionList("openwith");
openWithActions.clear();
for ( /* iterate over the relevant services */ ) {
KAction *action = new KAction( ...);
openWithActions.append(action);
}
plugActionList("openwith", openWithActions);
}
</programlisting>
<para
>В отличие от статических действий, созданные здесь <emphasis
>не</emphasis
> имеют коллекцию действий в как родителя, и вы должны явно их удалять. Для этого можно установить <literal
>openWithActions.setAutoDelete(true)</literal
> в примере выше. </para>
</simplesect>
<simplesect id="xmlgui-contextmenus">
<title
>Контекстные меню</title>
<para
>Примеры, приведённые выше содержали только случаи, где создавались главное меню приложения и его панели инструментов. Их построение полностью скрыто от вас в функции <function
>createGUI()</function
>. В XML-файле можно также описывать и контекстные меню. Получить указатель на контекстное меню можно в клиентской factory: </para>
>ищет контейнер в XML-файле. Его описание может быть таким: </para>
<programlisting
>...
<Menu name="context_popup">
<Action name="file_add"/>
<Action name="file_remove"/>
</Menu>
...
</programlisting>
</simplesect>
</sect1>
<sect1 id="help">
<title
>Интерактивная справка</title>
<para
>Существует несколько уровней такой помощи: </para>
<itemizedlist>
<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"
>). Также, можно воспользоваться tdeioslave'ом konqueror'а help:/. Руководство обычно не должно повторять информации, содержащейся в справке другой формы (всплывающие подсказки и т.д.), в нём должен быть цельный обзор возможностей прогаммы и т.п. Руководства для программ KDE должны быть в формате <ulink url="http://i18n.kde.org"
>. Он основан на XML и, следовательно, является свободно конвертируемым - начиная от банального HTML и заканчивая PDF. </para
></listitem>
</itemizedlist>
<para
>С точки зрения программиста, Qt предоставляет простой API для интерактивной справки. Чтобы присвоить подсказку элементу управления, воспользуйтесь классом <ulink url="kdeapi:qt/QToolTip"
>QToolTip</ulink
>. </para>
<programlisting
>QToolTip::add(w, i18n("This widget does something."))
</programlisting>
<para
>Если меню и панели инструментов созданы с помощью <ulink url="actionpattern.html"
>Отобразить первую страницу справки с её содержанием. Для вывода конкретной страницы руководства передайте<function
>invokeHelp()</function
> дополнительный аргумент - ссылку-"якорь" для перехода. </para>
</sect1>
</chapter>
<chapter id="components">
<title
>Компоненты и службы</title>
<sect1 id="components-services">
<title
>Службы KDE</title>
<simplesect id="services-whatarekdeservices">
<title
>Что такое службы KDE?</title>
<para
>Понятие <emphasis
>служба</emphasis
> (<emphasis
>service</emphasis
>) - основа модульной архитектуры KDE. Нет строгой технической реализации, связанной с этим понятием - службами могут быть модули, (plugins) в форма совместно используемых библиотек, или это могут быть программы, управляемые посредством протокола <ulink url="dcop.html"
>DCOP</ulink
>. Т.е. заявление, что программа является <emphasis
>службой определённого типа</emphasis
>, говорит о доступности соответствующего API. В C++ тип службы можно представить в виде абстрактного класса, а саму службу - в виде реализации. </para>
<para
>Преимущество такого отделения очевидно: программа, поддерживающая определённый тип службы может использовать любую службу этого типа. Она просто вызывает функции, имена которых закреплены в "абстрактном классе". За счёт такой унификации, службы можно подменять, изменять без каких-либо действий над программой, использующей их. </para>
<para
>Некоторые примеры: </para>
<itemizedlist>
<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>
</itemizedlist>
<para
>Служба характеризуется не только типом, который она реализует, а ещё некоторыми <emphasis
>свойствами</emphasis
> (<emphasis
>properties</emphasis
>). Например, ThumbCreator не только реализует класс C++ с типом <classname
>ThumbCreator</classname
>, он также имеет список MIME-типов, за которые он отвечает. Аналогично, компоненты (parts) KDevelop передают при загрузке основной программе язык, который они поддерживают. Для этого в KDE есть развитый CORBA-like <emphasis
>trader</emphasis
> со сложным языком запросов. </para>
</simplesect>
<simplesect id="services-definingservicetypes">
<title
>Определение типов служб</title>
<para
>Новые типы служб добавляются установкой их описания в каталог <filename
cout << "Service does not implement the right factory" << endl;
}
</programlisting>
</simplesect>
<simplesect id="services-definingdcopservices">
<title
>Объявление служб DCOP</title>
<para
>Служба DCOP обычно реализуется в виде программы, запускаемой по запросу. Затем она переходит в цикл событий и ожидает запросов на соединение DCOP. Программа может быть интерактивной, а может полностью выполняться как демон. Примером последнего служит <literal
>kio_uiserver</literal
>, реализующий взаимодействие с пользователем типа диалога выполнения KIO. Преимущество такой реализации заключается в том, что процесс выполнения нескольких загрузок может быть отображён в одном окне, даже если они запущены разными программами. </para>
<para
>Служба DCOP объявляется указанием не библиотеки, как в прошлом случае, а имени приложения. Также, службы DCOP не указывают ServiceType, т.к. они обычно запускаются явным указанием их имени. Дополнительные свойства занимают две строки: </para>
> говорит о невозможности запуска нескольких экземпляров этой службы. Это значит, что если вы попытаетесь запуститьэту службу (например, через <ulink url="kdeapi:tdecore/TDEApplication.html#startServiceByName"
>, и KDE обнаружит, что такая служба уже зарегистрирована в, то будет использована уже запущенная копия службы. В этом случае она должна быть реализована как <ulink url="kdeapi:tdecore/KUniqueApplication.html"
> говорит, что одновременно можно запускать несколько экземпляров службы, так что каждая попытка запустить её приведёт к новому запуску. Значение <literal
>None</literal
> говорит о необходимости немедленного запуска службы. </para>
if (!client->call("kio_uiserver", "UIServer", "setListMode(bool)",
data, replyType, replyData))
cout << "Call to kio_uiserver failed" << endl;
...
</programlisting>
<para
>Обратите внимание, что пример вызова DCOP использует явное приведение аргументов. Чаще вам придётся использовать заглушку (stub), созданную dcopidl2cpp, т.к. это намного проще и меньше подвержено ошибкам. </para>
<para
>В пиведенном примере, служба была запущена по имени ("by name"), т.е. первым аргументом <function
>, которому передаётся имя файла .desktop, например <literal
>"kio_uiserver.desktop"</literal
>. </para>
<para
>Все эти вызовы берут список URL вторым аргументом. Третий аргумент - указатель на <classname
>QString</classname
>. Если произойдёт ошибка, в это строку будет занесено (локализованное) сообщение об ошибке. </para>
</simplesect>
</sect1>
<sect1 id="components-mime">
<title
>MIME-типы</title>
<simplesect id="mime-whataremimetypes">
<title
>Что такое тип MIME?</title>
<para
>MIME- используются для описания типа содержимого файлов или потоков данных. Изначально они были введены для отправки изображений или звуковых файлов по e-mail (MIME расшифровывается как "Multipurpose Internet Mail Extensions"). Позднее, эта система также была использована в веб-браузерах для определения как обрабатывать данные, посылаемые веб-сервером. Например, HTML-страница имеет тип MIME "text/html", файл Postscript - "application/postscript". В KDE, эта идея используется повсеместно: </para>
<itemizedlist>
<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>
</itemizedlist>
<para
>С приведённых выше примеров видно, что работа с MIME - достаточно сложная задача. Сначала, нужно установить соответствие между маской файла и типом MIME. KDE позволяет определить тип MIME не только по имени файла, а и по его содержимому, для случаев когда имя файла недоступно, или оно без расширения. Далее, необходимо установить связи между MIME-типами и программами или библиотеками, позволяющими обрабатывать их. </para>
<para
>Существует большое разнообразие API для установления типа MIME данных или файлов. В общем случае, вам придётся выбирать между скоростью и достоверностью. Вы можете определить тип файла только из его расширения. Например, файл с именем <filename
>foo.jpg</filename
> скорее всего имеет тип "image/jpeg". Если же файл не имеет расширения, его тип придётся определять по его содержимому. Естественно, это занимает больше времени, особенно для удалённых файлов. Такой метод основывается на файле <filename
> в нём не нужна, т.к. перевод комментариев производится другим образом (через .po-файлы, находящиеся в модуле CVS tde-i18n/ru/<пакет>/desktop_<имя>.po). <filename
>Самый быстрый метод определения типа файла - <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");
if (type->name() == KMimeType::defaultMimeType())
cout << "Could not find out type" << endl;
cout << "Could not find out type" << endl;
else
cout << "Type: " << type << endl;
</programlisting>
<para
>Это приводит к загрузке части файла через KIO и его проверке. Помните, что это занимает некоторое время и блокирует программу. Используйте это только если <function
>KMimeType::findByURL()</function
> вернуло <literal
>"application/octet-stream"</literal
>. </para>
<para
>Чтобы избежать блокирования программы, можно явно запустить KIO-задание и соединить слот с одним из его сигналов: </para>
>Установка связи MIME-типа с приложением или службой</title>
<para
>При установке приложения, или компоненты наподобие KPart , также устанавливается и файл <literal
>.desktop</literal
>, содержащий список MIME-типов, которые оно может обрабатывать. Получить список программ и служб, обрабатывающих данный MIME-тип, можно через класс <classname
>Во время world wide web, программы должны иметь доступ к ресурсам сети - загружать файлы, передавать какие-либо данные. возможность получать доступ к файлам вне зависимости от их расположения называется <emphasis
>сетевая прозрачность</emphasis
> (<emphasis
>network transparency</emphasis
>). </para>
<para
>В прошлом было несколько попыток реализации этого. Старая файловая система NFS - одна из таких попыток на уровне POSIX API. Она приемлемо работала в локальных, тесно связанных сетях, но оказалась немасштабируемой до современных технологий. Здесь важна <emphasis
>асинхронность</emphasis
>. Пока вы ждёте загрузки страницы в вашем веб-браузере, пользовательский интерфейс не должен блокироваться. Также, прорисовка страниц не должна начинаться только после полной загрузки, а выполняться по мере поступления данных. </para>
<para
>В библиотеках KDE, сетевая прозрачность реализована в KIO API. Основная идея этой архитектуры - <emphasis
>задание</emphasis
> (<emphasis
>job</emphasis
>) ввода/вывода (IO - input/output). Задание может копировать, удалять, перемещать файлы и т.п. После запуска, задание работает в фоновом режиме и не блокирует приложение. Сообщение между заданием и приложением - например передача данных о степени выполнения - выполняется интегрировано с циклом событий Qt. </para>
<para
>Фоновые операции выполняются с помощью <emphasis
>ioslaves</emphasis
>. Они запускаются как отдельный процесс соединяются через доменные сокеты UNIX. Таким образом не требуется, многопотоковость и сбой slave'а не приведёт к сбою приложений, использующих его. </para>
>Расположение файла определяется URL. Вего начале пишется tdeioslave, обрабатывающий протокол, по которому доступен файл. Например, это может быть file, http, tar и т.д. Напримерфайл из архива tar, находящегося на http-сервере может иметь URL </para>
>В большинстве случаев, задания создаются вызовом функций в пространстве имён KIO. Эти функции берут один или два URL как аргумент, и другое. После окончания задания, посылается сигнал <literal
>Информация о файле - размер, время изменения, права доступа. Информацию можно получить из TDEIO::StatJob::statResult() после завершения задания. </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>
>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_URL (string) - URL файла. </para
></listitem>
<listitem
><para
>UDS_MIME_TYPE (string) - MIME-тип файла </para
></listitem>
<listitem
><para
>UDS_GUESSED_MIME_TYPE (string) - MIME-тип файла, по предположению slave. В отличие от предыдущего, не всегда точный (т.к. в некоторых случаях точное определение типа требует больших затрат ресурсов). Например, класс KRun явно проверяет MIME-тип только если он не располагает точной информацией. </para
></listitem>
</itemizedlist>
<para
>Не смотря на всю гибкость хранения информации в <classname
>UDSEntry</classname
>, для программиста это всё же составляет некоторые трудности (задержки во времени реализации). Например, чтобы определить MIME-тип файла, вам нужно итерировать по всем атомам и проверить является ли <literal
>m_uds</literal
> <literal
>UDS_MIME_TYPE</literal
>. к счастью, существует более простой API: класс <classname
>Часто, асинхронное API KIO слишком сложное для использования, и асинхронность не всегда важна. Например, в программе, которая может работать только с одним документом в одно время, можно сделать немногое в время загрузки файла. Для таких простых случаев, вы можете воспользоваться функциями класса TDEIO::NetAccess. Например, чтобы скопировать файл: </para>
>Функция возвратится после выполнения задания. Будет показана информация о прогрессе, а программа всё равно будет получать события прорисовки. </para>
<para
>Некоторый интерес также представляет комбинация функций <function
>removeTempFile()</function
> и <function
>download()</function
>. Последняя загружает файл по заданному URL и сохраняет его во временный файл с уникальным именем. Имя файла сохраняется во второй аргумент. <emphasis
>Если</emphasis
> URL ссылается на локальный файл, второй аргумент содержит локальное имя файла. Функция<function
>removeTempFile()</function
>удаляет файл если он получился в результате загрузки. Вот заготовка кода для загрузки файла не смотря на его положение: </para>
>Интерфейс к заданиям KIO достаточно абстрактный. При создании задания, вы можете добавить метаданные к нему. Каждый элемент метаданных состоит из пары ключ-значение. Например, чтобы указать HTTP-slave не использовать кэш при загрузке страницы: </para>
>Используя KIO API, вам не нужно разбираться в подробностях запуска IO slave'ов и связи с ними. Чаще всего нужно просто запустить задание и обрабатывать посылаемые им сигналы. </para>
<para
>На самом деле, за занавесками всё намного сложнее. При создании задания оно помещается в очередь, когда приложение возвращается в главный цикл событий, KIO создаёт процессы slave для заданий в очереди. После завершения работы, задание не уничтожается, а находится в "подвешенном состоянии" около 3 минут - на случай если поступит запрос на новое задание с теми же протоколом и узлом. </para>
<para
>Если slave'ы запускаются по мере поступления запросов (т.е. параллельно), эта схема называется <emphasis
>прямой</emphasis
>. Это не всегда приемлемо т.к. требует дополнительных затрат памяти. </para>
<para
>Чтобы избежать этого, можно воспользоваться <emphasis
>расписанием</emphasis
> (<emphasis
>schedule</emphasis
>) заданий. При этом одновременно может выполняться только ограниченное число заданий (сейчас это 3). Следующие задания будут ставиться в очередь: </para>
>. Например, для IMAP slave, не имеет смысла запускать несколько процессов для одного сервера. Поэтому нельзя запускать несколько заданий к одному серверу. Это можно сделать с помощью TDEIO::Scheduler: </para>
>После запуска такого задания, гарантируется, что они выполнятся полностью. </para>
</simplesect>
<simplesect id="nettransparency-definingslaves">
<title
>Добавление ioslave</title>
<para
>Далее мы обсудим процесс создания ioslave. По аналогии со службами, установка заключается в написании небольшого конфигурационного файла. Следующая заготовка Makefile.am устанавливает протокол ftp: </para>
>Строки "input" "output" не используются на данный момент. </para>
<para
>Оставшиеся строки в файле <literal
>.protocol</literal
> определяют возможности slave'а. Последние обычно намного проще, чем KIO API. Например, чтобы получить рекурсивный листинг каталога, запускается задание для сканирования верхнего каталога, затем для каждого подкаталога запускается ещё одно, отдельное, задание. При этом существует ограничение на количество одновременно запущенных заданий. Аналогично, чтобы скопировать файл с протоколом, не поддерживающим это напрямую, (например<literal
>ftp:</literal
>), KIO читает файл и передаёт его по назначению. </para>
<para
>Т.к. slave' загружаются в виде совместно используемых библиотек, но действуют отдельно, их структура исходных файлов немного отличается от структуры обычной библиотеки. Функция, вызываемая для запуска называется <function
>kdemain()</function
>. В ней обычно выполняются некоторые инициализации, а затем она входит в цикл событий: </para>
<programlisting
>extern "C" { int kdemain(int argc, char **argv); }
>Для slave'ов, реализующих сетевые протоколы, нужно реализовать функцию <function
>SlaveBase::setHost()</function
>. Она вызывается для передачи имени узла, порта, имени пользователя и пароля. Вообще, метаданные, предоставляемые приложением, можно получить с помощью <function
>SlaveBase::metaData()</function
>. Наличие их можно определить функцией <function
>SlaveBase::hasMetaData()</function
>. </para>
</simplesect>
<simplesect id="nettransparency-communication">
<title
>Обратная связь с приложением</title>
<itemizedlist>
<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
> могут предоставлять информацию о процессе выполнения с помощью методов <function
>totalSize()</function
>, <function
>processedSize()</function
>, <function
>speed()</function
>. Общий и выполненный размеры передаются в байтах, скорость - в байтах в секунду. </para
></listitem>
<listitem
><para
>Вы можете посылать произвольные пары ключ-значение с помощью <function
>setMetaData()</function
>. </para
></listitem>
</itemizedlist>
</simplesect>
<simplesect id="nettransparency-interacting">
<title
>Взаимодействие с пользователем</title>
<para
>Иногда slave должен взаимодействовать с пользователем. Это может быть в виде информационных сообщений, диалогов авторизации и подтверждения замены файла. </para>
<itemizedlist>
<listitem
><para
><function
>infoMessage()</function
> - информационное сообщение, такое как "Retrieving data from <host>" http slave'а, обычно отображаемое в панели состояния. На стороне приложения, этот метод отвечает сигналу <function
