[не нужно][велосипед] консоль

welcome to the world of tomorrow!

Ну боян же.

Было уже разве?

> не нужно

велосипед

nooooooo!

какой сочный баттхерт :) юзабилити по видео не оценить, собрать чтоли...

А для Ъ?

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

Просто интересно зачем на это тратить время?

а под пинукс оно собирается?

Experimental Terminal platform built on WebKit + node.js. Currently only for Mac and Windows, though the prototype works 90% in any WebKit browser.

Вроде портируют на linux..

ну ты отрыл! баянищще. это идею даже уже на лоре озвучивали в прошлом, что ли, году

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

Обычная же текстовая консоль, не смотря на своё совершенство, как средство управления любой вычислительной техникой. имеет некоторые недостатки — к сожалению, она не может отображать графические изображения, видео и прочее. И framebuffer решает проблему только отчасти.

Правда TermKit — это лишь прототип, но я вполне предполагаю, что интерфейс у всех систем будущего будет именно такой.

вычислительной техникой

графические изображения, видео

lolwut?

выдыхай.

guyvernk> а под пинукс оно собирается?

Я поставил, даже работает. Хотя полезность очень сомнительна.

http://www.linux.org.ru/forum/general/6328272

Финиш.

недели две как уже перетерли ненужность сабжа

Баян и не нужно. Кстати, в комментах в блоге автора сего поделия правильно подсказывают, что таких велосипедов было уже не мало. И ни один реально не востребован.

>> вычислительной техникой

графические изображения, видео

lolwut?

То, в дисплей чего вы смотрите — это не терминал ЭВМ?

Всё есть вычисления, даже чтение текста.

> не нужно
И каким же по вашему будет интерфейс будущего, когда окончательно все поймут, что эти окошки на рабочем столе уже устарели?

А тебя это волнует?

> И каким же по вашему будет интерфейс будущего, когда окончательно все поймут, что эти окошки на рабочем столе уже устарели?

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

Приложения будут представлять собой нечто среднее между программами из Plan9 и веб-сервисами.

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

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

«Графический» интерфейс строится на тех же принципах, что и веб: приложение отсылает дисплейному серверу текст, описывающий логическую разметку интерфейса, а дисплейный сервер отсылает приложению сообщения о действиях пользователя. Приложение не должно знать и не знает, что именно с ним «общается», и как реально представлен интерфейс на стороне пользователя. Дисплей полностью логически независим от приложения: приложение может находиться на локальной машине или у черта на рогах в сети.

Stateless приложение при этом даже не может знать, что делал пользователь в интерфейсе раньше. Допустим, пользователь открывает словарь. Менеджер сеанса запускает приложение словаря и перенаправляет ему запрос. Приложение отвечает, посылая разметку своего интерфеса. Пользователь вводит слово для перевода и нажимает ввод. Запрос отправляется приложению, но к тому времени менеджер сеанса мог его уже закрыть для экономии памяти. Если так, приложение создаётся снова и отвечает на запрос.

При этом, такой «графический» интерфейс является частным случаем поддерживаемых приложением форматов. Например приложение-словарь может поддерживать другие форматы ответов: «плоский» человекочитаемый текст, CSV, XML и т.п. Если даже разработчики приложения не предусмотрели поддержки никакого другого формата, кроме языка разметки, то всегда можно, например, вручную послать запрос из скрипта и затем извлечь из ответа приложения нужную информацию (хоть простым grep-ом).

Интерфейс полностью доступен для пользователя как текст: можно выделить и скопировать любые фрагменты, можно просмотреть код интерфейса в сыром виде.

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

Получение справки от приложений аналогично получению интерфейсной морды.

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


Резюмируя:
Никаких намертво прибитых к развесистым тулкитам программ. Никакого псевдотекста на экране, который якобы есть, но на самом деле это картинка. Никаких блужданий в десятке диалоговых окон: любой элемент интерфейса имеет точный путь. Никакого мышевозничества: даже если у какой-то программы есть только «графическая» морда, всё равно её можно вручную подергать за элементы управления из консоли. Никакой зависимости от операционной системы как на стороне приложения, так и на стороне дисплея. Никакой ереси типа «рендеринга интерфейса на стороне приложения» и прочих виндообразных костылей. Никаких привязок к тому, чем является дисплей и какие у него должны быть системные требования: хоть OpenGL-ом рисуй интерфейсы, хоть псевдографикой в консоли.

Вот бы было здорово. Халва халва халва!

Иными словами, полное отделение логики от интерфейса. Звучит красиво.
А где такое есть?

