Этот мерзкий, неудобный, противоестественный оконный интерфейс 3.

И что же, все операции можно и нужно делать с командной строки? Даже...
...редактирование текста? Естественно, нет, хотя существовали редакторы, которые управлялись командами. Подавляющее большинство задач требует чего-то большего, чем командная строка. Но для нормальной работы нужна интегрированная среда, к которой можно легко подключить дополнительные элементы, а не возможность таскать окошки по экрану. Некоторым приближением к этому можно считать Norton Comander. Он позволяет выполнять достаточно много часто используемых операций с файлами, а недостающие возможности легко дополняются командной строкой, пользовательскими меню и реакцией на расширения (тип) файлов. К сожалению, даже эти возможности не были доведены до логического завершения, а последние версии непомерно разбухли, и вынесение многих функций в отдельные программы сделало работу просто неудобной.
Другой пример - редактор МикроМир, написанный ребятами из МГУ и распространяемый бесплатно. При размере менее 90 KB он позволяет работать с тремя независимыми буферами - поточным, строчным и прямоугольным; использовать имя файла в тексте как гиперссылку, т.е. легко перейти к этому файлу, запустить программу по его расширению и др.; сделать буквы большими, маленькими, русскими или латинскими (особенно полезно, если они набраны не в том регистре); работать в режиме таблиц, ограниченных псевдографикой; сортировать строки. Особенно радует, что можно свободно переносить текст между текстом, строкой поиска, строкой замены и командной строкой, а также то, что ранее введенные значения этих строк автоматически запоминаются и их можно легко вызвать. Разумеется, некоторые нелогичности есть и у МикроМира, тем более что новых версий не выходило с 1984-го года.
А текстовые процессоры, WWW-навигаторы, графические редакторы наконец? Они тоже должны управляться с командной строки?!!!
Нет, хотя запускать их можно и оттуда. Но вот выполняться они вполне могут в полноэкранном режиме, а не в оконном. Все равно даже полного экрана им мало.

А если мне надо держать перед глазами два документа? Да еще в разных программах?
А зачем? Если подумать, то окажется, что любая необходимость видеть два документа одновременно есть следствие недостаточной автоматизации либо непродуманного интерфейса. Либо нужные мне данные можно скопировать в редактируемый документ и там уже править, либо человек выполняет работу, которую мог бы выполнить компьютер. Часто приходится набивать текст, который разработчики почему-то сделали недоступным для копирования. Названия иконок, список фонтов, список задач в MS-Windows - это текст, но скопировать его нельзя. А иногда компьютер принял факс, и девочку-секретаршу сажают набивать текст, записанный в графический файл, вместо того чтобы запустить распознаватель и затем редактировать полученный текст или просто передать текст, а не его графическое изображение по электронной почте или другими аналогичными средствами.
Специалисты фирмы Xerox, когда разрабатывали оконный интерфейс...

А разве оконный интерфейс был разработан фирмой Xerox? Она же не имеет никакого отношения к компьютерам!
Да, оконный интерфейс, как и стандарт локальной сети Ethernet, был разработан в фирме Xerox, но не был запатентован, а был отдан для реализации всем желающим. Но я отвлекся. Так вот, оконный интерфейс разрабатывался как аналог рабочего стола, на котором разбросаны документы. При этом, однако, не учитывалось, что на самом деле требуется два режима: "просмотра списка документов" и "работы с конкретным документом". Человек никогда не держит перед глазами два документа - он переводит взгляд с одного на другой.
В какой-то степени эти два режима - работы с программой и просмотра списка программ - реализованы в виде полноэкранного режима задачи и Панели Задач (taskbar). Первый недостаток такого подхода в реализации Windows'9x/NT в том, что Панель Задач оформлена в совершенно ином стиле, чем задачи - она расположена на краю экрана (обычно внизу) и либо присутствует постоянно, либо появляется при подходе курсора к краю экрана. Гораздо лучше был реализован Список Задач в Windows'3.11 - он появлялся в виде окна в центре экрана. Если бы еще это окно могло менять свой размер в зависимости от количества задач - ему цены бы не было! Существенным недостатком обоих списков задач является то, что в них отражается слишком мало информации, да к тому же это зачастую не та информация, которая нужна пользователю. Например, при запуске нескольких окон WWW-браузера мне хотелось бы в списке задач видеть, что происходит с ними, какая страница закачалась, а какая еще нет; вместо этого в списке задач видны только заголовки задач.
Кроме того, модель "панели управления", реализованная системой кнопок, не учитывает, что в управлении панелью огромную роль играют тактильные ощущения; для их усиления дизайнеры стараются придать кнопкам и рычагам разную форму, сделать им разную поверхность. Все это невозможно при работе с проскальзывающей мышкой и отображенными на экране кнопками. Лучше уж пользоваться комбинациями клавиш.
Впрочем, в той же самой лаборатории PARC уже разрабатывается интерфейс Hyperbolic Tree, не имеющий ничего общего с окнами. Возможно, они прочитали черновой вариант этой статьи, опубликованный на WWW-сервере.

