ArcaOS 5.0 Русская версия Пакет русификации ArcaOS 5.0 OS/2 давно доступен. Поддерживается любая версия: 5.0, 5.0.1, 5.0.2. eCo Software может выпустить и другие пакеты (Немецкий, Голландский, Бразильский Португальский, Испанский, Шведский и т.д.)

TITLE: Идеальная eComStation -- Skinning

DATE: 2008-04-11 17:35:45

AUTHOR: Eugene Evstigneev

Eugene Evstigneev предлагает разработчикам реализовать скиннинг для рабочего стола eComStation.

1. Аксиомы

• [A1] файл описания скина должен быть в формате XML;
• [A2] скин должен содержать только декларативную часть; вся функциональность должна реализовываться внутри класса окна;
• [A3] для обеспечения максимальной скорости работы резолвинг методов и переменных (в случае реализации на SOM) и парсинг должны производиться только при смене параметров отображения;
• [A4] перечень графических примитивов для использования в скиннинге не должен быть искуственно ограничен;
• [A5] механизм должен быть абстрагирован от любого конкретного класса окна и готов для использования как со всеми системными классами, так и с пользовательскими;
• [A6] механизм должен предусматривать возможность определения скина как для класса целиком, так и для отдельно взятого окна;
• [A7] перечень настраиваемых параметров для скина не должен быть фиксированным, и должен определяться каждым скином отдельно;
• [A8] должна быть возможность определения разных вариантов отображения для разных состояний одного и того же элемента;
• [A9] новый механизм отображения не должен ухудшать возможности по управлению внешним видом системы по сравнению с имеющимимся механизмом;
• [A10] в описании скина не должно содержаться формул и прочих выражений, интерпретируемых на стадии отрисовки;
• [A11] окно должно сохранять возможность визуализироваться даже в отсутствии скина и при критических ошибках в механизме скиннинга.

2. Промежуточные структуры и API - контекстные переменные

Контекстные переменные - это переменные, существующие в контексте определенного окна. Особенности переменных:

• контекстные переменные могут произвольно удаляться и добавляться в контекст;
• контекстные переменные могут быть наследуемыми, где наследование осуществляется от родительского окна по отношению к текущему;
• к контекстным переменным привязаны атрибуты, определяющие статус переменной.

Работа с контекстными переменными должна быть реализована как базовая возможность системы, не привязанная к скиннингу, но необходимая для этого.

При реализации скиннинга в контекстных переменных должны храниться такие данные, как состояние окна (нажата/не нажата для кнопок; активно/не активно для фрейма; курсор на контролом/не над контролом и т.п.) для [A8], так и его визуальные параметры (шрифт, цвет и т.п.). Контекстные переменные должны функционально заменить presparams. Для усовершенствования текущей возможности drag-n-drop цветов и шрифтов на контролы ([A9]) необходимо предопределить 3 контекстных переменных для хранения шрифта, цвета фона и цвета переднего плана. Наличие этих трех предопределенных переменных снимет необходимость в самостоятельной обработке событий при перетаскивании цветов и шрифтов на элемент управления (окно), однако это не должно мешать самостоятельной обработке этих событий окном, если в этом возникнет необходимость.

Переменные должны быть доступны для использования в описании скина.

Для быстрого сохранения и восстановления состояния окна должно быть предусмотрено API для работы с блоком контекстных переменных, оперативной единицой для которого должен быть блок переменных заданного контекста, определенный парой указатель/размер. Этот блок в зависимости от заданных параметров может включать, а может и не включать переменные всех дочерних окон.

3. Промежуточные структуры и API - XML-парсер

Парсер должен быть реализован в соответствии с рекомендацией XML 1.0 W3C. Парсер должен генерировать бинарное дерево в заранее заданном формате для его последующей обработки для обеспечения [A3].

Непосредственно отрисовка должна осуществляться по полученному дереву без дополнительного парсинга и резолвинга.

4. Графические примитивы

