> Доводилось читать заметку о тру-юниксовом гуе, ну, каким он должен быть в
> представлении автора статьи. Суть сводилась к использованию аналогов шелл-конвейеров,

вот эту ? http://www.45.free.net/~vitus/ice/thoughts/true_unix_gui.txt (домен сдох) http://forum.linux.by/viewtopic.php?f=2&t=1152&view=previous (пересказ)
http://www.wagner.pp.ru/~vitus/articles/ http://www.wagner.pp.ru/~vitus/articles/true_unix_gui.html http://www.wagner.pp.ru/~vitus/articles/true_unix_gui_2_0.html (живые ссылки)
http://vitus-wagner.livejournal.com/49617.html (бложик автора )

> работающих с графическими элементами управления окон, т.е. окно формирует сообщения в
> каком-то формате о своем содержимом, и их становится возможным прочитать из
> скрипта и как-то воздействовать на окно. NextStep вроде бы пыталась использовать
> эту идею, но че-то у них не пошло.
> Идея классная, она
> превращает всю оконную среду в средство быстрой разработки программ (примерно как
> можно было составлять серьезные программы-скрипты при помощи sed, find, coreutils и

в NextSTEP были настоящие персистентные объекты, и сервисы (www>search), альтернативное API этих объектов, доступные снаружи. Основным достоинством NextSTEP было нормальное ООП апи, и грамотный дизайн системы, позволяющий из-за персистентности успешно разделять представление и контроллер (например, контроллер писался кодом, а представление -- gui дизайнером Inteface Builder, рабочее приложение без строчки кода)
сейчас оно доступно в MacOSX (Interface Builder) или в GNUstep (Gorm, см. http://www.gnustep.it/pierre-yves/index.html http://gnustep.org/), возможно, что-то подобное есть в Etoile (http://etoileos.com/ )

Но Next был не первым. До него была AMIGA http://en.wikipedia.org/wiki/AmigaOS#ARexx http://ru.wikipedia.org/wiki/AmigaOS#ARexx , где любое GUI приложение, построенное на мало-мальски высокоуровневом тулките (вроде MUI) изначально было скриптуемым, т.к. GUI объекты тулкита поддерживали порты ARexx "по умолчанию".
Однако, тулзов вроде "запись макросов" в MS Office или Automator в MacOSX не было.

Примерно в тоже время, что и Next, существовал Plan 9 с plumbing: http://en.wikipedia.org/wiki/Plumber_(Plan_9) http://doc.cat-v.org/plan_9/4th_edition/papers/plumb и оконной системой Rio/ 8 1/2 http://doc.cat-v.org/plan_9/3rd_edition/rio/ , где схожая с AMIGA идея портов сообщений
была реализована в оконной системе Rio или в текстовом редакторе acme как порты-файлы в пространстве имён приложения. Plumber уже умел делать "диспетчеризацию" выделенной ссылки в нужное приложение: настраивалась система правил, какой файл в какое приложение послать

полноценным сервисом в стиле NeXT или D-bus Это не было, ибо настройка файла правил проводилась в терминах конкретного приложения.

> bash в консоли). Действительно, зачем было тупо копировать вин95 и полностью
> забывать традиционную философию UNIX, которая действенна именно благодаря своей простоте?
> Еще ведь не все потеряно. Реализовать такую среду, на мой взгляд, гораздо
> легче, чем лепить такой комбайн, как KDE4. Сам сижу на KDE3
> - ностальгия ), но скоро переползу на что-нибудь типа awesome

справедливости ради, как бы не оказалось, что такую среду как раз проще реализовать именно в KDE, с его KParts, DCOP и D-bus. Теперь вот ещё семантическую БД какую-то встроили..

В awesome, на мой взгляд, что-то можно накрутить с XEmbed, xprop и нещадно скриптуя его на lua, или какой-то браузер вроде uzbl, luakit, serf (встраиваемых в XEmbed) , настраивая конфиги в емаксе, но количество времени на реализацию того же Plumbing + примитивного менеджера сессий для начала (а в перспективе семантической не БД, но ФС типа объектов, тегов и категорий тегов) -- разумной оценке по сложности и срокам не поддаётся