[devel-distro] Очень простой конфигуратор

[Paul Wolneykien <manowar@altlinux.org>]

  Всем привет.

  В соседних обсуждениях по конфигуратору и инсталлятору был высказан
ряд тезисов:

  1. первоначально предполагалось появление консольного установщика
     (его порой [не хватает?]);
  2. в том числе и для безголовых (админов, хи-хи) серверов в
     датацентрах с COM-портом;
  3. нужна дружественность к людям с ограниченными возможностями;
  4. важен адаптивный интерфейс для устройств с маленьким экраном;
  5. если хочется, чтобы установщик или конфигуратор был не только
     в браузере, достаточно единой кодовой базы для интерфейсов
     фронтендов;
  6. эта база должна крайне медленно устаревать (вместо "не работает
     на вчерашнем браузере");
  7. и по-возможности быть декларативным (!) описанием фронтенда;
  8. юниксы вырвались вперёд на простоте, человекопостижимости;
  9. не должно быть экспоненциального роста сложности для развития
     и поддержки системы конфигурации;
 10. потребительские качества программы должны оцениваться с позиций
     потребностей высококультурного, воспитанного человека;
 11. ибо заботиться о людях --- не значит потакать их немощам, но
     помогать им преодолеть их.


  Хочу сказать, что по первому пункту имею некоторые наработки. Однажды
(судя по git это было 12 лет назад) на архитектурной базе нашего
альтератора был разработан ряд модулей для настройки сторонних
(и проприетарных) программ и, частично, для настройки базовой системы
Альт-СП в плане сети. Для последнего были заменены или дополнены
стандартные модули типа alterator-net-eth. Почему же это потребовалось?
Дело в том, что первым условием того заказа было... чтобы конфигуратор
работал в консоли.

  К сожалению, весь код целиком не сохранился. Но сохранилась
shell-обвязка вокруг woo, имитирующая alterator/woo на scheme [1],
а также вторая библиотека, непосредственно предназначенная для
построения текстовых диалоговых интерфейсов [2] на базе dialog(1).

  Сразу добавлю, что похвастаться в этом коде особенно не чем: я сейчас
поглядел, там eval на eval и eval погоняет; часть из них явно не нужна,
а остальные --- не санитизируются. Но речь на самом деле не об этом
конкретном коде. А о том, что когда-то существовал вполне рабочий
прототип из 5--7 модулей альтератора, построенных по диалоговому
принципу. Что показал данный эксперимент? Он показал и доказал
практически, что бэкенды на базе alterator/woo, написанные с оглядкой
на index.scm и index.html, могут быть использованы также с принципиально
иной структурой фронтенда, зажатого в узкие рамки таких категорий UI
как "двойственный выбор", "множественный выбор", "подтверждение или
отказ", "ввод данных" и --- главная особенность --- "уровень,
подуровень, под-подуровень, и т. д." (вместо одного сложного окна
дерево простых).

  Что тогда послужило отправной точкой? Кажется, для соседнего проекта
нужно было собирать кастомизированные ядра, а значит перед глазами
был диалоговый конфигуратор ядра. Было вполне логично реализовать
подобное на имеющейся базе alterator/woo + backend3. И это что-то
получилось: уж не знаю, благодаря данной архитектуре или же вопреки
ей.

  Что можно сказать о диалоговой структуре UI сегодня, в том контексте,
который определили соседние обсуждения по конфигуратору и инсталлятору?
Номера пунктов соответствуют тезисам в начале данного письма.

  Во-первых, она с лёгкостью покрывает пп. 1, 2, 3 и 4. В частности,
для п. 3, посредством замены dialog(1) альтернативной программой,
реализующей потоковое текстовое меню и добавлением TTS, получаем
настоящее голосовое меню, которое не нужно "табать" в поисках этих
странных кнопок из мира зрячих. Для реализации п. 4, опять же,
достаточно заменить саму dialog(1) на подходящую графическую реализацию
меню.

  Во-вторых, пп. 5--7. С ними тоже тут нет никаких проблем. Более того,
на действительно декларативном уровне я не могу представить ничего,
кроме описания кейсов вопрос-ответ. Любое другое "декларативное"
описание UI на проверку оказывается пустой рекламной декларацией
разработчика (продажника), поскольку обязательно оперирует такими
плоскими (двухмерными, то есть) понятиями, как "панель", "кнопка",
"маркировка" (label), "100% по ширине", "по левому полю" и т. д. 
Пустой декларацией оказывается в таком случае "переносимость",
"независимость от платформы" и пр.

  По сравнению с такими обещаниями переносимости и независимости
конфигуратор ядра Linux ведёт себя очень и очень зерьёзно. Из
текстового он без труда превращается в графический ("на той же
кодовой базе", п. 5), его не трудно вообразить и в 3D/VR. Но конечно,
при всех возможных тут красивостях и даже украшательствах,
пользователь, в итоге, всё равно оказывается перед выбором из тех же
самых вопросов и альтернатив, которые заложены в диалоговое дерево и
ради получения ответов на которые и запускается конфигуратор. И это ---
очевидный минус, скажет кто-то.

  Но минус ли это на самом деле? Если мы, в-третьих, посмотрим на
оставшиеся тезисные пункты 8--11, то можем рассчитывать на вполне
положительный отзыв насчёт простоты (разработки) и "олдскульности"
(в хорошем смысле) использования диалоговой структуры.

  Важный момент. Каким неоспоримым преимуществом обладает диалоговый
интерфейс для настройки чего-либо? В соседних обсуждениях об этом,
кажется, никто не говорил (или я пропустил). А вот каким. На мой
взгляд, древовидная структура --- единственная до конца и полностью
документируемая структура. Причём, однозначно документируемая.
Все остальные варианты конфигуратора требуют написания
иллюстрированной документации со снимками экрана, которая из-за этого
страдает неоднозначностью и рискует потерять свою актуальность с
каждой сменой брэндинга и графического тулкита. Хотя я при этом совсем
не против иллюстраций, нет. Но согласитесь, что мануал по настройке
ядра с иллюстрациями текстовых боксов на 100% годится и в том случае,
если я использую "make xconfig". Это потому, что пользователь работает
здесь с логической структурой, которая не меняется.

  Теперь предложение.

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


---
[1]:
git://git.altlinux.org/people/manowar/packages/alterator-dialog-functions.git
[2]: git://git.altlinux.org/people/manowar/packages/dialog-framework.git