Графический интерфейс Linux.

В.Костромин (http://rus-linux.net)

Как известно, операционная система Linux заняла достойное место на серверах, но пока еще не завоевала признания большинства пользователей персональных компьютеров. Не в последнюю очередь это объясняется тем, что о ней идет молва, как о системе, ориентированной на работу из командной строки, а поэтому “недружелюбной” к неопытному пользователю. Между тем, Linux обладает и графическим интерфейсом, не уступающим, а во многом и превосходящим возможности, предоставляемые известной всем оконной системой фирмы Microsoft. В этой небольшой статье мы попытаемся рассмотреть, как устроен графический интерфейс в Linux, и как настроить процедуры его запуска.

1. Устройство системы X Window.

Графический интерфейс в Linux строится на основе стандарта X Window System (заметьте, что Window, а не Windows) или просто "X" (в просторечии — "иксы"), разработка которого была начата в 1984 году. Первые 10 версий X Window System были разработаны всего тремя людьми - Робертом Шейфлером (Robert Sheifler), Джимом Геттисом (Jim Gettys) и Роном Ньюменом (Ron Newman).  Двое из них были сотрудниками Массачусетского технологического института, а третий – сотрудником корпорации DEC. Начиная с 1988 г. этот стандарт поддерживался консорциумом X, созданным с целью унификации графического интерфейса для ОС UNIX. В 1997 году консорциум X был преобразован в X Open Group (http://www.x.org). В настоящее время действует 6-ой релиз (выпуск) 11-ой версии стандарта на графическую подсистему для UNIX-систем, который кратко обозначается как X11R6.

Свободно распространяемая реализация стандарта X11R6 была создана группой программистов, которую вначале возглавлял Дэвид Вексельблат (David Wexelblat). Эта реализация известна как XFree86 (http://www.xfree86.org), и может использоваться не только в Linux, но и в других версиях UNIX для систем на базе процессоров Intel 80386/80486/Pentium (например, FreeBSD). В настоящее время выпущена уже 4-ая версия XFree86, о которой и пойдет речь в настоящей статье.

Операционная система UNIX с самого начала была многопользовательской, многозадачной системой, работавшей в режиме разделения времени. При этом она позволяла пользователям работать в удаленном режиме, либо через терминалы, либо с использованием сетевых технологий. Эти основные концепции были учтены при создании графического интерфейса для UNIX и поэтому система X Window построена на основе модели "клиент/сервер" [1]. Правда, модель эта в данном случае используется как бы в "перевернутом" виде. Дело в том, что X-сервер запускается на компьютере пользователя (а не на каком-то удаленном "сервере") и обеспечивает вывод изображения на экран монитора. Эта программа работает непосредственно с "железом" и обеспечивает управление как устройствами ввода (клавиатура, мышь и так далее), так и устройствами вывода (дисплей, монитор, динамик). X-сервер "захватывает" оборудование и предоставляет его возможности другим программам (клиентам сервера) как ресурсы (собственно, именно поэтому он и считается сервером) по особому протоколу, который называется X-протокол, или протокол сетевой связи (X Network Protocol). Кстати, специализированный компьютер, на котором исполняется исключительно X-сервер, называется (аппаратным) X-терминалом.

Если запустить только X-сервер, вы увидите просто серый экран с характерным крестиком курсора посредине. С помощью мыши этот крестик можно перемещать по экрану. И все! На нажатие кнопок мыши и клавиш никакой видимой реакции не следует. И невидимой - тоже! Дело в том, что сам X-сервер изображение не формирует, он только "доставляет" графику видеоадаптеру и передает сообщения о событиях от аппаратной части (в частности, от клавиатуры и мыши, то есть сообщения о действиях пользователя) своим клиентам, а клиенты пока не запущены. Хотя на самом деле некоторые комбинации клавиш X перехватывает и обрабатывает. Это <Ctrl>+<Alt>+<Backspace> — завершение работы сервера (если эта возможность не запрещена при конфигурации), <Ctrl>+<Alt>+<+> и <Ctrl>+<Alt>+<-> — "горячее" переключение доступных видеорежимов, и <Ctrl>+<Alt>+<F#> — переключение в другую виртуальную консоль.

Чтобы получить на экране какие-то более содержательные изображения, одного X-сервера недостаточно, надо запустить менеджер окон и хотя бы одну программу-клиент, которая будет формировать изображение и обрабатывать сообщения о действиях пользователя (например, щелчок кнопкой мыши и т.п.). В роли "клиентов" X-сервера выступают приложения, работающие с X Window, например, графический редактор GIMP, текстовый редактор OpenOffice.org, эмулятор терминала xterm и другие.

Между клиентами и сервером стоят еще два очень важных компонента графического интерфейса: библиотека графических функций X-Lib и менеджер окон.

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

Взаимодействие между менеджером окон и X-сервером осуществляется в асинхронном режиме путем обмена сообщениями. Клиентские программы открывают соединение с сервером, и затем просто посылают ему запросы примерно такого типа: “нарисуй прямую линию от точки такой-то до точки такой-то” или “выведи эту строку текста таким-то шрифтом начиная с такой-то позиции экрана”. Эти запросы, в основном, обрабатываются путем вызова соответствующих процедур из библиотеки X-Lib, которая содержит набор стандартных функций, которые обеспечивают выполнение низкоуровневых операций с графическими образами. Менеджер окон вызывает функции из X-Lib для управления дисплеем и выполнения любых преобразований изображений в окнах.

Надо сказать, что хотя элементы графического интерфейса (иконки, кнопки, диалоговые окна, линейки прокрутки, различные рамки и оконные меню) и прорисовываются на экране с помощью низкоуровневых функций из библиотеки X-Lib, но приложения не вызывают эти функции непосредственно, а обращаются к функциям более высокого уровня, которые в англоязычной документации называют виджетами – "widgets”. Ведь чтобы нарисовать, например, с помощью X-Lib простую кнопку с надписью «Ввод», необходимо прорисовать два прямоугольника, скруглить углы, изобразить тень, вывести надпись, обеспечить изменение вида кнопки при наведении мыши и так далее. Чтобы не повторять каждый раз работу по программированию часто используемых элементов графического интерфейса, были разработаны несколько отдельных библиотек таких элементов (виджетов). Эти библиотеки иногда называют "тулкитами" ("toolkit"). Наиболее известными из них являются библиотеки Motif, Qt и GTk. Библиотека Motif широко использовалась в 1980-х и начале 1990-х годов. Наиболее известным приложением, построенным на ее основе, является Netscape Communicator. В наше время эта библиотека уже не так популярна, поскольку появились более совершенные разработки, причем бесплатные (Motif распространялась на коммерческой основе). Библиотека GTk была разработана как замена Motif для проекта GIMP (GTk иногда расшифровывают как GIMP Toolkit или GNU Toolkit). Она сейчас очень популярна, потому что относительно невелика по объему, содержит много функций, расширяема и абсолютно свободна. Библиотека Qt получила широкое распространение с появлением проекта KDE, который использует ее для создания всех элементов графического интерфейса. Еще одной библиотекой, заслуживающей упоминания, является LessTif – бесплатный аналог Motif.

Если теперь все сказанное выше изобразить графически, получим рис.1.

Рис.1. Архитектура системы X Window

Конечно, рисунок этот очень схематичен. Рассмотрим,к примеру, обмен сообщениями между X-сервером и менеджером окон. Существует 4 типа сообщений, передаваемых между клиентом и сервером:

Запрос – клиент требует нарисовать что-либо в окне или запрашивает у сервера информацию;
Ответ – сервер отвечает на запрос;
Событие – сервер сообщает клиенту о событии (например, о нажатии клавиши пользователем);
Ошибка – сервер сообщает об ошибке.

Когда X-сервер и X-клиент работают на одной машине, обмен запросами и сообщениями между севером и клиентом осуществляется через локальный сокет. Но существует возможность передавать эти сообщения по сети, используя стек протоколов TCP/IP. Это свойство X Window является очень большим преимуществом этой системы в сравнении с другими типами графических оболочек, так как приложения могут быть запущены как на тоже машине, на которой работает X-сервер, так и на другом компьютере, который может даже не иметь собственной клавиатуры и мыши. Все, что нужно программе для работы, - это знать, где искать X-сервер (для этого используется либо переменная окружения DISPLAY, либо опция в командной строке). Более того, существуют даже программы (например, emacs), которые умеют работать и с X-сервером и с обычным текстовым терминалом и сами разбираются при старте, как именно им работать в данном случае.

Поскольку взаимодействие менеджера окон с сервером в общем случае осуществляется по протоколам TCP/IP, на приведенном рисунке следовало бы еще отобразить программное обеспечение, реализующее эти протоколы. Еще одним важным ресурсом графической подсистемы являются шрифты. Оперировать со шрифтами может как непосредственно X-сервер, так и специальная программа, которая называется сервер шрифтов, и которую также следовало бы включить в рисунок.

Можно еще отметить, что X-сервер может обеспечивать работу с несколькими "дисплеями" и "экранами" одновременно. Правда, термины “экран” и “дисплей” в системе X Window имеют специальное значение. Когда X-сервер запускается, он инициализирует один или несколько “дисплеев”. Каждый “дисплей” включает в себя не только видео-компонент, но и клавиатуру, мышь и другие устройства ввода. Конечно, отдельный пользователь в любой момент времени посредством одного комплекта устройств (монитора, клавиатуры и мыши) имеет доступ только к одному “дисплею”. Но имеется возможность запустить несколько “дисплеев”, которые могут быть как локальными (виртуальными), так и расположенными на других хостах, соединенных с данным компьютером по сети. Каждый “дисплей” может иметь собственную конфигурацию (например, другое разрешение). Пользователь может выбирать, какой дисплей он хочет использовать при входе в систему. Однако в самой типичной ситуации используется только один дисплей (с номером 0).

“Экран” ("screen") по отношению к X-серверу означает то изображение, которое вы видите, когда запускаете X Window. “Экранов” тоже может быть несколько, так же, как и “дисплеев”. Дополнительные “экраны" используются в случае “дисплеев с многими экранами”. Фактически имеется возможность использовать один X-сервер на несколько компьютеров.

Рассмотрение таких конфигураций выходит за рамки данной статьи, но знание этих фактов дает вам представление о той гибкости, которой обладает система X Window и о роли X-протокола в этой системе. Приложения можно запустить, например, на мейнфрейме, а картинка будет выводиться на экран персонального компьютера. Отметим еще, что в стандартном режиме запросы и сообщения буферизуются и обрабатываются сервером в асинхронном режиме, что позволяет повысить скорость работы и снизить нагрузку на сеть. При желании клиент может перейти на синхронный режим работы, хотя этот режим работает в 30 раз медленнее (так что обычно используется только для отладки программ).

Один и тот же X-сервер может одновременно использоваться многими приложениями. Для того, чтобы обеспечить одновременную работу различных приложений и уменьшить объем информации, передаваемой по сети, сервер для каждого из приложений хранит данные об используемых приложением шрифтах, информацию о цвете и многое другое. Эти данные в совокупности называются ресурсами сервера [2]. Клиенты имеют возможность ссылаться на эти ресурсы с помощью кодов ресурсов, сокращая тем самым сетевой трафик и облегчая доступ к данным для различных процедур.

Итак, вы теперь в общих чертах представляете, из каких основных частей формируется графический интерфейс в Linux. Как видите, строится он по модульному принципу, причем существует достаточно много вариантов выбора для каждой из основных компонент. Различных менеджеров окон, например, существует очень много [3,4], а набор приложений вообще необозрим. Так что и вы можете построить собственную графическую среду, использовав любой набор ее составных частей по своему выбору. Однако тут возникают некоторые проблемы.

Первая такая проблема связана с разнообразием тех подходов к взаимодействию с пользователем, которые применяются в разных программах. Некоторые приложения, работающие в графическом режиме, используют широко распространенные библиотеки графических элементов типа Qt или GTk, а другие строятся на основе собственных наборов графических элементов. Наборы графических элементов обычно не являются взаимозаменяемыми, поскольку используют различные программные интерфейсы. С другой стороны, не существует никаких ограничений или требований для разработчиков приложений как в части употребления тех или иных наборов графических элементов, так и в части, например, способов запуска программ (через меню, командную строку или набором определенной комбинации клавиш). Это, естественно, вызывает трудности в работе пользователей. Но более существенно то, что это вызывает нерациональные траты ресурсов компьютера. Если 6 разных приложений используют 6 разных библиотек графических элементов, то мы вынуждены как хранить эти 6 библиотек на диске, так и загружать их в память, хотя Linux (и UNIX вообще) поддерживают возможность использования динамически разделяемых библиотек.

Эти недостатки отсутствуют в так называемых интегрированных графических средах или оболочках. В таких средах все основные компоненты графического интерфейса, а также множество специально разработанных приложений, строятся на основе единой графической библиотеки и единого подхода к организации интерфейса. При этом графические среды типа CDE, KDE, GNOME, GNUStep и т.д. строятся по тем же принципам, которые были кратко описаны выше, и не замещают перечисленные выше компоненты системы X Window, а расширяют и дополняют их. KDE, например, использует библиотеку графических функций Qt и собственный менеджер окон kwm, который управляет поведением всех окон. Кроме того, KDE дополняет Qt своей особой библиотекой (kdelibs) для выполнения таких задач, как создание меню, диалоговых окон или окон сообщений, организации взаимодействия программ, печати, и других задач.

2. Запуск системы X Window.

Существует два основных варианта запуска графического интерфейса пользователя в системе Red Hat Linux. В первом варианте X-сессия запускается менеджером дисплея xdm, после чего пользователь получает возможность войти в систему (логироваться) непосредственно в графическом режиме. Во втором варианте пользователь вначале входит в систему в текстовом режиме, а потом запускает X-сессию с помощью программы xinit (чаще всего для этого используется скрипт startx, который является просто оболочкой для программы запуска графического режима xinit). В любом случае система X Window запускается с правами суперпользователя, поскольку ей требуется доступ к аппаратным устройствам.

Именно выбор между этими двумя способами запуска X-ов вы делаете, когда при инсталляции Linux задаете (или не задаете) автоматический запуск графического режима. Недостатком первого варианта (через xdm) является то, что если возникнут какие-то проблемы с переходом в графику, вы оказываетесь в затруднительном положении – ведь вы еще не вошли в систему и поправить что-либо нет возможности. Эта ситуация, конечно, не является безвыходной, однако начинающему пользователю все же лучше при инсталляции системы отказаться от автоматической загрузки графического режима и запускать его «вручную» из текстового. Как же это сделать?

Из предыдущего раздела вы уже знаете, что вначале необходимо запустить X-сервер. Это можно сделать, непосредственно запустив на выполнение сервер XFree86 из каталога /usr/X11R6/bin. В результате вы должны увидеть на экране серый прямоугольник с крестиком курсора мыши посередине. Если вы такого крестика не увидели, придется заняться настройкой X-сервера. Из-за ограничений, связанных с объемом статьи, я не могу подробно рассказать о том, как осуществляется настройка X-сервера и вынужден отослать вас к книге [5], где этот вопрос освещен достаточно подробно. Сейчас же мы предположим, что сервер успешно загрузился. Однако, кроме перемещения крестика курсора по экрану, вы от него ничего не добьетесь, поскольку не запущен менеджер окон и ни одной программы-клиента. Поэтому просто нажмите комбинацию клавиш <Ctrl>+<Alt>+<Backspace> для того, чтобы завершить работу X-сервера. 

Более правильный способ перехода из текстового в графический режим состоит в том, что вы даете команду xinit. Программа xinit (она расположена в каталоге /usr/X11R6/bin) предназначена для запуска сервера системы X Window и хотя бы одной программы-клиента в ситуациях, когда X-сервер не запущен непосредственно из /etc/init (то есть при старте системы) или тогда,когда используются несколько экземпляров оконной системы.

Если в командной строке не указано, какой именно X-сервер запускать, xinit ищет в домашнем каталоге пользователя файл .xserverrc, чтобы выполнить содержащийся в нем скрипт запуска сервера. Если такого файла нет, xinit по умолчанию выполняет следующий скрипт:

X:0

т. е. запускает программу с именем Xна дисплее с номером 0. При этом предполагается, что в одном из каталогов, перечисленных в путях поиска, найдется программа с именем X. Обычно такая ссылка создается в каталоге /etc/X11в командной строке запуска xinit не указана клиентская программа, которую надо запускать, программа xinit ищет в домашнем каталоге пользователя файл .xinitrc, чтобы выполнить его как скрипт, запускающий клиентские программы. Если такого файла не существует,  xinit по умолчанию выполняет вместо этого скрипта команду:

xterm-geometry +1+1 -n login -display :0

Если вы после установки Red Hat Linux еще не создали свой файл .xinitrc, и просто запустите команду xinit из командной строки, вы увидите почти пустой рабочий стол с единственным окном терминала (рис.   2).

Рис. 2. Команда xterm как единственный клиент X-сервера.

Поскольку менеджера окон нет, вы ничего не можете сделать с этим окном (переместить, изменить размер и т. д.), но вы можете в этом окне запустить другие программы, в том числе менеджер окон. Наберите, например, команду /usr/X11R6/bin/fvwmили /usr/X11R6/bin/twm (один из этих оконных менеджеров обычно по умолчанию установлен). После этого вид экрана несколько изменится (рис.3) , вы сможете перемещать окна (обычным способом, захватывая мышкой заголовок окна), а по щелчку левой кнопкой по пустому полю рабочего стола получите выход в меню. Можно запустить еще один экземпляр xterm или любую другую программу (на рисунке 3 вы видите два запущенных окна терминала и окно программы gimp).

Рис. 3. Запущен менеджер окон twm и программа gimp.

Если остановиться на таком способе вызова графического интерфейса, то каждый раз при его запуске придется повторять одну и ту же последовательность команд (не считая других минусов этого метода). Естественно, что пользователю стоит воспользоваться возможностью создания скрипта .xinitrc для автоматизации этой рутинной работы.

Ниже приведен пример скрипта .xinitrc, который запускает часы, несколько терминалов и оставляет менеджер окон в качестве "последнего" клиента.

#!/bin/sh

xrdb-load $HOME/.Xresources

xsetroot-solid gray &

xclock-g 50x50-0+0 -bw 0 &

xload-g 50x50-50+0 -bw 0 &

xterm-g 80x24+0+0 &

xterm-g 80x24+0-0 &

twm

Важно отметить, что программы, запускаемые из .xinitrc, должны запускаться в фоновом режиме, если только они не завершаются немедленно. Иначе эти программы будут препятствовать запуску других команд. Однако одна из запущенных программ (обычно менеджер окон или эмулятор терминала) должна выполняться не в фоновом режиме, а на переднем плане, чтобы работа скрипта не завершалась (завершением работы этой программы пользователь сообщает программе xinit, что закончил работу, и что сама программа xinit должна завершиться). В приведенном примере, если менеджер окон правильно сконфигурирован, то для завершения работы в X-сессии достаточно выбрать команду Exit в меню менеджера twm (это меню вызывается щелчком правой кнопки мыши на пустом поле рабочего стола).

Аргументы, заданные в командной строке вызова xinit, позволяют обойти выполнение скриптов .xinitrc и .xserverrc. В командной строке может быть указана альтернативная программа-клиент и/или альтернативный сервер. Клиентская программа должна быть первым аргументом в командной строке вызова xinit. Для того чтобы вызвать конкретный X-сервер, добавьте двойное тире (после указания программы-клиента и ее аргументов), после которого укажите имя нужного сервера. Приведенные выше картинки были, например, получены на втором экземпляре X-сервера, который запускался командой xinit -- :1 .

Поскольку пользователю-новичку обычно не хватает квалификации для создания собственного варианта скрипта .xinitrc, администраторы сайтов могут помочь им в вызове графического интерфейса, создав общедоступный скрипт, выполняющий эту функцию. Такие скрипты обычно называются x11, xstart,или startx и являются удобным способом создания простого интерфейса для пользователей-новичков. Вот пример простейшего скрипта такого вида:

#!/bin/sh

xinit/usr/local/lib/site.xinitrc -- /usr/X11R6/bin/X bc

При инсталляции стандартной версии Red Hat Linux создается более сложный вариант скрипта startx, который расположен в каталоге /usr/X11/bin (вы можете его просмотреть). Для него существует и man-страница, в которой говорится, что этот скрипт создается просто как образец для администраторов сайтов, и предназначен для создания собственных вариантов такого скрипта.

Если просмотреть стандартный вариант скрипта startx, мы увидим, что практически он сводится к выполнению всего-навсего трех команд:

xauthadd $display . $mcookie

xauthadd `hostname -f`$display . $mcookie

xinit$clientargs -- $display $serverargs

То есть, в конечном итоге, startx вызывает уже рассмотренную нами команду xinit, только предварительно формирует нужные значения аргументов командной строки для нее. Первый аргумент — имя файла xinitrc, причем если в домашнем каталоге пользователя есть файл .xinitrc, то берется он (с указанием пути), а если в домашнем каталоге нет такого файла, то берется общесистемный файл /etc/X11/xinit/xinitrc.

Аналогично формируется значение переменной serverargs: если существует файл .xserverrc в домашнем каталоге пользователя, то переменная serverargs будет указывать на него. Если такого файла нет, то serverargs укажет на /etc/X11/xinit/xserverrc. Переменной display присваивается значение :0. Далее в скрипте startx производится анализ аргументов, которые были заданы в командной строке при его вызове (эту часть мы пока не будем детально разбирать, поскольку для начала будем вызывать скрипт без параметров) и, наконец, в конец строки вызова xinit добавляется -auth$HOME/.Xauthority. Таким образом, сразу после установки системы (пока пользователь не создал файлов .xinitrc и .xserverrc в своем домашнем каталоге) будет вызываться в следующем виде:

xinit/etc/X11/xinit/xinitrc -- :0 /etc/X11/xinit/xserverrc -auth$HOME/.Xauthority

Команды xauth и опция -auth$HOME/.Xauthority, передаваемая X-серверу, служат для авторизации пользователя, запускающего графический режим. Механизмы авторизации нас пока не интересуют, так что рассматривать эту часть не будем (см. интерактивное руководство man с параметром Xsecurity).

Итак, мы вкратце рассмотрели, как организовать запуск графического режима из текстового. Если запуск графического режима отлажен и многократно испробован, можно организовать его автоматическую загрузку при включении компьютера. Для этого используется программа, которая называется менеджером дисплея (X Display Manager — xdm). Для того, чтобы запускать xdm при загрузке ОС, надо отредактировать файл /etc/inittab. В этом файле имеется строка вида

id:3:initdefault:

определяющая уровень запуска по умолчанию (об уровнях запуска рассказано в [5]). Замените эту строку строкой следующего вида:

id:5:initdefault:

Такое изменение заставляет Linux при запуске переходить на 5-й уровень. А в конце того же файла /etc/inittab обычно прописана строка

x:5:respawn:/usr/bin/X11/xdm–nodaemon,

которая означает, что на этом уровне запуска должен запускаться менеджер дисплея xdm.

Имейте в виду, что команда respawn в только что приведенной строке из файла /etc/inittab означает, что при попытках перезапуска системы будет происходить перезапуск менеджера дисплея. В частности, нажатие "магической" комбинации <Ctrl>+<Alt>+<Del> будет повторно запускать систему стой же конфигурации. Поэтому если вы после установки xdm будете как-то менять системные настройки и в результате ошибочных действий нарушите хрупкое равновесие системы X Window, вы попадете в очень затруднительную ситуацию. Именно поэтому, как было сказано выше, включать автоматическую загрузку графического режима при запуске системы стоит только после того, как процедуры его запуска отлажены и опробованы.

В случае использования xdm пользователь при входе в систему сразу попадает в графическую среду, и нет необходимости специально запускать графический интерфейс командой startx. При этом сохраняется возможность переключиться в текстовую консоль, набрав <Ctrl>+<Alt>+<F#>, а потом вернуться обратно в графическую среду, используя комбинацию <Ctrl>+<Alt>+<F7>.

После установки Red Hat Linux, например, строка в /etc/inittab, определяющая менеджер дисплея, имеет вид:

x:5:respawn:/etc/X11/prefdm–nodaemon,

а /etc/X11/prefdm есть ссылка на /usr/bin/kdm. На рисунке 4 вы видите типичную картину экрана после запуска интегрированной графической среды KDE. Вы можете видеть, что запущены программы эмуляции терминала, графический редактор gimp, почтовый клиент kmail, программа korganaiser и текстовый редактор OpenOffice Writer, в котором была создана настоящая статья.

Рис. 4. Вид экрана при работе в интегрированной графической среде KDE.

Литература