НОВОЕ: OS/2 GURU - Вопросы и ответы

Наверняка, многие из тех, кто написал хотя бы одну shareware- или freeware-программу задумывался о том, чтобы его творение, которое могло бы быть весьма полезно человечеству, выглядело подобающе. Хотя есть разработчики, считающие, что не важно, как выглядит программа, "лишь бы работала". Утверждение вполне справедливо для программ, работающих в консольном режиме, все взаимодействие с которыми происходит через интерфейс командной строки. Однако, это правило довольно часто применяется во многих приложениях, работающих в графическом режиме. Мотивации здесь две: это сделано из принципа ("вам шашечки или ехать?"), или разработчик просто считает себя некомпетентным в области дизайна интерфейсов, и старается этим вообще не заниматься.

Данная статья написана специально для тех, кто занимается разработкой программ для OS/2 (eComStation), поэтому стоит остановится на деталях работы программ в данной среде.

К сожалению, для OS/2 нет общедоступного guidelines (спецификаций и рекомендаций) по проектированию интерфейсов (по крайней мере автор об его существовании не знает), поэтому довольно часто встречаются программы, в том числе и коммерческие, которые выглядят в OS/2 инородными, как по внешнему виду, так и по логике интерфейса. Здесь я попытался вывести общие рекомендации по оформлению программ, исходя как из общепринятых стандартов системы, так и из здравого смысла, которые помогут без излишних затрат придать программе более или менее приличный вид. Итак.

Блокнот настроек

Одна из самых малозаметных, но в то же время одна из самых грубых, ошибка, связанная с организацией логики взаимодействия с пользователем диалогов настроек. Речь идет о частом использовании в OS/2 набора кнопок "OK", "Cancel", "Apply" (или первых двух), стандартизированных всеми известной фирмой. Для пользователей, пришедших с другой операционной системы, или работающие в таковых большинство времени, ничего необычного в этом нет. Те же, кто почти все время работает в OS/2, при общении с такими диалогами испытывают дискомфорт, иногда переходящий в раздражение. Механизм, используемый в OS/2 и eComStation известен всем, кто хотя бы раз открывал стандартный диалог настройки, но я все же его озвучу.

Механизм предельно изящный: все эти три кнопки заменяет одна - "Undo" ("Отказ" в русской версии OS/2). Все изменения, производимые в таком диалоге вступают в силу сразу же, позволяя видеть в реальном масштабе результат настройки. Вернуть прежние значения настроек, причем без закрытия окна, можно нажатием на кнопку "Undo". Закрытие окна производится стандартным образом (крестиком в заголовке окна, если он имеется; двойным щелчком по системному меню; или же всем известной комбинацией Alt+F4). Отдельного упоминания заслуживает кнопка "Default", повсеместно используемая в OS/2, и отсутствующая в большинстве других ОС - она позволяет вернуть значения всех параметров настроек в то состояние, в котором они были в момент установки системы (программы), также без последующего закрытия окна. Очень часто возникает ситуация, когда не очень опытный пользователь, меняя параметры, заходит слишком далеко, и в результате частично или полностью теряется работоспособность настраиваемой компоненты. Обычно не предусматриваются никакие средства для отката всех значений в подобных ситуациях в некоторое "безопасное" состояние. Кнопка "Default", используйся она почаще, смогла бы сохранить большое количество нервов и времени.

Однако, есть случаи, когда использование кнопок "OK" и "Cancel" в диалогах настроек оправдано, например, если программа используется в realtime-системе, и неосторожное изменение некоторых настроек может повлиять на производственный процесс, или же активизация параметров настроек занимает значительное время.

Но все же, при разработке OS/2-программы, в диалогах настроек в первую очередь нужно использовать комбинацию "Undo"+"Default", и только если этот вариант по каким-то причинам не может быть применен, использовать "OK" и "Cancel". Но даже во втором случае будет крайне полезным наличие кнопки "Default".

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

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

Другой, более тяжелый случай, когда в обычном диалоговом окне в верхней его части в ряд по горизонтали располагаются обычные push buttons, при нажатии на которые меняется содержимое диалога. Таким образом симулируется работа блокнота. Такие случаи крайне редки, но они есть. Здесь я просто хотел бы предостеречь от подобных действий, которые иначе как издевательством над пользователем назвать нельзя.

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

Системные цвета

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

Если в программе используются только стандартные элементы управления, то здесь проблем, как правило, нет. Экран начинает пестреть, когда в программу добавляются элементы, стандартно в OS/2 отсутствующие: статус-строка, панель инструментов, progress bar и др. Не буду описывать, во что выливается подобная самодеятельность, опишу только некоторые рекомендации.