Но вопрос тем не менее в другом: а как будет выглядеть сам пользовательский интерфейс на большинстве систем?
Сейчас и в Windows и в MacOS X и в KDE и в GNOME это прямоугольные окна на рабочем столе, имеется панель задач, где есть значки или кнопки для переключения запущенных приложений, есть трей, панель быстрого запуска и меню приложений, в некоторых DE — например в Unity панель не снизу, а слева, но суть её не меняется, опять же в Unity и MacOS X с Windows 7 быстрый запуск, трей и панель задач объединены в док, но принципиально их сущность не меняется.
Во всех этих DE окна прямоугольной формы, у них есть заголовок, на котором расположены кнопки закрытия, разворачивания на весь экран, сворачивания на панель.
И даже консоль в окошке.

Когда вот эта идея интерфейса будет устаревшей в общепризнанном смысле, что придёт на смену? Вот я предполагаю, что что-то вроде этого TermKit. Но не он сам, наверняка.

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

смысла запихивать вывод в саму консоль никакого

Вообще идеал совместной работы приложения и консоли - это емаксовый минибуфер:

1) у каждого приложения(в емаксе - режима) свой набор команд, так что работа минибуфера зависит от того, какое приложение сейчас в фокусе
2) команды - это не сочетания клавиш, которые все равно ни один человек никогда не запомнит, а полноценные полнотекстовые команды с удобным автодополнением
3) строка минибуфера не вылезает в центре экрана в окружении картинок, прыгающей анимации и т.п. как в gnome-do

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

Другое дело, как использовать эти окна. При правильном отделении логики от интерфейса пользователь сможет составить себе приложение под задачу из составных частей так же легко, как сейчас легко настроить набор апплетов на панели. По рецептам типа файловый менерджер + редактор + эмулятор терминала + простой скрипт, который соединяет всё это вместе = среда разработки с интегрированным терминалом и боковой панелью с файлами. Пример высосан из пальца, но, думаю, если возможность гибко соединять компоненты появится, то быстро придумают такие use case, которые пока еще трудно представить.

Может поменяться отношение к окнам. Окно не будет вещью в себе, оно будет понятно пользователю: окно можно будет скопировать и прикрепить к багрепорту или вставить в справку программы, на окно можно будет дать ссылку, можно будет поправить код окна, пропустить его через фильтр, заменить в нём таблицу стилей и т.п.

А где такое есть?

Нигде. Сейчас идет обратный процесс: запиливание всего и вся на сторону клиента и создание монстров. Поэтому я и говорю: прогнозы — неблагодарная штука. Что-то похожее было в GUI оберон-систем (Bluebottle, если не ошибаюсь). Можно было просмотреть любой диалог в «сыром» виде, внести изменения, ввести произвольный текст в любом поле и выполнить его как команду, получив туда же результаты. При чем, команды были командами вызова методов у объектов, т.к. вся система была объектной. В Plan9 тоже были некие наработки.

Но вопрос тем не менее в другом: а как будет выглядеть сам пользовательский интерфейс на большинстве систем?

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

Очень интересные идеи излагаешь...
А не мог бы сделать более подробное описание какого-нибудь одного usecase'а, желательно с набросками.
Выражение типа «Пользователь просто применяет фильтр к диалоговому окну» звучит красиво, но не конкретно. Хотелось бы так сказать прочувствовать как он его применяет и насколько это удобно/не удобно.
Хотя бы пару схематичных набросков.

> Выражение типа «Пользователь просто применяет фильтр к диалоговому окну» звучит красиво, но не конкретно. Хотелось бы так сказать прочувствовать как он его применяет и насколько это удобно/не удобно.

* Берём из окна проигрывателя название песни и панель кнопок и ставим на панель. Нажатие на кнопки отсылаем в исходное окно.
* Берём любое приложение и перекраиваем интерфейс: неудобное расположенное распологаем удобно, лишее выпиливаем, недостающее добавляем и прикручиваем внешними скриптами. В частности, модифицируем произвольным образом главное меню, статусбар и т.п.
* Разработчик не предусмотрел возможность использовать хоткеи? Добавляем на стороне дисплея нужные биндинги и привязываем к элементам интерфейса.
* Пишем плагин для панели задач и/или WM, который выгребает из окон список вкладок и встраивает в панель задач или WM как отдельные сущности, чтобы можно было переключаться между ними теми же способами, которые настроены в WM для переключения окон.
* При заходе в некоторый диалог автоматом или по хоткеям подставляем в поля ввода некоторые дефолные значения или значения из другого скрипта.

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

Хотеть такое себе.

Интересно.
Попробую найти проблемы в данном концепте...