Ну и в чем же суть этого интерфейса?
Начну издалека: как известно, глаза человека охватывают почти 180° по горизонтали, при этом около 30° составляет "рабочая область", в которой острота зрения максимальна, а к краям чувствительность зрения падает - отсюда понятие "боковое зрение". Монитор компьютера спроектирован так, что вся его рабочая область оказывается в центральном поле зрения. Для игр типа "Doom", "Duke Nukem 3D", "Quake" это очень неудобно - человек оказывается "зашоренным" (от слова "шоры" - что-то типа очков, надеваемых лошади, чтобы та не видела ничего по сторонам и не отвлекалась); в то же время игроку надо иметь максимально естественное зрение. Частично этого можно достичь применением "виртуального шлема", экран которого охватывает все поле зрения игрока.
Боковое зрение, в поле которого находятся те документы, с которыми пользователь в данный момент не работает, было проигнорировано создателями оконных систем; возможно, у них были большие мониторы. В любом случае тот документ, с которым я работаю, должен занимать подавляющую часть "рабочей области", а остальные документы должны быть вытеснены "на периферию". Частично это реализовано в виде "панели задач" в Windows'95/NT, но она оказалась слишком негибкой - если иконки на "рабочем столе" и в меню "Start" можно распределить по папкам (директориям), хотя это и не самое удобное, то в "панели задач" они расположены строго в порядке их запуска. К тому же в "панели задач" отображаются именно задачи, точнее - программы, чей запуск их породил; гораздо логичнее было бы отображать документы - иконки, олицетворяющие задачу, должны содержать не рисунок задачи (например, стилизованную букву "W" для редактора Word), а внешний вид документа (той части, которая видна в рабочем поле редактора), уменьшенный до размеров иконки. То же самое, кстати, относится и к отображению документов-файлов в FileManager - желательно изображать их не типом обрабатывающей их программы, а видом титульной страницы.
Ну а сама идея "Hyperbolic Tree" в том, что информация представлена в виде дерева (графа, у которого между любыми двумя вершинами имеется ровно один путь) без выделенного корня; объекты, с которыми работает пользователь, представляются вершинами дерева, а связи между ними - ребрами; в качестве корня принимается тот объект, с которым работает пользователь, а остальные расположены вокруг него, причем чем дальше от выбранного корня по дереву расположен объект, тем дальше от центра он располагается и менее детально отображается.
Одним из основных недостатков оконного интерфейса является его прожорливость по отношению к ресурсам. Конечно, если Вы готовы заплатить за самый мощный на сегодняшний день процессор и немеренное количество оперативной памяти, эта проблема Вас не волнует. Но вот если Вы небогаты или если у Вас этих компьютеров на предприятии не один десяток - придется задуматься. Ведь почти все современные WindowManagers (диспетчеры окон) о каждом произошедшем событии оповещают задачу - хозяина окна. Потребовалось перерисовать содержимое окна или его части, нажали кнопку на клавиатуре или кнопку мыши, просто провели курсором мыши над окном - каждый раз диспетчер окон вызывает задачу. Тратится время на переключение контекста задачи, перезагружается кэш-память, происходит подкачка с диска - короче, непроизводительно расходуются ресурсы машины.
Я говорил, что прожорливость к ресурсам не является главной причиной; я имел в виду только то, что оконные системы неудобны сами по себе, но экономия ресурсов - тоже немаловажная вещь. Обратите внимание: как только мы отказываемся от текстового режима и переходим на графический, немедленно в два, а то и более раз вырастают потребности в памяти. Например, Unix-сервер (FreeBSD или Linux) можно запустить на 4 MB памяти (правда, это будет весьма медленный сервер), а Windows'NT'Server можно запустить никак не меньше чем на 16 MB (и работать будет не лучше, чем Unix на 4 MB). На 8 MB можно запустить W'95, а на 4 MB - W'3.11, но при этом мы лишаемся и вытесняющей многозадачности, и разграничения доступа к файлам на уровне операционной системы, и всех остальных свойств, которые должны присутствовать в серверной операционной системе.
В этом смысле очень интересно сравнить взаимодействие программы с WindowManager'ом и взаимодействие X-терминала с хостом. Если компьютер с принтером можно рассматривать как мини-сеть, то почему бы взаимодействие программ не рассматривать как клиент-серверное? Так вот, X-терминал посылает сообщения хосту о каждом событии - тычке мышкой, нажатии кнопки, необходимости перерисовать окно. А вот HTML/Java-терминал тривиальные случаи (перерисовку, прокрутку, ввод символов в поля ввода) обрабатываются встроенной программой (браузером), для не очень тривиальных в составе страницы есть программки на Java и JavaScript, а самые нетривиальные, требующие новых данных, передаются на WWW-сервер. Примерно такую же модель давно надо было реализовать и в оконных системах. Я не уверен, что при выполнении задач, ядра OS и драйверов на одном процессоре нужен промежуточный слой программ обработки "не очень тривиальных случаев", хотя для асимметрично-мультипроцессорной архитектуры с медленной передачей сообщений, каковой является сеть, это очень удачное решение. Примерно такая схема, насколько я знаю, была реализована в RiscOS - задача может передать окно модулю, который берется за обслуживание сообщений к этому окну. При этом окно должно быть описано в определенных терминах - здесь картинка, здесь текст, а здесь кнопка - и задача, создавшая окно, будет обрабатывать только то, что не удается описать в рамках понимаемых этим модулем терминов; впрочем, туда были включены все наиболее часто используемые элементы. К сожалению, этот способ сделать оконные программы более компактными так и не перекочевал в другие операционные системы.