Графический примитив - это базовый элемент отображения. В общем понимании - это процедура, которая на основе входных параметров осуществляет некоторый вывод в заданный presentation space. В интерфейсе примитива должна быть определена процедура "Paint", осуществляющая непосредственно отрисовку в presentation space, указатель на который должен передаваться в качестве входного параметра. В параметрах должны также присутствовать некоторые наиболее общеупотребимые переменные для наиболее быстрой обработки входных данных ([A3]). Среди входных параметров должны присутствовать:

• x-координата области отрисовки;
• y-координата области отрисовки;
• ширина области отрисовки;
• высота области отрисовки;
• отступ от левого края области отрисовки (padding-left) (для [A10]);
• отступ от правого края области отрисовки (padding-right) (для [A10]);
• отступ от нижнего края области отрисовки (padding-bottom) (для [A10]);
• отступ от верхнего края области отрисовки (padding-top) (для [A10]);
• выравнивание по горизонтали;
• выравнивание по вертикали;
• ссылка на текст;
• ссылка на изображение;
• цвет фона;
• цвет переднего плана;
• дополнительный цвет;
• шрифт;
• дополнительный параметр (предположительно, ULONG).

Учитывая возможность пользовательского расширения набора примитивов ([A4]), во входных параметрах должен присутствовать указатель на массив структур, содержащих пары "имя"-"значение" для всех прочих параметров, не попавших в число предопределенных, но которые, возможно, присутствуют в описании скина.

Кроме "Paint" должна присутствовать процедура "ConfigDlg", которая отображает диалог для визуальной настройки примитива, необходимый в случае реализации расширенного редактора схем.

Среди изначально определенных примитивов должны присутствовать:

• solid color;
• gradient;
• image;
• growable image;
• toned image;
• toned growable image;
• icon;
• text.

5. Описание скина

5.1. Физическое представление

В физическом понимании файл описания должен быть в формате XML ([A1]) и соответствовать требованиям well-formed документа и не быть отдельным документом ("Standalone Document Declaration"), т.е. объявление документа должно быть вида:

  <?xml version="1.0" standalone="no"?>

5.2. Логическое представление

5.2.1 Визуализация

Алгоритм отрисовка каждого элемента определяется последовательностью тегов, описывающих графические примитивы. Формат описания должен быть следующего вида:

 <primitive name="..">
    <parameter name=".." value=".." />
    ...
 </primitive>

..например:

 <primitive name="text">
    <parameter name="x" value="0" />
    <parameter name="y" value="0" />
    <parameter name="w" value="&cxv_w;" />
    <parameter name="h" value="&cxv_h;" />
    <parameter name="text" value="&cxv_text;" />
    <parameter name="color" value="&cxv_foregroundcolor;" />
    <parameter name="font" value="&cxv_font;" />
    <parameter name="x_shadow" value="1" />
    <parameter name="h_align" value="1" />
 </primitive>

..где тег "primitive" определяет вызов к процедуре "paint" примитива, имя которого определяется единственным атрибутом "name". Вложенные атрибуты "parameter" определяют набор значений, передаваемых в качестве входных параметров, где атрибут "name" определяет имя параметра, а "value" - значение. В соответствии с п.4, предопределенные параметры должны передаваться непосредственно в списке параметров, а все прочие в виде массива структур. Значения параметров могут быть заданы в виде констант, так и в виде ссылок на контекстные переменные, определенные в соответствии с форматом описания сущностей ("entity") спецификации XML.

Данный механизм снимает необходимость в структурах CCI, поскольку соответствие системного параметра отображения и его местоположения в элементе управления определяется описанием скина.

5.2.2. Идентификация

Принадлежность тегов описания примитивов к конкретному классу окна должна определяться тегом верхнего уровня "class" с единственным атрибутом "name", определяющий класс окна ([A5]).

Пример:

 <class name="pushbutton">
    <primitive>...</primitive>
    ...
 </class>

Кроме возможности задания визуализации для класса целиком, необходима возможность описания отображения для конкретного окна, определеямым его идентификатором ([A6]). В случае реализации скиннинга на классической модели PM, идентификатором может быть строка, возвращаемая процедурой окна, а в SOM это может быть имя объекта. Формат описания для конкретного окна должен быть слеующего формата:

 <window name="closebutton">
    <primitive>...</primitive>
    ...
 </window>

..где атрибут "name" тега "window" определяет идентификатор визуализируемого окна.

