articles/true_unix_gui_2_0.html

   1 <HTML><HEAD>
   2 <META HTTP-EQUIV="Content-Type" "text/html; charset=utf-8">
   3 <TITLE>True Unix GUI 2.0</TITLE>
   4 <META NAME="description" CONTENT="Проект устройства GUI среды в стиле
   5 Unix отталкиваясь от реалий 2009 года">
   6 </HEAD><BODY>
   7 <H1>True Unix GUI 2.0</H1>
   8 <p>Когда-то давно я написал статью <a href="true_unix_gui.html">True Unix
   9 GUI</a> по поводу того, как же должен быть устроен интерфейс
  10 пользователя для того, чтобы сохранить все достоинства командной строки
  11 Unix, но при этом максимально поддержать решение тех задач, которые
  12 стоят перед современным пользователем.</p>
  13 <p>Идеи, изложенные там, пока остаются на уровне благих пожеланий.</p>
  14 <p>Сейчас попробую решить более простую задачу - описать, как может быть
  15 устроена консистентная по интерфейсу система приложений для unix,
  16 лишенная основных недостатков существующих desktop environments -
  17 нестабильности, сложности в программировании etc.
  18 <h2>Бэкграунд</h2>
  19 <p>
  20 Чего хочет от интерфейса компьютерной системы пользователь? Насколько я
  21 понимаю, прежде всего он хочет, чтобы его не заставляли думать. Если
  22 какие-то действия повторяются достаточно часто, чтобы они превратились в
  23 пальцевые привычки, например, открытие файла через стандартный диалог,
  24 или клик правой кнопкой, они должны работать независимо от того, с каким
  25 приложением пользователь сейчас работает. То есть интерфейс должен быть
  26 консистентным. И хотим мы этого или нет, эти привычки сформированы в
  27 рамках CUA-парадигмы интерфейса
  28 </p>
  29 <p>Сейчас это в основном достигается путем убирания этих
  30 функций в развесистые библиотеки интерфейсных тулкитов.
  31 </p>
  32 <p>
  33 Тулкиты получаются большими, API развесистыми, развитие приводит к
  34 нарушению обратной совместимости и т.д. Более-менее приличных
  35 результатов на этом пути удается добиться только большим коммерческим
  36 фирмам вроде Apple и Microsoft, которые могут себе позволить затраты на
  37 Q&amp;A, превышающие затраты на разработку, могут выставлять жесткие
  38 требования к 3-rd party разработчикам и т.д. И все равно получается
  39 плохо.
  40 <p>В мире OpenSource все еще хуже. Нельзя заставить независимого
  41 разработчика соблюдать HIG, если этот HIG ему не нравится.</p>
  42 <P>Независимые разработчики, это как правило, люди с более сложными
  43 привычками, чем простые пользователи. Серьезного разработчика не устроит
  44 в качестве редактора pico или mcedit - ему подавай vim или emacs с
  45 совершенно ужасными для простого пользователя клавишными командами. Зато
  46 мощный и удобный для пользователя привычного.</p>
  47 <p>Еще хорошему разработчику нужно понимать, что делает тот кусок софта,
  48 который он разрабатывает. А когда этот кусок софта зависит от кучи
  49 библиотек, да эти библиотеки по собственной инициативе плодят потоки
  50 выполнения, да взаимодействуют не слишком документированным образом с
  51 прочими компонентами системы, картину мира приходится ограничивать
  52 искусственно. В результате возникают такие вещи как "я тут нашел
  53 замечательный framework, я правда в нем нифига не разобрался, но
  54 смотрите как здорово получилось". Для меня подобное заявление
  55 разработчика - однозначный show-stopper. Использовать такую программу
  56 нельзя. Но других-то нет. Писать надежные программы почти что
  57 разучились. А пользователь хочет фич. </p>
  58 <p>По-моему, в конце первого десятилетия XXI века стремление ко
  59 множеству фич - атавизм, подбный неконтролируемой любви некоторых
  60 приматов к соли. Прошли давно те времена, когда в типичном местообитании
  61 приматов соли был дефицит. Её давно уже научились добывать и из моря, и
  62 из земли в любых требуемых количествах. Но вот отвыкнуть солить все
  63 подряд мы не можем. Биология так быстро не перестраивается</p>
  64 <p>Так же и с фичами. Как правило, типичный пользователь не знает всех
  65 возможностей тех программ, которыми он пользуется. Возникает новая
  66 задача, ставится вопрос не &laquo;Как решить эту задачу уже знакомыми
  67 инструментами&raquo; (в большинстве случаев на этот вопрос есть
  68 осмысленный ответ), а &laquo;Где бы нарыть такую программу, которая
  69 делает все что мне надо и еще немножко&raquo;. Программы рассматриваются
  70 не как инструменты, а как этакие магические даже не заклинания, а
  71 артефакты, вроде скатерти-самобранки.
  72 </p>
  73 <p>А все потому, что написать программу с более-менее стандартным GUI -
  74 сложно. Это вам не двухстрочный shell-скрипт. В типичном интерфейсном
  75 тулките даже тривиальное окошко с менюшкой из пяти позиций и парой
  76 стандартных диалогов сделать - на экран не влезет.
  77 </p>
  78 <p>Надо как-то эту ситуацию менять</p>
  79 <h2>Требования</h2>
  80 <ol>
  81 <li>Максимальная независимость всех  компонент. С одной
  82 стороны должна быть возможность обработать практически любую ошибку и не
  83 потерять пользовательских данных, с другой - если мне не нравится диалог
  84 открытия файлов, я должен иметь возможность заменить его на более другой
  85 (благо в дистрибутиве их полно разных) без перекомпиляции (и тем более,
  86 переписывания) всех программ, которыми я пользуюсь.
  87 <li>Наличие одного решения для каждой задачи. Если посмотреть сколько
  88 реализаций протокола HTTP есть в типичной пользовательской системе -
  89 можно прийти в ужас. Нет, я не против того, чтобы в дистрибутиве были
  90 несколько реализаций, чтобы я мог выбрать наиболее меня устраивающую,
  91 или даже установленных одновременно, чтобы выбирать можно было в момент
  92 использования. Но вот нет - та или иная реализация намертво встроена в
  93 каждую программу или библиотеку языка программирования.
  94 <li>Возможность писать на любом языке программирования. Современный
  95 подход приводит к тому, что большая часть функциональности реализована в
  96 виде стандартных библиотек с интерфейсом языка C или C++. Встроить эти
  97 библиотеки в более высокоуровневый язык не всегда тривиально, особенно
  98 если речь идет о языке, уже имеющем свои представления о цикле обработки
  99 событий и менеджмете памяти.
 100 <li>Сетевая прозрачность. Как правило, в Unix используется какой-нибудь
 101 протокол удаленного выполнения команд, например ssh, который позволяет
 102 вполне естественным образом выполнять программу (в том числе и имеющую
 103 GUI) на удаленной машине, получая её результаты на локальный дисплей.
 104 Как правило, этот протокол имеет еще и удобные встроенные средства
 105 авторизации. Тем не менее, почти никогда, кроме некоторых продвинутых
 106 imap-клиентов, эта возможность не используется для доступа к данным
 107 хранящимся на удаленной машине - используется прямое TCP-соединение, у
 108 которого могут быть проблемы с файрволлами, требуется отдельная
 109 авторизация (а про ident-протокол в наше время можно смело забыть).
 110 <li>Виртуальная файловая система. То что файлы могут лежать не только в
 111 локальной файловой системе, но и в удаленной, доступной либо по
 112 протоколу выполнения команд, либо по протоколу сетевой файловой системы,
 113 на каком-нибудь мобильном устройстве, в архиве, на съемном носителе etc,
 114 знают все. Но ситуация с VFS оставляет желать лучшего.
 115 <li>Понятие логической консоли. Когда-то давно, все чем располагал
 116 пользователь для обмена информацией с компьютером, было дисплей,
 117 клавиатура да мышь. Именно этот набор устройств поддерживает в норме
 118 протокол X11 (хотя там понятие <i>позиционирующего устройства</i>
 119 несколько шире, чем &laquo;мышь&raquo;). В современных условиях это
 120 давно не так. Во-первых, есть микрофон  и колонки. И где бы пользователь
 121 не запустил программу, работать она должна ровно с теми колонками,
 122 которые расположены рядом (или вообще вмонтированы в) дисплеем этого
 123 пользователя. Во-вторых, есть сканеры, цифровые фотоаппараты,
 124 веб-камеры, и прочие источники данных, которые как-то связаны с
 125 физическим расположением пользователя. Есть еще и съемные носители,
 126 которые не только источник данных, и их получатель. И тоже находятся там
 127 же, где и пользователь. Впрочем, съемный носитель - частный случай
 128 виртуальной файловой системы
 129 </li>
 130 <h2>Архитектура</h2>
 131 <p>
 132 Поскольку внизу у нас таки Unix, архитектуру следует основывать на том,
 133 что Unix умеет хорошо, на том что описано во всех книжках по
 134 программированию. Это - командная строка и пайпы.
 135 </p>
 136 <p>Мощность современных компьютеров весьма велика. И зачастую запуск
 137 отдельного процесса является допустимым оверхедом для любой
 138 интерактивной операции. В конце концов, это было допустимым оверхедом во
 139 времена Кернигана и Пайка, когда компьютеры были гораздо слабее.
 140 Конечно, запуск современной программы с кучей библиотек, встроенными
 141 интерпретаторами et cetera, et cetera обходится гораздо дороже, чем
 142 запуск утилиты cat, но кто сказал, что компоненты выполняющие
 143 стандартные фунции должны быть &laquo;современными программами&raquo; в
 144 этом смысле слова?
 145 </p>
 146 <p>
 147 Если предположить, что нам не жалко породить отдельный GUI-процесс для
 148 операции выбора открываемого файла, то в программе вызов этого диалога
 149 будет выглядеть как
 150 <pre>
 151 f=popen("filedialog","r");
 152 fgets(f,filename,sizeof(filename);
 153 pclose(f);
 154 </pre>
 155 Исполняемый файл filedialog может быть либо
 156 <pre>
 157 #!/bin/sh
 158 exec zenity --file-dialog
 159 </pre>
 160 либо
 161 <pre>
 162 #!/usr/bin/wish
 163 puts [tkGetOpenFile]
 164 </pre>
 165 это уж как вам больше нравится. Управлять набором подобных утилит можно
 166 либо с помощью механизма аналогичного дебиановским alternatives, либо
 167 с помощью специального каталога в ${HOME}, например ~/components, где
 168 лежат симлинки или скрипты, делающие то, что нравится текущему
 169 пользователю.
 170 </p>
 171 <p>
 172 Вот поменяли одну  симлинку, и сразу ВО ВСЕХ программах изменился диалог
 173 открытия файлов. Независимо от того, какую GUI-библиотеку использует
 174 сама программа.
 175 </p>
 176 <p>
 177 А если вы пользуетесь каким-нибудь продвинутым файл-менеджером, который
 178 много чего умеет, ваш скрипт filedialog может пообщаться с этим
 179 файлменеджером (через unix-domain socket, через X-овый ICCCM, как
 180 угодно) и открыть его панель со всеми его возможностями.
 181 </p>
 182 <p>Как реализовать таким же образом progress-bar см в той же zenity.
 183 </p>
 184 <p>А ведь можно вынести в подобного рода компоненты и более сложные
 185 операции. Поиск по тексту, например. Основная программа выдирает из
 186 своего формата данных искабельный текст, и скармливает компоненту,
 187 который возвращает "найдено/не найдено" (а если найдено, то смещение от
 188 последнего блока текста). В результате, с каким бы форматом данных мы не
 189 работали, хоть с html, хоть postscript, диалоговое окно поиска имеет
 190 одинаковые опции, поддерживает одинаковый синтаксис регулярных выражений
 191 etc.
 192 </p>
 193 <p>
 194 Еще можно оторвать от приложений систему главного меню, вынеся её в
 195 отдельную программу. Здесь, пожалуй, пайпы будут не самым удобным
 196 механизмом межпроцессной коммуникации, лучше использовать передачу
 197 событий X11, но зато эта конструкция позволяет полноценно реализовать
 198 интерфейсную парадигму МакОС, где меню не вверху окна, а в верху экрана.
 199 Это очень удобно, потому что для того, чтобы попасть мышью в верхнюю
 200 строчку экран, не надо прицеливаться. Просто резко дергаешь руку вверх,
 201 мимо границы экрана не промахнешься. А можно не реализовывать. В такой
 202 концепции создание меню приложений - функция window manager-а, а тот уж
 203 может выбирать, рисовать меню в верхней строке или в рамке текущего
 204 окна. Ему доступно и то, и другое.
 205 </p>
 206 <p>В результате получается, что приложение собственно, тоже превращается
 207 в компонент. Оно распоряжается только основным полем своего окна,
 208 обрабатывает команды, приходящие в виде горячих клавиш и событий,
 209 сгенерированных менеджером меню. А такие приложения можно, используя
 210 X-овый механизм reparenting всячески комбинировать между собой.
 211 </p>
 212 <p>Дабы не изобреть велосипедов, вспомним, что у Xt-приложений есть
 213 замечательный ресурс translations, который позволяет связывать
 214 прикладные функции  с клавиатурными событиями. На уровне
 215 пользовательской, per-display, per-site или per-application
 216 конфигурации. Аналогичным образом должны обрабатываться и события от
 217 менеджера меню.
 218
 219
 220
 221 </ol>
 222
 223
 224
 225
 226 </BODY>
 227 </HTML>