Объектно-ориентированное программирование позволяет не обрабатывать те события, которые не интересуют программу.
Объектно-ориентированное программирование - один из способов скрыть от программиста детали реализации. Это хорошо, только если надо быстро написать программу, которая потом будет не слишком часто выполняться. Или если надо написать переносимую между разными платформами программу (в надежде, что на каждой платформе уже есть нужные библиотеки). Избежать обработки всех подряд событий можно, только поручив WindowManager'у обрабатывать тривиальные элементы окна.
А пока WindowManager не умеет сам обрабатывать такие события, программа на объектно-ориентированном языке все равно будет обрабатывать все события; даже если программист проигнорировал какой-либо тип события, компилятор сам добавит "стандартный обработчик", бессмысленно пожирающий ресурсы машины.
Ну, ресурсы машины как бы не очень жалко - машина железная, пусть работает. Жалко пользователя, который тратит кучу времени, пытаясь красиво расположить окошки на экране, вместо того чтобы работать; а как только добавился новый элемент, приходится повторять всю процедуру снова. Это один из примеров того, что гибкость системы отнюдь не всегда способствует удобству работы.
А для многих задач коллективной работы с каким-либо набором данных зачастую достаточно мощного компьютера, к которому подключены дешевые текстовые терминалы. Существенное преимущество такого подхода - резкое снижение стоимости всей системы при большом количестве рабочих мест и снижение загруженности сети. (Еще меньше загружают сеть HTML- и Java-терминалы, но они сложнее и поэтому дороже.) Вдобавок SQL-клиент, выполняющийся на одной машине с SQL-сервером и отображающий результаты своей работы в виде терминальных управляющих Escape-последовательностей либо в виде HTML, гораздо быстрее осуществляет транзакции, чем SQL-клиент, выполняющийся где-то в сети. У текстового терминала, кстати, гораздо меньше уровень электромагнитного излучения и выше качество изображения, но об этом мало кто задумывается.
Не могу не признать, что графический режим полнее использует экранное пространство: т.к. буква "w" гораздо шире, чем буква "i", нецелесообразно тратить на них одинаковое пространство, как это принято в текстовых режимах; к тому же у векторных шрифтов, применяемых в графике, можно подрегулировать размер (кегль) под размер и разрешение монитора и под зрение пользователя. Но, с другой стороны, почему-то текстовые режимы менее восприимчивы к уменьшению размера экрана, чем графические. Все-таки, на мой взгляд, текстовые режимы были вытеснены на обочину прогресса, так и не исчерпав всех своих возможностей - например, вполне реально создать знакогенератор, который бы отображал текстовом режиме буквы разной ширины (при этом длинна строчки должна была быть рассчитана под строку из самых узких букв, а при наличии в строке широких букв ее конец терялся бы за краем экрана).