Наличие тегов <class> и <window> может порождать неоднозначности при выборе описания, когда для визуализируемого окна имеется как описание <window>, так и <class>. В этом случае приоритет должно иметь описание, содержащееся в теге <window>.

В конечном итоге файл описания скина должен содержать последовательность тегов <class> и <window>.

5.2.3. Условные секции

Формат скина должен допускать описания визуализации для различных состояний одного и того же элемента ([A8]). Такие состояния должны определяться контекстными переменными, значение которых должно поддерживаться в адекватном состоянии во время работы.

Предположительно (данный вариант не является окончательным), для проверки состояния какой-либо контекстной переменной могут быть использованы специальные теги следующего вида:

 <if-eq name="" value="">
    ...
 </if-eq>

..где атрибут "name" содержит имя (сущность) проверяемой переменной, "value" - значение. Имя тега определяет производимую операцию (в данном случае - равенство).

Состоянием элемента (окна) может определяться как его внутренним состоянием (кнопка нажата/отжата), так и действиями пользователя (курсор [не] над окном, hover). Примерное описание скина с условными секциями может выглядеть следующим образом:

 <class name="pushbutton">
 <!-- кнопка нажата -->
    <if-eq name="&pushed;" value="1">
       <primitive>..</primitive>
       ...
    </if-eq>
 <!-- кнопка отжата -->
    <if-eq name="&pushed;" value="0">
 <!-- курсор над кнопкой -->
       <if-eq name="&hover;" value="1">
          <primitive>..</primitive>
          ...
       </if-eq>
 <!-- курсор не над кнопкой -->
       <if-eq name="&hover;" value="0">
          <primitive>..</primitive>
          ...
       </if-eq>
    </if-eq>
 </class>

Открытая проблема - проверка необходимости в перерисовке элемента в зависимости от смены состояния контекстных переменных, используемых в условных секциях. Учитывая, что лишь немногие переменные могут присутствовать в условных секциях, перерисовка окна при изменении значения любой контекстной переменной может привести к значительным потерям производительности.

6. Иерархия

Учитывая возможность субклассирования пользователем класса окна для расширения его функциональности, для таких субклассированных окон в скине не будет содержаться никакого описания, соответствующего именно этому классу (кроме случаев, когда для субклассированного окна пользователем определен и скин). В этом случае должно выбираться описание, соответствующее вышестоящему классу в иерархии наследования. Допустим, для иерархии классов:

  Window
     Pushbutton
        MyPushbutton
        

описание визуализации имеется только для класса "Pushbutton". Для визуализации окна класса "MyPushbutton" должно использоваться описание класса "Pushbutton", как наиболее близкого по иерархии, имеющее описание.

7. Составные элементы управления

Многие элементы управления при едином идентификаторе окна имеют несколько активных областей, которые по-разному визуализируются и реагируют на действия пользователя. К таким элементам относятся полосы прокрутки, меню, списки, градусники и т.п. Для решения задачи можно выделить два решения. Первое предполагает фиксацию состояния активных областей в контекстных переменных. Суть второго - в присваивании каждой активной области реального или фиктивного класса окна, описания которых должны присутствовать в скине.

На примере полосы прокрутки, для описания всех составных элементов (кнопка вверх, кнопка вниз, движок) можно выделить 4 контекстных переменных - высота кнопок, координата верхней кнопки, координата движка, высота движка. Таким образом, описание визуализации для полосы пркрутки могло бы выглядеть таки образом:

 <!-- сама полоса -->
 <primitive name="solidcolor">
    <parameter name="x" value="0" />
    <parameter name="y" value="0" />
    <parameter name="w" value="&cxv_w;" />
    <parameter name="h" value="&cxv_h;" />
 </primitive>
 <!-- кнопка вниз -->
 <primitive name="solidcolor">
    <parameter name="x" value="0" />
    <parameter name="y" value="0" />
    <parameter name="w" value="&cxv_w;" />
 <!-- cxv_buttonh - переменная, содержащая высоту кнопки -->
    <parameter name="h" value="&cxv_buttonh;" />
 </primitive>
 <!-- кнопка вверх -->
 <primitive name="solidcolor">
    <parameter name="x" value="0" />
 <!-- cvx_buttony - переменная, содержащая y-координату кнопки "вверх" -->
    <parameter name="y" value="&cxv_buttony;" />
    <parameter name="w" value="&cxv_w;" />
 <!-- cvx_buttonh - переменная, содержащая высоту кнопки -->
    <parameter name="h" value="&cxv_buttonh;" />
 </primitive>
 <!-- движок -->
 <primitive name="solidcolor">
    <parameter name="x" value="0" />
 <!-- cvx_slidery - переменная, содержащая y-координату движка -->
    <parameter name="y" value="&cxv_slidery;" />
    <parameter name="w" value="&cxv_w;" />
 <!-- cvx_sliderh - переменная, содержащая высоту движка -->
    <parameter name="h" value="&cxv_sliderh;" />
 </primitive>