На вскидку:
А что делать если на стороне сервера нет средств для отображения информации так как задумал разработчик? Нет какого либо специфического виджета, необходимого для специальной программы (CAD, например)?

Что еще пришло в голову:
Забыл сказать, что нечто похожее на то, что ты описываешь уже есть в PlanB/Octopus (эти ОС являются развитием идей Plan9). Вот тут http://lsub.org/ можно найти демонстрационные видео, на которых от плеера отделяют кусочек и таскают его между разными окнами и экранами, а также копируют. Еще, ЕМНИП, в каком то из роликов говориться о том что интерфейс можно заархивировать обычным tar'ом а потом разархивировать на другой машине. Такие плюшки достигаются благодаря развитию идей Plan9, а именно, в этой системе, GUI строится через взаимодействие с ФС.

Мне, кстати, тоже приходили в голову похожие мысли когда я пилил DockBarX. Хотел добавить возможность перетаскивания любого виджета из окна приложения в выпадающее меню значка в доке. Даже находил какую то программку (наверное все таки модуль для GTK) которая позволяла просматривать дерево виджетов запущенного GTK приложения. Но так и не запилил из-за отсутствия времени.

Теперь пару мыслей о возможных проблемах.
1) Программистов надо будет обязать следовать спецификациям. Это не тоже самое что просто знать название функций библиотеки виджетов и правила работы с ними. Я думаю, концепт можно сравнить с HTML. Есть некое дерево объектов, которое надо будет парсить. Пропарсить и нарисовать результат - не проблема, браузеры справляются. А со всякими фильтрами не все так просто (а ради них, а так же и других подобных плюшек все и затевается), появляется проблема однозначной идентификации виджетов в дереве.
Программистов надо будет заставить давать виджетам осмысленные имена, на что они могут забить (По аналогии с HTML, далеко не всегда id и class содержат что-то осмысленное).Без id и осмысленных имен будет трудно от запуска к запуску находить нужные виджеты, т.к. они могут перемещаться по дереву (например при изменении вида приложения).

2) Естественно это будут дополнительные тормоза, особенно они будут заметна в сложных UI.
Вообще что ты предлагаешь для описания дерева виджетов и обмена данными с сервером?

>Приложение не должно знать и не знает, что именно с ним «общается», и как реально представлен интерфейс на стороне пользователя.
Бред.

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

Со словарём? А если ввод — интерактивный (с мгновенным поиском или, например, визуальным фидбеком)? И не убьёт ли такая интерактивность всю эту систему тормозами?

(хоть простым grep-ом).

plaintext должен умереть.

Никакой ереси типа «рендеринга интерфейса на стороне приложения»

Хорошая идея. Жаль, что нереализуемая. Ну не считая веб10.0, но он неюзабелен.

>Разработчик не предусмотрел возможность использовать хоткеи? Добавляем на стороне дисплея нужные биндинги и привязываем к элементам интерфейса.
Кстати, хорошая идея. Можно сделать нечто вроде менеджера хоткеев (менеджер окон уже есть, а хоткеи — такой же разделяемый ресурс, как и экран).

* Берём любое приложение и перекраиваем интерфейс: неудобное расположенное распологаем удобно, лишее выпиливаем, недостающее добавляем и прикручиваем внешними скриптами. В частности, модифицируем произвольным образом главное меню, статусбар и т.п.

Не верю в юзабельность этого.

Музыка в тему очень.

> Бред.

Очень аргументированно.

А если ввод — интерактивный (с мгновенным поиском или, например, визуальным фидбеком)? И не убьёт ли такая интерактивность всю эту систему тормозами?

Я просто напомню, что интерактивный поиск в гугле — это тоже работа со stateless приложением.

plaintext должен умереть

Еще одна очень аргументированная точка зрения.

Не верю в юзабельность этого.

А мы уже ведем диспут о боге, я что-то пропустил?

> А что делать если на стороне сервера нет средств для отображения информации так как задумал разработчик? Нет какого либо специфического виджета, необходимого для специальной программы (CAD, например)?

Тогда придётся использовать canvas и гнать дисплею команды рисования как есть.

концепт можно сравнить с HTML

Ну в общем да, это некий «правильный HTML для разметки интерфейсов». Который таки изначально по семантике будет пригоден для этой задачи, в отличие от HTML. И еще — не думаю, что в качестве основы синтаксиса следует использовать xml.

появляется проблема однозначной идентификации виджетов в дереве