И как это должно выглядеть?
Допустим, что ширина экрана - 640 пикселов; самый узкий символ - восклицательный знак, точка, пробел - шириной три пиксела; значит, система должна быть рассчитана на 213 символов в каждой строке. Допустим, в строке оказался широкий символ, занимающий девять пикселов, а остальные - пробелы; это значит, что будет отображено только 210 пробелов, а остальные символы не будут отображаться на экране вообще.
Естественно, программа должна иметь возможность узнать, сколько символов реально отображает дисплей, чтобы перенести оставшиеся в следующую строку. По-видимому, будут нужны символы, с помощью которых можно будет добиться выравнивания вертикального столбца, а для того, чтобы знать, куда и какие символы надо помещать, программе должна быть доступна информация о ширине каждого символа. Естественно, отображение информации на таком дисплее требует тщательного программирования и ресурсов под программу, так что, возможно, создатели компьютеров правильно сделали, что перешли от текстовых экранов фиксированной ширины прямо к графическим экранам; к сожалению (или к счастью), история не имеет сослагательного наклонения, а сейчас затевать эксперимент с вышеописанным дисплеем поздно и никому не нужно.

Хорошо, это все количественные различия. А есть что-нибудь более существенное?
Ну, для системного администратора, на мой взгляд, "наглядное графическое представление данных" просто опасно - освоивший технологии "укажи и нажми", а также "перетащи и брось" берется за управление системой, не освоив основ ее функционирования. Хуже того - очень многие начинают путать интерфейс представления данных с самими данными. Это не страшно до тех пор, пока система функционирует в рамках, описываемых интерфейсом, т.е. в пределах того, что предусмотрено ее создателями. Но, как известно, катастрофы не требуют планирования, а любая нештатная ситуация потому и нештатная, что не предусмотрена создателями системы (иначе система сама бы справилась). При этом я сошлюсь на PC Week 12(86) от 1-7 апреля 1997, статья Леонида Миронова "Нужен ли ГИП(GUI) для серверной ОС?".
Если Вы настраиваете IP-маршрутизатор, никакой графический интерфейс не позволит Вам обойтись без знания таких вещей, как "номер сети", "маска", "шлюз"; настройка DNS (сервера доменных имен) требует знать, что обозначают записи MX, NS, A, PTR, HS-INFO; а борьба с сообщением "No access" ("недоступно") требует разбираться в правах доступа. И "интуитивно понятный интерфейс", даже с "контекстной подсказкой", мало поможет, если нет фундаментальных знаний.
Установка атрибутов доступа каким-нибудь SecurityManager (менеджером безопасности) ничем не поможет, если в системе есть хоть один способ доступа в обход этих атрибутов, в то время как все программы будут наглядно показывать, что система полностью закрыта от нежелательных лиц. Как можно определить, что в системе настежь открыта "задняя дверь"? Только детально разбираясь в "потрохах" системы, не полагаясь на сообщения привычных утилит, тем более что однажды проникший в систему злоумышленник вполне мог заменить эти утилиты на свои, которые никогда уже не скажут правды законному администратору.
А теперь представьте себе, что управление ядерным реактором доверено оператору, который полагается на "наглядный" графический интерфейс. Пока все идет как надо, оператор легким движением мыши управляет работой реактора, основываясь на наглядно представленных параметрах функционирования. Но вдруг он промахнулся и нажал не ту кнопку (а для нажатия кнопки, изображенной на экране, не нужно откидывать предохранительный колпачок, даже если это кнопка самоликвидации путем атомного взрыва). Или реактор самопроизвольно перешел в режим, не предусмотренный создателями программы. Или сломался какой-нибудь из управляющих элементов. Если оператор изучал реальное устройство реактора, а еще лучше - принимал участие в монтаже, он сможет, манипулируя оставшимися в его распоряжении средствами управления, удержать реактор от взрыва. А если он привык к своему интерфейсу и не знает ничего о реальном реакторе, которым управляет?