Главный критерий здесь - элемент не должен выбиваться из общей цветовой гаммы, а цветовая гамма - вещь переменная. К счастью, в OS/2 довольно простой механизм использования системных цветов. С точки зрения разработчика каждый цвет из текущей палитры цветов представлен константой, и приведение всего приложения к системной цветовой гамме не составляет большого труда. Как правило, вся работа сводится к простой замене в исходном коде всех упоминаний цветовых констант с префиксом CLR_* на соответствующую константу из набора System Colors с префиксом SYSCLR_*. Однако, четкого соответствия между чистым цветом и системным цветом нет. Замену следует производить исходя из семантики того или иного объекта, цвет которого предполагается поменять. К примеру, если у вас в программе реализована панель инструментов, то естественно предположить, что ее фон должен соответствовать фону окна рабочей программы, которому соответствует константа SYSCLR_APPWORKSPACE. Однако, фон элемента Progress Bar, как правило, должен соответствовать фону диалогового окна (константа SYSCLR_DIALOGBACKGROUND). В первую очередь нужно исходить из того, где будет использоваться такой элемент - в рабочем окне программы или в диалоговом окне. Как правило, их цвета совпадают в большинстве случаев, но в все же они семантически разделены. Гораздо сложнее, если элемент с одинаковой интенсивностью используется как в основном окне, так и в диалогах. Единственно правильное решение здесь - перед прорисовкой такого элемента управления определять цвет фона родительского окна, и использовать именно его.

Кратко опишу, в каких случаях какой системный цвет должен использоваться:

Фон элемента, работающего в основном окне программы	SYSCLR_APPWORKSPACE
Фон элемента, работающего в диалоговом окне	SYSCLR_DIALOGBACKGROUND
3D-окантовка, светлая часть	SYSCLR_BUTTONLIGHT
3D-окантовка, темная часть	SYSCLR_BUTTONDARK
Активная часть элемента (напр., бегунок в progress bar)	SYSCLR_ACTIVETITLE
Текст на элементе управления	SYSCLR_WINDOWTEXT (или SYSCLR_WINDOWSTATICTEXT, в зависимости от ситуации)

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

На этом можно было бы и закончить, если бы OS/2 не предлагала более развитые средства по оформлению программ. Речь о Presentation Parameters (PP).

Большинство разработчиков при оформлении программ могли бы ограничиться системными цветами, но для полного соответствия визуальным стандартам OS/2 все же необходимо ввести поддержку PP, хотя это и требует дополнительных затрат на кодирование.

С точки зрения пользователя, PP позволяют произвольно менять расцветку любого элемента программы путем простого перетаскивания нужного цвета или шрифта из соответствующей палитры на элемент управления.

Для программиста PP выглядит как массив, привязанный к каждому элементу управления, каждый элемент которого содержит цвет (или шрифт), используемый для прорисовки определенной области этого элемента. Для полноценной поддержки PP в программе необходимо реализовать механизм drag&drop для цветов и шрифтов из системных палитр. А для того, чтобы этот механизм был действительно полезным, а не игрушкой по типу "раскрась сам", нужно обеспечить сохранение PP для всех элементов при выходе из программы, с последующим их восстановлением при следующем запуске.

Растры

Отдельно стоит упомянуть использование в программах растровых изображений, применяемых для оформления элементов управления. По естественным причинам не может быть и речи об использовании в растрах System Colors.

Делается это по разным причинам - из желания выделиться из стандартного окружения, из необходимости реализовать элементы управления, стандартно в OS/2 отсутствующие, или же в программе должен присутствовать некоторый образ (например, логотип), не связанный с управлением программой.

Как правило, никакой разумной мотивации в собственной прорисовке стандартных элементов нет. Кроме того, что результат подобной самодеятельности не отличается эстетичностью (мало кто из разработчиков обладает художественными и дизайнерскими навыками), они еще по своей сути являются монолитами - любая модификация пользователем текущей схемы, или же смена визуальных стандартов операционной системы при выходе очередной версии, такой программы не коснется. По этой же причине ее нельзя будет назвать соответствующей визуальным стандартам OS/2. Единственное исключение здесь - механизм скиннинга, когда необходимость в собственной прорисовке диктуется самой сутью выбранной визуальной архитектуры. Скиннинг сейчас используется все чаще и чаще, однако это не всегда оправдано. В программах с достаточно развитым интерфейсом скиннинг только затрудняет взаимодействие с ней - адаптировавшись к стандартному интерфейсу операционной системы, пользователю будет трудно приспособиться к необычному внешнему виду программы, а иногда и к нестандартной логике интерфейса. Однако, есть класс программ, которые сегодня трудно представить без скиннинга - это всевозможные медиа-проигрыватели, tv- и fm-тюнеры, и т.п.

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

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

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

Однако, есть вид растров, не являющихся самодостаточными, и требующего поддержки со стороны фонового окружения. Это - монохромные растры, базирующиеся на сером цвете. Здесь вариантов не так много - или вообще отказаться от их использования, или же перед их выводом на экран программно тонировать цветом SYSCLR_APPWORKSPACE (или SYSCLR_DIALOGBACKGROUND), что довольно трудоемко.

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

Reviews / articles about OS/2

Ваше имя:

e-mail для связи:

Введите Anti-spam код

Какой товар вам нужен? (коротко)

Визуальные стандарты OS/2

Блокнот настроек

Системные цвета

Растры

ArcaOS 5.1.1 - DOS Опять работает

Panorama VESA видео драйвер для OS/2

Warpstock Europe 2017