Журнал Витуса

Еще когда я впервые в жизни увидел Windows 3.1 меня несказанно удивило, что там редактор иконок считается частью средств разработки а не end-user-ской программой. Для меня как-то казалось очевидным что иконка файла в GUI должна изображать нечто, напоминающее пользователю о содержимом файла, а не о программе, умеющей с ним работать.

Windows с тех пор несколько исправилась и научилась по крайней мере для фотографий вместо иконки показывать превьюшку.

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

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

http://esr.ibiblio.org/?p=7421

Раймонд умный пост написал по поводу концепций, которые лежат под Unix way. Я эту мысль про семантическую локальность три дня думать буду.

Собственно, этот проект я начал тихой сапой год назад, когда начал писать vws. Вчерашний пост про OpenVPN явно является продолжением того же тренда. Кстати для openvpn-менеджера я уже репозиторий завел.

Вообще надо еще wpa_gui переписать. И bluez-applet. К этому снаряду я уже, правда, пытался подойти, но без большого успеха. Впрочем, теперь у меня больше блютусных девайсов - есть и наушники, и мыши.

В общем, проект по устранению из linux-овой рабочей станции/ноутбука лишних демонов. Благо демоны нелишние wpa-supplicant, openvpn, qemu-system прекрасно умеют выполнять ту работу, ради которой пытаются завести лишний набор демонов, которые ими управляют. Поэтому вместо демонов надо сделать апплеты в трее или командно-строчные утилиты, которые все необходимые операции умеют выполнять.

От libvirtd я уже больше года как избавился, хотя для того чтобы довести vws до состояния, пригодного для многопользовательских систем и сборочных серверов под управлением jenkins и pgfarm потребовалось довольно много времени.

Теперь вот собираюсь на NM с wicd ополчиться.