Недостаток метода - его непригодность для визуализации элементов, где количество активных областей непостоянно, например меню.

Выделение каждой активной области в отдельное окно со своим классом снимет эти ограничения, но раздует иерархию классов окон, и увеличит затраты опреративной памяти ввиду большого количество таких составных элементов. Как вариант решения последней проблемы - создание окон для активных областей только при непосредственном отображении элемента на экране, и их удаление при его скрытии. Как побочный эффект - уменьшенное время реакции при открытии и закрытии окна (например, меню).

Альтернативный вариант предполагает наличие в скине описания визуализации для каждой активной области как для отдельного класса окна, но при фактическом отсутствии такового. При этом отрисовка составного элемента будет состоять из последовательности вызовов к процедуре визуализации для каждой активной области с предварительной установкой контекстных переменных в нужные значения и подстановкой в качестве входного параметра функции визуализации фиктивного класса окна, отсутствующего в системе, но присутствующим в описании скина. Недостаток подхода - его непрозрачность.

8. Маска

На данный момент в системе имеются элементы, имеющие непрямоугольные активные области, к которым относится спиннер ("WC_SPINBUTTON"). Для их визуализации предлагается или переписать такие классы для ликвидации таких непрямоугольных областей, или введение в описание скина параметра, описывающего бинарную маску.

9. Настраиваемые параметры

Предлагаемая схема визуализация снимает необходимость в фиксированном наборе настраиваемых параметров. Любые цвета, шрифты и прочие параметры могут задаваться как в виде констант, так и в виде ссылок на контекстные переменные. Очевидно, что скин, в котором все визуальные параметры заданы в виде констант, лишен любых настроек, доступных в редакторе схем. В то же время, ничто не мешает задать все параметры в виде переменных, которые могут участвовать как в управлении параметрами визуализации, так и в качестве параметров в условных секциях. Учитывая отсутствие любых требований к таким параметрам со стороны системы, в описании схемы необходимо предусмотреть блок (возможно, отдельным файлом), содержащий описание имеющихся в схеме переменных, пригодное для использования в редакторе схем. Описания должны быть сгруппированы по описываемому классу или идентификатору окна, и содержать все параметры, необходмые для визуализации настройки в редакторе схем. Параметры должны содержать:

• вербализованное название переменной (возможно, на разных языках);
• тип переменной (цвет, картинка, шрифт, число, чекбокс, список и т.п.);
• значение по умолчанию.

Пример предлагаемого описания переменной:

 <!-- parameters.xml -->
 <sch:class name="pushbutton">
    <sch:name xml:lang="en">Push button</sch:name>
    <sch:name xml:lang="ru">Кнопка</sch:name>
    <sch:parameter value="cxv_backgroundcolor">
       <sch:name xml:lang="en">Button color</sch:name>
       <sch:name xml:lang="ru">Цвет кнопки</sch:name>
       <sch:type value="color" />
       <sch:value value="#808080" />
    </sch:parameter>
    <sch:parameter value="cxv_foregroundcolor">
       <sch:name xml:lang="en">Text color</sch:name>
       <sch:name xml:lang="ru">Цвет текста</sch:name>
       <sch:type value="color" />
       <sch:value value="#0" />
    </sch:parameter>
    ...
 </sch:class>