Не совсем понял. Будут стандартные типы узлов («поле ввода», «кнопка», «полотно»...) и будут идентификаторы конкретных узлов, выставляемые клиентской стороной. Всё это знакомо по HTML, приёмы работы с таким интерфейсами уже отработаны программистами. Большинство интерфейсов сайтов прекрасно поддаются модификации средствами CSS и вставкой JS-кода на страницу на стороне браузера. При том, что CSS и HTML вообще хреново приспособлены для задачи, которую сейчас решают — разметке произвольных интерфейсов. Отсюда полагаю, что для данного концепта проблема будет еще менее актуальна, чем для сайтов.

Программистов надо будет заставить давать виджетам осмысленные имена, на что они могут забить

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

Без id и осмысленных имен будет трудно от запуска к запуску находить нужные виджеты, т.к. они могут перемещаться по дереву (например при изменении вида приложения).

В отличие от сайтов, тут всегда есть возможность прислать разработчику патч. Это снимает остроту проблемы, если она будет.

Естественно это будут дополнительные тормоза, особенно они будут заметна в сложных UI.

Где-то определённо будут, а где-то, вероятно, будет наоборот — ускорение. Например, перерасчет размеров элементов можно будет в большинстве случаев выполнить целиком на стороне дисплея.

Вообще что ты предлагаешь для описания дерева виджетов и обмена данными с сервером?

Лично я — ничего конкретного, т.к. тут нужен серьёзный анализ. Некоторые разрозненные идеи:

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

* Разметка интерфейса производится на уровне виджетов, однако прямая отрисовка в canvas также должна быть предусмотрена. Для ситуаций типа рендеринга pdf, графических редакторов, игр, видео и т.п. Конкретные API для работы с созданным canvas могут быть различными и являются внешними по отношению к базовому протоколу. Видимо, на стороне дисплея поддержка разных API будет реализована через плагины, и там может быть что угордно: API для аппаратного декодирования видео, OpenGL, X-сервер-в-canvas, чёрт с рогами...

* Некоторые виджеты лежат на грани между «простой виджет на стороне дисплея» и «виджет со сложной прорисовкой, выполняющейся приложением». Например, виджет для редактирования многострочного текста. Выход вижу в том, чтобы определить стандартные требования к таким виджетам, а дополнительные возможности задавать как расширения протокола по мере необходимости. Например, подсветка синтаксиса и проверка орфографии могут в простейшем случае выполняться на стороне дисплея (и, следовательно, будут доступны в любом поле ввода, если поддерживаются реализацией). Но всё становится сложнее, если приложение хочет влиять на процесс подсветки синтаксиса.

* Любой узел разметки можно описать как ссылку на ресурс, который требуется подставить на место данного узла. Примерный аналог из HTML — тег img, который, однако, позволяет подставлять только изображения. (На самом деле, одно из самых нелепых ограничений, которое меня всегда изумляло в языке _гипертекстовой_ разметки.) Ресурсы могут быть описаны в том же дереве разметки, запрашиваться из приложения отдельными запросами, браться из некоторого «стандартного» перечня ресурсов на дисплейном сервере и т.п. В общем случае, правила подстановки ресурса определяет дисплей.

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

* В качестве основы синтаксиса потребуется нечто более вменяемое, чем xml.

>Некоторые виджеты лежат на грани между «простой виджет на стороне дисплея» и «виджет со сложной прорисовкой, выполняющейся приложением». Например, виджет для редактирования многострочного текста. Выход вижу в том, чтобы определить стандартные требования к таким виджетам, а дополнительные возможности задавать как расширения протокола по мере необходимости. Например, подсветка синтаксиса и проверка орфографии могут в простейшем случае выполняться на стороне дисплея (и, следовательно, будут доступны в любом поле ввода, если поддерживаются реализацией). Но всё становится сложнее, если приложение хочет влиять на процесс подсветки синтаксиса.
В итоге будет *очень* жирный display-server (веб-браузер?). В облаках это будет выглядеть более-менее естественно, но на десктопе…
Или десктопы умрут?

> В итоге будет *очень* жирный display-server (веб-браузер?)

А сейчас оно не жирное? Посчитай сколько вместе жрут все библиотеки поддержки гуёв на современном десктопе. А дерево виджетов и так сейчас у клиента поддерживается реализацией тулкита, если мы его перенесем на дисплей, для десктопа с локальными приложениями ничего не изменится.

Чтобы сервер не был жирным, достаточно 1) грузить реализации виджетов по необходимости, а не линковать всё в один бинарник и 2) реализовать нормальное API между сервером и плагинами, выпилив их в отстреливаемые по необходимости процессы, а не делать монстра из 30-ти *.so в одном процессе.