Об интерфейсах
Итак, пользователь получил доступ к ресурсам машины через терминал в текстовом или графическом режиме. А что дальше? А дальше ему требуется некая программа, обеспечивающая интерфейс для взаимодействия между ним, любимым, и операционной системой с протекающими в ней процессами и входящими в нее файлами.
За всю историю человечества было придумано лишь два принципиально различных класса интерфейсов (между прочим, это относится не только к околокомпьютерной сфере деятельности).
Исторически первым (и, замечу, наиболее естественным) способом взаимодействия пользователя с машиной (и всеми ее потрохами) был командный интерфейс, основанный на отдаче прямых директив. Обычно он осуществляется с помощью клавиатуры, однако теоретически можно использовать и любой другой способ ввода команд - скажем, щелчком средней клавиши мыши. Именно ему, под именем CLI (Command Line Interface - интерфейса командной строки) суждено было на долгие годы стать традиционным интерфейсом Unix (а затем и POSIX-совместимых операционок вообще).
За вторым способом взаимодействия человека и машины прочно закрепилось название графического (GUI - Graphic User Interface - графического интерфейса пользователя). Название, впрочем, не строгое - а в общем случае и просто не верное: ниже будут даны примеры такого рода интерфейсов, функционирующих в текстовом режиме; и напротив - командных интерфейсов, реализуемых в режиме графическом.
Основной принцип интерфейсов второго рода - отказ от использования прямых командных директив в пользу манипулирования объектами - файлами, каталогами, интерфейсными элементами и т.д., выполняемого обычно с использованием мыши. Хотя, как мы видели ранее, с помощью мыши можно и вводить прямые команды. А манипулировать объектами с помощью клавиатурных комбинаций также никто не запрещает. Разумеется, в конечном счете таким путем вызываются те же командные директивы, однако сами они остаются глубоко за кадром.
"Совершенно верное определение" подобрать затрудняюсь, но то, что именуется графическими интерфейсами, скорее следовало бы называть интерфейсами объектными, манипуляционными или как-то в этом роде.
Хотя все эти термины неудачны - первый из-за ассоциации с ООП в понимании Грэди Буча (к коему в общем случае иметь отношения вовсе не обязан), второй - просто из-за трудновыговариемости.
Не вполне адекватен также термин "сенсуальные" интерфейсы, предложенный в свое время Максимом Отставновым. На основании того, что "звук стал их полноправной частью" (Максим Отставнов. Неимоверно важный Гном. Компьютерра, 2000, #45-46 (374-375), с. 26). До недавнего времени это - было не более, чем мечтой: почти никакой функциональной нагрузки (кроме более или менее мелодичных стонов и визгов) звук в компьютерной рабочей среде не нес. И дожить до полноценных голосовых (особенно русскоязычных) интерфейсов я не особенно рассчитывал. Хотя недавно в очередной раз был посрамлен в своем пророчестве: в KDE версии 3.4 управление голосом приобрело уже практический смысл. Однако использовать голосовые технологии для отдачи прямых командных директив будет ничуть не сложнее, чем для манипулирования объектами (на мой взгляд, даже легче).
В итоге я остановился на определении "визуальные интерфейсы", так как зрительный контроль действий в них абсолютно необходим. В отличие от сред командных, где теоретически вполне можно представить стучащего по клавиатуре вслепую оператора, обращающего взгляд на экран только для созерцания результата. Или - не обращающего вовсе, если результат его не очень интересует.
Для примера: вы пытались когда-либо объяснять по телефону, как выполнить с помощью компьютера некое действие? Если да - знаете, что при использовании DOS это вполне проходило, в Windows же - получалось скверно...
Так что впредь я применительно к интерфейсам, основанным на манипулировании объектами, призываю употреблять термин "визуальные" (за неимением пока лучшего). Исключительно как антитезу интерфейсам командным, предполагающим управление прямыми директивами. Собственно же слово "графический" следует оставить за определением режимом, альтернативного режиму текстовому, как было сказано в предыдущем параграфе.
Разумеется, между используемым режимом и типом интерфейса на практике есть некоторая, хотя и не однозначная, корреляция. Так, при консольном доступе (вне зависимости - в чисто текстовом же режиме или во фрейм-консоли) пользователь фактически обречен на использование той или иной разновидности CLI. Для чего ему служат программы класса командных оболочек (shells): одна из таких программ (login shell) запускается при авторизации в системе и берет на себя ответственность за интерпретацию и исполнение вводимых пользователем директив.
Говоря об обреченности, я не имею ввиду фатального принуждения. Ибо пользователю в качестве login shell вольно использовать чуть ли не любую программу, в том числе и обеспечивающую ему нечто вроде визуального интерфейса. И программы такие имеются - знаменитый Midnight Commander тому примером. Поскольку, не смотря на свою сугубо текстовую ориентацию, в основе его лежит именно манипулирование объектами, осуществляемое комбинациями "горячих клавиш". Другое дело, что очень быстро для пользователя становится ясным, что mc не делает ничего такого, чего нельзя было бы выполнить (и обычно - гораздо быстрее и проще) прямыми командами оболочки, да и в принципе не способен ни на что большее.
Тут-то и приходит осознание обреченности - в хорошем смысле этого слова, обреченности на более эффективные приемы работы. Вопреки мнению классиков советской фантастики, я не считаю ущемлением свободы обреченность на что-то хорошее - например, на любовь хорошей девушки. И к тому же, свободы выбора - обречь себя на любовь девушки нехорошей, - отнять у нас никто не в силах. Или, паче того, на любовь Midnight Commander'а - впрочем, это отдает уже некоторой нетрадиционностью ориентации.
За своеобычное лирико-дидактическое отступление не извиняюсь. Потому что в графическом режиме корреляция с типами интерфейсов еще сложнее. Начать с того, что сама по себе оконная система X (а мы выяснили, что это - единственный универсальный способ обеспечения графического режима) никакого пользовательского интерфейса вообще не обеспечивает, а служит лишь метаинтерфейсом для клиентских программ.
Среди клиентских Иксовых программ выделяется два важнейших их типа, которые и способны обеспечить пользовательский интерфейс внутри оконной системы. Это а) эмуляторы терминала и б) оконные менеджеры.
Так вот, пользователь, запустив совместно с Иксами эмулятор терминала, оказывается в самой что ни на есть командной среде - том же login shell, что и в чистой консоли. Где он точно также, как и в консоли, может вводить командные директивы - в том числе и на запуск истинно графических приложений. С той только разницей, что функционирует его командная оболочка в Иксовом окне, а не в полноэкранном (хотя и виртуальном) терминале.
Правда, воспользоваться прелестями оконного интерфейса он пока не в силах - ведь средств управления окнами (открытия, закрытия, масштабирования, минимизации и даже переключения между окнами), - у него нет. Чтобы получить такие средства, ему требуется еще одна клиентская программа - менеджер окон. И вот это уже - полноценный визуальный пользовательский интерфейс, он же - GUI в традиционной терминологии.
Существует многие множества оконных менеджеров - представление о их количестве можно получить на сайте Window Managers for X(http://xwinman.org/). Они различаются своей функциональностью: одни обеспечивают только базовые средства управления окнами (масштабирования, перемещения, переключения) и соответствующие интерфейсные элементы (кнопки минимизации, развертывания и т.д.). Другие же имеют развитые средства запуска программ, управления запущенными приложениями и т.д.
Особый вид X-клиентов представлен интегрированными графическими средами или, как их еще называют, десктопами. В их числе - KDE, GNOME, XFce. От собственно оконных менеджеров они отличаются тем, что, помимо собственно средств управления интерфейсом, включают в себя еще некоторое количество пользовательских приложений: программы эмуляции терминала, файловые менеджеры, браузеры, почтовые клиенты и прочие коммуникационные программы, текстовые редакторы и даже офисные пакеты.
Традиционно интерфейсы командного стиля противопоставляются визуальным интерфейсам.Основанием чему - абсолютно разные механически (даже, я сказал бы, физиологически) приемы работы в них. Однако обращение с автомобилем и, скажем, лошадью также требует совершенно разных приемов и навыков. Что не мешает в обоих случаях достигать одной и той же цели (транспортировки чего-либо или кого-либо). С различным, правда, успехом в разных условиях.
Аналогично и с интерфейсами. Множество задач целесообразно решать с помощью командных директив - примером чему пакетная обработка текстовых данных. В то же время, скажем, обработку изображений обычно легче выполнить в визуальной среде (хотя и здесь роль команд не следует недооценивать). И потому наиболее эффективным оказывается сочетание командных и визуальных методов. Благо POSIX-системы предоставляют богатые возможности комбинирования тех и других.
