Графічний інтерфейс користувача

До середини дев'яностих існували окремо комп'ютерна графіка і окремо — настільні ігри в комп'ютерну графіку. Ті з читачів, котрі пам'ятають історію вітчизняної шкільної інформатизації, можливо, стикалися з дивом техніки під назвою «цифровий дисплей растровий» (ЦДР), яке вдавалося підключити до першого вітчизняного персонального комп'ютера ДВК, щоб відображати на екрані телевізора декілька тисяч пікселів в чотирьох кольорах. У той час в Лабораторіях Комп'ютерної Графіки деяких вузів можна було зустріти Графічні Робочі Станції з векторними пристроями і X-терміналами, і навіть плоттерами.

Закон Мура тим часом робив свою (в даному випадку, не чорну, а багатоколірну) справу, і до середини дев'яностих на комп'ютері з процесором Intel 486 вже запускалася та сама система, яку п'ятьма роками раніше можна було спостерігати лише на X-терміналах і графічних станціях, що коштували якихось немислимих (що на ті часи, що на сьогодні) грошей. Ігри в саморобну графіку, звичайно, продовжуються і сьогодні, але в цілому світ возз'єднався, і особливої потреби в таких іграх давно немає. Хоча — така діалектика масових ринків — саме ці ігри (включаючи ігри в буквальному розумінні) породили попит на дешеві пристрої (перш за все, графічні акселератори), які і роблять справжню комп'ютерну графіку доступною користувачу масової x86- і PowerPC-техніки; навіть застарілі «персоналки» — співставними з X-терміналами, а новіші і могутні — суперниками професійних графічних робочих станцій початкового і середнього рівня.

X Window System і Xfree86

X Window System — один з найбільших і найуспішніших проектів в історії комп'ютерної техніки — бере свій початок у 1984 р., коли розробники двох систем комп'ютерної графіки, що претендують на універсальність, — проектів Athena (Массачуссетській технологічний інститут) і W Windowing (Стенфордський університет) — вирішили об'єднати свої зусилля. З тих пір практично кожна компанія, що серйозно займається графікою, вважає своїм обов’язком внести які-небудь розробки в систему, формальним «господарем» якої в 1987 р. став новостворений X Consortium (нині X Open Group, http://www.X.org).

З тих пір X пройшов через одинадцять основних реалізацій і безліч версій.