На самом деле в основном потому что есть нетбук, на который LXDE попросту не лезет (5-й libreoffice их бэкпортов лезет, а на lxde уже места не остается. Эксперимент с awesome признан несколько неудачным. Сам я еще как-то пользоваться им могу, но вот научить ребенка не получается. Он уже привык к традиционным wm с перекрывающимися окнами, поэтому оказалось проще поставить jwm, чем объяснять ему за одни выходные (большую часть которых мы оба провели в огороде), кучу концепций, которые я еще и сам до конца не усвоил.

На самом деле lxde для меня потеряла смысл уже давно, когда я перешел с pcmanfm на spacefm. Все остальное, что я использую от lxde jwm умеет не хуже.
Разве что lx-logout'у еще надо приискать десктопонезависимую замену. Впрочем, lx-logout безбожно глючит с light-locker-ом. В смысле, систему в которой вместо xscreensaver используется lightlocker не умеет корректно уложить в hybernate, чтобы она потом нормально взлетела. А если нет hybernate, то функциональность lx-logout сводится к той, которую обеспечивают совместно менюшка quit в jwm и аппаратная кнопка питания.

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

И у этого подхода есть масса преимуществ. Во-первых, прекраснореализуется toolbox phylosophy. Во-вторых, авторам приложений не нужно думать о поддержке таких операций как бэкап, или о способах передачи данных по сети - это можно поручить отдельным программам - сетевым FS, ftp-клиентам и т.д, и они прекрасно справятся с любыми данными.

Но чего-то в этой парадигме не хватает, и ее постоянно пытаются поломать. Из тех примеров, с которыми приходилось сталкиваться лично мне, первым была MacOS classic, с атрибутами creator и owner у файла. Концепция была, конечно. сильно кривая и мешала, когда нужно обрабатывать некие данные несколькими программами.

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

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

Или для обмена данными по шнурку вместо избыточно низкоуровневого для этой цели USB Storage используют не протокол уровня файловой системы (SMB, например), а какой-нибудь PTP или MTP.

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

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

Я вот тут задумался над вопросом, а какая нужна надстройка над протоколом, подобным интентам, чтобы реализовать те полезные возможности файловой системы, которых нас лишает андроид, стремящийся максимально изолировать приложения друг от друга.

1. Нужен стандартизированный протокол бэкапа. То есть любое приложение, которое хоть что-то хоть где-то хранит (ну кроме очень специальных случаев вроде HSM, должно поддерживать операцию "скачать всё" и, по возможности - "скачать изменения со времен такого-то бэкапа", а также "восстановить вот это".
В принципе, даже HSM-ы можно бэкапить, если предусмотреть защиту бэкапа секретом, который хранится где-то отдельно от бэкапа.

2. Нужен стандартизованный object sharing протокол. Что-то вроде того же PTP или MTP - посмотреть какие объекты есть в библиотеке у данной программы, вытащить указанный объект в виде, пригодным для того, чтобы скормить аналогичному приложению на другом устройстве, положить объект.

Возможно, в обоих случаях нужно поддерживать что-то типа rsync-протокола, то есть возможность передачи по кускам с контролем целостности.

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

Upd А придумает ли кто-нибудь третий случай операции кроме "забэкапить все" и "поделиться избранным", применимый к ЛЮБОЙ информации хранящейся на устройстве? (понятно что варианты "открыть в соответствующем приложении" и "стереть нафиг" не в счет).

Вот смотрю я на развитие проекта Devuan и думаю, что форк без systemd это, конечно, благая идея. Но если не отказаться от GTK и Qt, создать систему в которой от использования GUI будет легко перейти к его модификации, не получится.

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

Непонятно зачем вообще столько лет в Linux проталкивали D-Bus. Казалось бы системная шина ровно для этого нужна - передать программам, которые могут быть в этом заинтересованы сообщения об общесистемных событиях (ну например, смене роутинга или открытия/закрытия крышки) и пусть они на это реагируют, если хотят.

А тут вот почему-то из рутового скрипта непосредственно производится управление пользовательскими скринсейвером. И отключить можно только глобально, для всех пользователей сразу. Хотя очевидно, что ценность моей сессии и ценность сессии Артура для потенциального мимопрохожего взломщика разная (знаем мы, кто тот взломщик ;-).

(А все потому что никто не додумался включить в комплект dbus скриптуемый тул для реакции на события).

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

Пришла тут мысль, что в операционной системе, кроме понятия "сессия" дожно существовать понятие "закулиса".
В смысле, контекст, в котором выполняются действия от имени пользователя, независимо от того, есть в данный момент этот пользователь рядом с компьютером или нет.

В классическом unix фактически единственным представителем закулисы являются кроновские задания.
Несколько позже появились всякие procmail-ы и sieve.

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

Достижение определенной географической точки/соты/wi-fi сети. Появление в радиусе действия какого-то локального протокола (wifi, bluetooth, подключение USB-шнурком) принадлежащего пользователю гаджета, завершение закачки файла (я считаю что это событие следует рассматривать отдельно от "завершение очередного этапа в пакетном задании", так как закачка файла может производиться каким-нибудь mldonkey, который закачав этот файл продолжает работать с десятью другими закачками трех других пользователей, или вообще речь идет о том что кто-то зааплоадил файл на анонимный ftp)

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

Вообще обсуждение уже принесло немало интересного, хотя постоянно норовит свалиься куда-то на низкий уровень - в обсуждение шин сообщений и прочих API. А мы вообще-то еще требования к UI не сформулирвали.

Но вот rainbow_beast просветил меня по поводу разницы между mind maps и concept maps.

Хотя я не уверен, что термин mind mapping не подходит, но все же в названии "Концептуальный интерфейс" что-то есть. Постмодерном попахивает.

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

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

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

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

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

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

Кстати о безопасности, Систему следует планировать исходя из того, что любая из компонент может содержать если не злонамеренный код, то опасные ошибки. И везде где возможно использовать разграничения доступа к памяти, ограничения доступа к файловой системе и т.д. В качестве образца мы имеем по крайней мере две модели - классическую модель Unix и неклассическую Android с контрактами приложений. Там, правда, очень плохо сделано разграничение доступа к файловой системе. Можно еще посмотреть на остерхутовскую модель из SafeTcl.

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

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

У окна четыре стороны и можно их закрепить за разными типами связей.

Возможно, стоит позаимствовать из Ashton Tate Framework концепцию "изнанки фрейма". Там на изнанке фрейма можно было писать скрипт, генерирующий содержимое фрейма. Здесь более логичным является наличие на изнанке пояснительного (гипер)текста про то что можно с этим фреймом делать. Скрипт там тоже может быть, на то еcть literate programming.

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

Идеями Раскина насчет полностью modeless интерфейса злоупотреблять не стоит. Смена взгляда на один и тот же информационный объект иногда вполне оправдана. Но только надо оформить смену режима как переход по ссылке в concepts map. Вот до сих пор это у нас был текст, который мы набирали, и ассоциировался он с набором инструментов для работы с содержимым, а сейчас это стал верстаемый документ, и набор инструментов стал совсем другой.

Тут чего-то в мире пользовательских интерфейсов, который казалось на десятилетия застыл в парадигме CUA, в связи с появлением планшетов наметилось какое-то шевеление.

В связи с этим возникают мысли про то, как в принципе может пойти развитие интерфейсов на более традиционных устройств. Некоторое время назад я описал в "Детях пространства" как Карл Кроппкэ обучается работе со спейсианским ноутбуком.

Принципиальны там следующие вещи

1. Интерфейс неинтуитивный, он требует обучения. И несмотря на то что Лада прекрасно знает что Карл - образованный и весьма квалифицированный программист, она заставляет его пройти интерактивный обучающий курс.
Что курс там оказывается весьма хорошо написан - отдельный вопрос. Вот чего-чего а concept manual-ов современным интерфейсным нововведениями вроде мультитача явно не хватает.

2. В качестве отцов основателей чьи идеи были использованы в этом интерфейсе упоминаются Раскин, Вирт и Бузен.
При этом кнопка Jump на клавиатуре есть. Но испольузется не как у Раскина, а скорее как Meta в Unix или Command в MacOs. То есть не сама по себе а в сочетании с чем-то ещё. (это по поводу Раскина). У Вирта из Оберона по-моему можно позаимствовать ровно две вещи - tiled window management (который сейчас весьма популятен среди профессионалов) и выполнение команды, написанной в любом месте на экране одним кликом. Вот притащить в интерфейсы идеи Бузена, то есть Mind Mapping - штука нетривиальная.

В принципе, гипертекст со ссылками весьма близок к mind mapping, так что возможно, развитие html5-based интерфейсов туда и приведет. Но mind mapping это в первую очередь система быстрого и удобного редактирования связей между объектами.

Идеи Раскина о сплошном поиске в интернете более-менее реализованы усилиями гугля. Впрочем, идея reinventing the command line с возможностью указания поискового запроса вместок команды есть по-моему в Unity.

Кстати была еще идея экрана как бесконечного параболоида, автора которой я, к сожалению не вспомнил. Но можно считать что мой персонаж её тоже не вспомнил. То есть когда окно удаляется из фокуса внимания, оно уменьшается. И чем ближе к краю экрана, тем сильнее. Это в общем-то естественно стыкуется с mind map-ом. Окна, находящиеся на расстоянии одной ассоциации от текущего показываются уменьшенными, но так, что даже текст при желании читаем, на расстоянии двух - уже почти иконки и так далее.

И я совершенно зря не упоминул Негропонте с "активностями". Потому что далеко не все окна на экране являются именно "объектами", "документами" - статичными сущностями, которые могут измениться только по инициативе пользователя. Есть логи, чаты и тому подобные вещи, которые меняются "самопроизвольно" с точки зрения данного пользователя.

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

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

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

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

1. Должен поддерживаться ключик, переводящий stdin/stdout в line-buffered (или unuffered) режим несмотря на то что условие isatty(fileno(stdin)) не выполняется. Это позволит не расходовать ценный ресурс PTY (которым вынужден пользоваться rlwrap)

2. Должна поддерживаться команда, которая позволяет узнать, является ли данная строка завершенным высказыванием входного языка, которое можно отдавать на выполнение (аналог tcl-евского info complete)
3. Должна поддерживаться команда которая по паре "строка, позиция в строке" позволяет узнать как называется объект, который может стоять на этом месте в строке
(переменная, опция, таблица, поле etc).
Можно ограничиться передачей только строки, в предположении что имя должно начинаться там, где кончается строка.

4. По названию типа объекта и префиксу имени вернуть список всех имен подходящих объектов.

По-моему, поддержки такого протокола вполне хватить для того, чтобы реализовать полноценный completion в стиле лучших реализаций программ, испольузющих readline.
Да, естественно, что при выполнении условия 2, требование "команды 2, 3 и 4 можно подавать только тогда, когда интерпретатор ожидает выполнения команды" не является чрезмерным.