Здесь название переменной (значение атрибута "value" тега "parameter") должно задаваться _не_ в нотации сущности (entity). Описанные таким образом переменные могут быть установлены только для класса, внутри описания которого они были определены. Для описания переменных, используемых в секции "<window>" описания скина предлагается использовать тег "<sch:window>" вместо "<sch:class>". Определенные таким образом переменные по своей сути заменяют переменные SYSCLRs, имеющиеся в текущей модели PM. Для описания переменных вне контекста класса или окна предлагается использовать тег "<sch:section>" с форматом описания, аналогичным приведенному выше. Главное отличие переменных, описанных в секции "<sch:section>" от тех, которые описаны в "<sch:window>" и "<sch:class>" в том, что они существуют вне какого-либо контекста, и имеют силу на всем протяжении описания скина. В случае, когда переменные с одним и тем же именем определены в описаниях класса, окна и общей секции, приоритет распределяется следующим образом:

• 1. окно;
• 2. класс;
• 3. общая секция.

Предполагаемое применение секции "<sch:section>" - определение общих параметров схемы, не относящихся к определенному классу или окну, хотя формально область применения не ограничена. Таких внеконтекстных секций может быть несколько для возможности визуального разделения разнородных параметров в окне настройки схемы.

Определение переменной с одним и тем же именем несколько раз в пределах:

• одной секции "<sch:window>";
• одной секции "<sch:class>";
• всех секций "<sch:section>"

является ошибкой.

10. Схема реализации

Основную инфраструктуру скиннинга предлагается реализовать в виде функций и методов класса окна верхнего уровня (доступного через функцию WinDefWindowProc текущей версии PM). Стыковку новой инфраструктуры и имеющейся модели PM предлагается сделать в методе Paint (WM_PAINT), переопределенным в классе окна верхнего уровня. Общий алгоритм работы этого метода после переопределения должен выглядеть следующим образом:

 1. отрисовка скина для текущего окна
 2. если ошибка (например, скин для окна не определен), то
 3.   отрисовка скина для текущего класса окна
 4.   если ошибка (например, скин для класса не определен), то
 5.      если текущий класс окна равен классу верхнего уровня,
 5.         то возврат с ошибкой
 6.      определить класс, стоящий выше по иерархии, к п.3
 7. успешный возврат

Таким образом, алгоритм будет пригоден для использования в любых классах без модификации. Отсутствие непосредственной отрисовки окна объясняется тем, что алгоритм должен быть реализован в классе окна верхнего уровня, который является невизуализируемым. В производных (визуализируемых) классах алгоритм должен быть следующим:

• 1. вызов дефолтного обработчика
• 2. если ошибок нет, возврат
• 3. ручная отрисовка контрола

В п.1 произойдет отработка алгоритма, описанного выше, который визуализирует элемент на основе описания скина. Если визуализация прошла с ошибками, происходит прямая отрисовка элемента на экране по имеющимся текущим алгоритмам, не связанных с механизмом скиннинга. Этот алгоритм позволит сохранить работоспособность пользовательского интерфейса даже при критических ошибках в механизме скиннинга, произошедших как из-за ошибок в реализации скиннинга, так и из-за пользовательских ошибок (неправильный скин, отсутствие скинов, эксперименты над системой и т.п.) ([A11]).

Комментарии:

arec 2008-04-15 03:17:02	Пусть eComStation объединиться с проектом ReactOS вот будет выгодное сотруничество в плане всего .... а -то как в люнуксе кто в лес кто по дрова ... а всем нужно одно и тоже только у каждого свои методы а вместе бут эфективнее ....
Sergey Posokhov 2008-04-15 12:25:27	А я вот не согласен :-) Нужен язык, подобный Rexx, позволяющий описать любое окнище, в том числе меню и даже PM123. Его компилировать в код на Си и Паскакале. Слабо?

Прокомментируйте эту статью (напоминаем, автор работал над текстом несколько недель, уважайте мнение других).

Ваше имя: Ваш E-Mail: CODE:
Ваш комментарий:

eComStation 2.0 создана для работы на современных компьютерах (i3/i5/i7, Core Duo, AMD X2), но будет работать и на компьютерах, купленных 5 лет назад. Что нового в eCS 2.0?