Подальший виклад орієнтований на вільну реалізацію X, яка називається XFree86, підтримується однойменною спільнотою (http://www.xfree86.org) і втілює на сьогодні версію 4.2 поточної реалізації. XFree86 — найпопулярніша реалізація X, вона поставляється у складі переважної більшості відкритих систем (як вільних, так і закритих) для x86-сумісних комп'ютерів, підтримує безпрецедентно широкий спектр устаткування і, завдяки доступності початкових текстів і призначенню для користувацької аудиторії в десятки мільйонів чоловік, достатньо «вилизана», принаймні, наскільки це можливо для такої різноманітності «заліза». Не дивлячись на те, що історично цифри «86» в назві пакету відносяться до відповідного сімейства процесорів від Intel, сучасні версії XFree86 реалізовані для більшості інших популярних процесорів. XFree86 доступний і для деяких ОС альтернативної архітектури, включаючи Microsoft Windows NT.

Більшість нижческазаного є справедливим для будь-якої реалізації X на будь-якому устаткуванні і під будь-якою ОС, список яких можна знайти на http://www.X.org.

Кольоровий сандвіч

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

Безпосередньо з устаткуванням (відеосистемою, пристроями вводу і динаміком) працює X-сервер. Ця програма захоплює устаткування і надає його можливості іншим програмам як ресурси (власне, саме тому вона і називається сервером) по особливому протоколу, який так і називається, X-протокол. Перераховане устаткування в сукупності називається X-терміналом (апаратним X-терміналом називається і спеціалізований комп'ютер, на якому виконується виключно X-сервер).

Тут відразу видно відмінність X Windows System від більшості саморобних графічних систем, котрі використовуються в пропрієтарних розробках: взаємодія X-сервера з його численною клієнтурою відбувається по специфікованому протоколу, який може тунелюватись через TCP/IP і, відповідно, клієнти і сервер можуть виконуватися на різних вузлах Мережі. Це означає, що одні і ті ж програми можуть експлуатуватися в різних топологіях, включаючи сукупність автономних робочих станцій («персональних комп'ютерів»), сукупність робочих станцій без даних або бездискових робочих станцій («локальна мережа»), багатокористувацьку систему з X-терміналами (або яку-небудь гібридну топологію).

Ще одним ресурсом, який надає X-сервер, є шрифти. Оперувати шрифтами він може самостійно, або за допомогою іншої програми, яка називається сервер шрифтів X і забезпечує їх масштабування.

Більшість користувачів, встановивши систему, одержують в своє розпорядження готове графічне середовище. Ми поступимо інакше — розбиратимемося з нею по шарах.

«Чистий» X

На Мал. 1 зображена «гола» система X Window — те, з чим більшість користувачів ніколи не стикаються. Запустити її звичайно можна так: X.

Ми бачимо традиційний сірий екран з не менш традиційним курсором у вигляді букви X. Використовуючи мишу або інший координатний пристрій, курсор можна переміщати по екрану. На натиснення кнопок миші і клавіш ніякої видимої реакції не слідує. І невидимої теж — сервер готовий передавати ці сигнали своїм клієнтам, а клієнти поки не запущені. Хоча насправді деякі комбінації клавіш X перехоплює і обробляє. Це Zap (Control-Alt-Backspace) — завершення роботи сервера (якщо ця можливість не заборонена при конфігурації), Zoom (Control-Alt-+/-) — «гарячіше» перемикання доступних відеорежимів. У деяких ОС (Наприклад, GNU/Linux) Control-Alt в поєднанні з функціональною клавішею звільняє устаткування і передає його на деякий час відповідної віртуальної консолі.

Скористаємося з останньої можливості, перейдемо на консоль і запустимо перший клієнтський додаток: програму xterm (Мал. 2). На екрані X знайшов з'явилося вікно, а у вікні можна бачити інтерфейс клієнтського додатку. В даному випадку інтерфейс текстовий, а додаток — емулятор терміналу, на якому запущена діалогова оболонка системи за замовчуванням. З емулятором можна робити все те ж, що і із звичайним терміналом: вводити команди, одержувати результат і запускати інші програми. Якщо програми текстові (рядкові або віконні), виконуватися вони будуть в тому ж вікні, а якщо графічні (як і сам xterm) — в окремих вікнах.

Запустимо програму xclock (Мал. 3). При її запуску ми використовували декілька параметрів, що задають геометрію (місцеположення і розмір) новоствореного вікна, колір його фону і шрифту за замовчуванням, товщину і колір рамки. Ці (і деякі інші) параметри типові для програм, побудованих на основі графічної бібліотеки X Toolkit. Значення параметрів, задані при виклику програми, можуть бути перекриті самим додатком, що запускається, окрім опції геометрії. Річ у тому, що вікно виділяється клієнтському застосуванню при запуску, і всі доступні йому ресурси цим вікном і обмежені — це властивість X-протоколу.

Запустивши декілька екземплярів того ж xterm (і почитавши документацію) можна виявити, що і «голий» X уміє не так уже й мало. Наприклад, оперує буфером обміну текстом між додатками і надає текстовим додатками такий ресурс, як смугу прокрутки (забавна смужка, скроллити текст за її допомогою вгору або вниз можна, клацаючи по ній різними кнопками миші, — це спадщина проекту Athena).

Чи є користь від системи, що працює з фіксованими вікнами? Так, якщо пригадати, що «універсальний десктоп» — не єдина сфера застосування комп'ютера. Можна запустити при завантаженні X і браузер на весь екран і одержати гіпермедійний кіоск за ціною PC. А можна посадити за той же браузер оператора, який буде через нього весь день «крутити» базу даних.

Але ми підемо далі. Отже, основная робота X-сервера — створювати вікна і надавати клієнтським застосуванням можливості роботи в них. Для того, щоб працювати з вікнами, потрібна інша програма, яка так і називається, — менеджер вікон (window manager).

Вікнотяги

Як же менеджер вікон долає вказане обмеження X-протоколу? Ніяк — просто виділеним йому вікном є весь екран. (Насправді, менеджер вікон — не єдина програма, здатна працювати з «кореневим» вікном; наприклад, xsetroot, що входить в комплект поставки, дозволяє встановити колір фону або помістити на нього малюнок.) Менеджерів вікон існує величезна кількість — під будь-який набір завдань, які може вирішувати графічна багатовіконна система. Їх настільки багато, що вибрати який-небудь як «типового представника сімейства» скрутно. Тому виберемо один з найрозвиненіших — Enlightenment.

«Просвіта» (http://www.Enlightenment.org) створена Карстеном Хайцлером і Джефом Харрісоном (Carsten Haitzler, Geoff Harrison) і його поточна версія — 0.16.5. До 2000 р. вона була «штатним» менеджером вікон в популярному середовищі GNOME (йому буде присвячена окрема лекція), потім поступилася цим місцем менш функціональній, але швидшій «Пилі-рибі» (Sawfish). Вона продовжує залишатися GNOME-сумісною, і багато користувачів цього популярного десктоп-менеджера віддають перевагу саме ій, хоч і без GNOME у Enlightenment прихильників вистачає.

Запустимо Enlightment (Мал. 4). Як різко змінилася картина!

Перше, що ми бачимо — це те, що навколо нашого вікна xterm з'явилися «віджети» (елементи вікон) — рядок заголовку з кнопками і рамка. Вікно тепер можна переміщувати по екрану, «схопивши» за заголовок, масштабувати, «узявши» за бік або за кут, максимізувати, мінімізувати або закрити, натиснувши відповідну кнопку. Питається, що ще можна робити з вікном?

Питання не просте. Натиснувши на ліву кнопку в заголовку, одержуємо несподівано різноманітне меню (меню — це теж «віджет») таких дій (Мал. 5). Виявляється, його можна ще знищити (Annihilate), підняти/опустити (Raise/Lower), затінити/розтінити (Shade/Unshade) приклеїти/відклеїти (Stick/Unstick) і виконати ще масу дій, для яких було потрібно окремі меню! Набір цих дій залежить від конкретного менеджера вікон (і Enlightenment — один з найбагатших можливостями), а те, які з них виведені в рядок заголовка окремими кнопками — взагалі від його настройки. Власне, управління вікнами — основна функція віконного менеджера, і на цьому його функціональність може і закінчуватися. Проте більшість з них виконують принаймні ще одну функцію.

Ви вже звернули увагу на те, що при запуску Enlightment на екрані з'явилося ще одне вікно? Це так званий пейджер (pager), на Мал. 6 він зображений крупним планом. На пейджері представлена мініатюрна копія екрану, що оновлюється в режимі реального часу, причому, якщо підвести курсор до зображення окремого вікна, воно збільшується і поряд висвічується назва додатку, запущеного в ньому. Але чому екран займає тільки чверть вікна пейджера? Тому що віконний менеджер дозволяє оперувати «віртуальним столом, що перевищує розмірами фізичний екран, а пейджер — один із засобів переміщення фізичного екрану по робочому столу. Enlightenment дозволяє створювати до 64 екранів на робочому столі. Ще один важливий компонент Enlightenment ми не побачили відразу: це меню настройки самого менеджера, яке можна «дістати», клацнувши правою кнопкою миші на тлі екрану (Мал. 7). Порившись в настройках, можна виявити, що вищесказане про способи операції з цим менеджером вельми умовне, тому що поміняти можна буквально все, від декору віджетів до кількості і функцій елементів оформлення вікон і їх реакції на різні дії.

Лише один приклад: скільки способів візуалізації переміщення вікна ви знаєте? Розробники «Просвіти» придумали цілих шість, включаючи фантастичний «напівпрозорий». Настройки і розширення Enlightenment можна об'єднувати в «теми» (themes) і обмінюватися ними.

Власне, на цьому функції віконного менеджера як такого і закінчуються, а далі Enlightenment вторгається у володіння іншого класу програм — менеджерів робочого столу...

Столоначальники

...що демонструє відсутність різкої межі між ними. Існує два підходи до того, щоб добудувати віконну систему до повнофункціонального середовища. Перший — додати в «графічний сандвіч» ще один шар — менеджер робочого столу — що працює «поверх» віконного менеджера і використовує функціональність останнього. Цим йдуть команди розробників GNOME і KDE, яким присвячені окремі лекції.

Інший шлях — «дотягнути» до повнофункціонального середовища функціональність самого віконного менеджера, і ним йде Enlightenment і ряд інших проектів.

Чого ж нам не вистачає до повнофункціонального середовища? Менеджера програм, інструментів і додатків. Так от, в Enlightment є така функціональність, доступна (стандартно) по клацанню на тлі лівою кнопкою.

Коментувати тут особливо нічого: пункти меню дозволяють запустити безліч різних додатків, причому, окрім незалежно розроблених, і цілу пачку «апплетів», що поставляються разом з Enlightenment. Альтернативний спосіб запуску — через «панель» — вбудований в деякі теми «Освіти».

Звідки беруться такі ресурси, як «віджети» з їх декором і способом поведінки? Звичайно, менеджер вікон може містити їх в собі. Але такий підхід не дуже характерний для відкритих систем, одним з принципів розробки яких є компонентність. Більшість розвинених віконних менеджерів, менеджерів робочого столу і «заточених» під них додатків можна згрупувати по бібліотеках (toolkits), з опорою на які вони розроблені.

Тріумф інтерфейсу над користувачем?

Косметичних поліпшень за тридцять років існування парадигми WIMP була придумана маса, а ось більш менш серйозних, при уважному аналізі, виявляється тільки два: інтеграція звуку (і перетворення графічного (візуального) середовища в сенсуальне) і початок експлуатації концепції гіперпосилань, в термінах яких можна переформулювати майже весь інтерфейс.

Фредерік Брукс ще в 1995 р., обговорюючи основні процеси та події в програмній галузі за попередніх 20 років, назвав в числі «найбільш вражаючих явищ» «тріумф інтерфейсу WIMP» сс. 239-243. У цьому чотирьохсторінковому аналізі, що став класичним (всім, що цікавиться темою, украй рекомендується прочитати ці чотири сторінки. А заразом — і всю книгу Брукса), Брукс:

  • проводить декомпозицію самої ідеї («діалог» з системою: об’єкти-«іменники» і дії-«дієслова»)
  • виділяє чинники, що сприяли її тріумфу (концептуальна цілісність через метафору «робочого столу»; еквівалентність клавіатурних команд пунктам меню, що забезпечує поступовий перехід від новачка до досвідченого користувача; нав'язування архітектури через засоби розробки)
  • називає обмеження метафори «робочого столу» («проблема двох курсорів»), а також
  • передрікає застарівання WIMP при впровадженні мовного інтерфейсу («WIMP через покоління стане надбанням історії. Вказівка курсором залишиться способом завдання іменників при управлінні нашими комп'ютерами. Для виразу дієслів стане використовуватися мова»).

Пройшло ще п'ять років, і ми можемо відзначити, що:

  • Проф. Брукс не побачив рішення «проблеми двох курсорів» (а заразом — і несуперечливої інтеграції командного рядка в графіко-інтерфейсне середовище) в кінці восьмидесятих в Norton Commander (і в сонмі послідовників цієї чудової програми на різних платформах (огляд див. в . Проф. Безруков запропонував для реалізованого в Norton Commander інтерфейсу термін «ортодоксальний менеджер файлів» (OFM));
  • WIMP не думає застарівати, і швидше сам абсорбує нові інтерфейсні можливості (включаючи розпізнавання мови), аніж буде витіснений ними;
  • і, нарешті, найсерйозніше — це те, що «тріумф WIMP» на сьогодні виглядає не те, щоб менш безперечним, а менш однозначним, все більш схожий на горезвісний «тріумфальний хід радянської влади» по знесилених Першою світовою війною частинам Російської імперії і її околиць. У багатьох прикладних областях спроби впровадження WIMP стали швидше частиною проблеми призначеного для користувача інтерфейсу, чим частиною її рішення.

«Суцільного» ж WIMP-середовища і зовсім немає ніде, окрім встроенных/спеціалізованих систем: у будь-якому оточенні, що претендує навіть не на універсальність, а просто на широку сферу застосування, елементи WIMP поєднуються з елементами іншої інтерфейсної моделі — командно-рядковій — іноді органічніше (OFM, AppleScript і т.п.), а частіше еклектично, суперечливо і з фатальним для продуктивності результатом (фрагменти «рваного» командного рядка в «діалогових вікнах», різноманітні Wizards і «вікна установки переваг»).

Якщо перечитати текст доповіді, в якій ідеї WIMP вперше були представлені широкій публіці, стане зрозуміло, чому: модель WIMP пропонувалася як засіб безпосереднього маніпулювання конкретними об'єктами («узяти це і покласти туди», «змінити таку-то властивість того-то об'єкту», а не як засіб формулювання абстрактних положень і команд («чи всі файли, лежачі в каталозі X, мають формат Y?», «видалити всі файли, створені до 01.01.2000 в яких згадується Борис Єльцин» і т.п.). Відповідно, зробити WIMP-робоче місце для виконання технічних процедур, «рабської», некваліфікованої праці можна, а ось систему підтримки повноцінної вільної практики — скрутно.

Від якого спадку нам не варто відмовлятися?

Віктор Вагнер протиставляє «рихлості» моделі WIMP, хай і цілісній метафорично, концептуальну цілісність командно-рядкового інтерфейсу (див. також нашу попередню лекцію), що ґрунтується на чотирьох принципах:

  • універсальності форми представлення інформації (текстовий файл, що розуміється як послідовність символів, деякі з яких розділяють рядки (записи), поля і слова;
  • можливості перепризначення введення-висновку і з'єднання програм каналами;
  • філософії «набору інструментів» (одна утиліта — одна функція);
  • наявності в оболонці механізму регулярних виразів.

По Вагнеру, по-справжньому успішним графічним інтерфейсом (true UNIX GUI) буде інтерфейс, що пропонує не менш цілісну і послідовно реалізовану концептуальну основу. Причому, що пропонує не тільки і не стільки кінцевому користувачу, скільки розробнику, тобто реалізований починаючи з системи швидкої розробки (RAD). У згаданій статті Вагнер розглядає декілька кандидатів на роль універсальної форми представлення інформації в графічному середовищі і міркує про те, які принципи могли б стати аналогами іншим «китам», на яких покоїться командно-рядковий інтерфейс.

Насправді, існує цілий ряд систем, що в тій чи іншій мірі закладають основу «інтерфейсів наступного покоління». На жаль, жодну з них не можна назвати на сьогодні масовою, окрім, можливо, мови опису інтерфейсу XUL, використаного в Mozilla (http://www.mozilla.org) і, відповідно, в Netscape 6 (http://www.netscape.com), але і для XUL поки немає RAD. Але це вже зовсім інша тема (див. лекцію 10).