Ну, большинство пользователей работают все-таки не с ядерными реакторами!
Да, но им тоже не помешает знать детали функционирования системы. Когда в 1987-1992 годах я работал на компьютерах фирмы Acorn, модель B+, я заметил прекрасное свойство операционной системы: системный вызов OSByte соответствовал команде *FX, т.е. команда
*FX аргумент1 аргумент2 аргумент3
с числовыми аргументами соответствовала ассемблерному коду процессора 6502
LDA #аргумент1
LDX #аргумент2
LDY #аргумент3
JSR OSByte
правда, при этом нельзя было узнать, какие значения возвращает операционная система в регистрах A, X и Y:-(. Таким образом, можно было задать автоповтор клавиатуры, определить действие функциональных клавиш и стрелок, перенаправить ввод-вывод, настроить работу последовательного и параллельного портов, а также видеосистемы и многое другое. Граница между квалифицированным пользователем и программистом почти отсутствовала.
DOS предлагает гораздо худшую модель: между командой
MODE con RATE=r DELAY=d
и ее ассемблерным аналогом
MOV AX, 0305H
MOV BL, 32-r
MOV BH, d-1
INT 16H
уже нет такого однозначного соответствия. Однако пользователь легко может написать script, или, как его называют в DOS, batch-файл (по-русски - пакет команд), который будет содержать команды, обычно подаваемые с клавиатуры. Пользователь может облегчить себе жизнь, но стать программистом ему будет гораздо труднее.
А вот в системах с "менюшным" интерфейсом создать пакетные задания гораздо сложнее - между пользователем и программистом пролегает почти непреодолимая пропасть. Именно поэтому удобные пользовательские интерфейсы создаются людьми, которые прошли огонь, воду и медные трубы примитивной командной строки без средств редактирования, да еще в отсутствие удобных утилит - но чем удобнее созданный ими интерфейс, тем быстрее система перестает развиваться, впадает в стагнацию. Избежать застоя, насколько мне известно, удалось только Acorn и Unix. Acorn изначально разрабатывал комплексное решение, включающее сам компьютер и программное обеспечение (от ядра операционной системы до текстовых редакторов), зашитое в ПЗУ. Основную прибыль приносит продажа "железа", поэтому фирма оказалась заинтересована в расширении круга программирующих для этой платформы. ПО (как фирменное, так и независимых производителей) строится из независимых модулей, связанных протоколами вызовов. Наиболее популярные (часто используемые) модули включаются в ПЗУ следующих версий.
Unix - уникальный феномен многих операционных систем для разных аппаратных платформ, объединенных общими стандартами. Несмотря на наличие нескольких семейств, таких как System V и BSD, а также множества диалектов типа QNX, Unix'ы сохраняют совместимость на уровне исходных текстов программ (откомпилированные программы не переносятся не только на другой процессор, но и на другой Unix, работающий на том же процессоре). Переносимость программ удивительна даже по сравнению с совместимостью разных версий одной операционной системы одной фирмы для конкретной платформы. Жизнеспособность Unix долгое время поддерживалась доступностью исходных текстов ядра и утилит; в последнее время исходные тексты коммерческих Unix'ов недоступны, но появились бесплатный FreeBSD (в противоположность платному BSDi) и "народный Unix" Linux. Жизнеспособность Unix поддерживается прежде всего конкуренцией среди разных групп программистов, каждая из которых стремится сделать свой Unix лучше других, а лучшие решения быстро перекочевывают во все другие реализации.

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

Дмитрий Карпов