За разработчиками из проекта KDE "угнаться" трудно. Только на компьютере "побывала" версия 2.2.1 этой популярной настольной среды, как ей на смену вышел предположительно последний релиз системы семейства 2.x. И фактически с момента выхода новой версии она подвергалась автором разнообразным испытаниям пусть в невыгодных для системы, но абсолютно честных, с точки зрения потенциального пользователя, условиях.
Регалии
Начнем мы издалека — с вещей, которые на самом деле никакого отношения к программам не имеют. А именно, с титулов, наград и регалий, которых программы (и их разработчики) удостаиваются. В мире большого коммерческого ПО титулованность — один из самых важных, решающих факторов всех составляющих успеха. Не напрасно и не случайно Б. Гейтс объявил успех Windows XP в такой дерзкой форме: "Я очень счастлив, когда вижу такой уровень продаж, ведь отправка человека на Луну — это ничто по сравнению с разработкой Windows XP". Эту фразу перепечатали тысячи изданий (и даже автор статьи не избежал подобной печальной участи), и вот уже сомнения, возмущения и предсказания аналитиков отошли на второй план. Проект KDE — естественно, не корпорация Microsoft и представляет совершенно иной мир, но и в нем есть свои амбиции и титулы. Их полный перечень можно найти на сайте www.kde.org, мы же обратим внимание на ключевую фразу, характеризующую цель проекта, которой "открывается" его сайт, и всего одну, но весьма весомую награду. Итак, главная цель и характеристика KDE, по словам разработчиков, гласит: "KDE — это мощная, с Открытыми Исходными Текстами, графическая настольная среда для рабочей станции Unix". Ну а самая весомая награда — "Программная инновация 1998/99 гг.", полученная проектом на выставке CeBIT.
Такое весьма странное начало вовсе не случайно — ничего случайного не бывает. Раз уж KDE заявлена разработчиками как среда для "рабочей станции Unix" и раз столь уважаемая международная выставка, как CeBIT, удостоила проект такого титула, то руки можно считать развязанными. Что означает — никаких "поблажек" при эксплуатации KDE 2.2.2 и никакой снисходительности автор проявлять не собирается, "ведь отправка человека на Луну — это ничто по сравнению…" (здесь читатель может продолжить фразу сам).
Инновации и архитектура
Полученная проектом KDE в далеком по компьютерным меркам 1998 году награда CeBIT спонсировалась Ziff-Davis и присуждалась "не за коммерческий успех, а за креативность в дизайне продукта, исключительные решения специфических проблем или принципиально новые концепции". Одновременно с проектом KDE эти награды получили процессоры AMD семейства K6-2, видеоакселераторы NVidia Riva TNT и ATI Rage 128 и, наконец, Novell NetWare версии 5.
Что же принципиально инновационного было в проекте в те времена? Возможно, "привычный" дизайн, во многом схожий с оформлением "настольных" систем. Дизайном в мире рабочих станций Unix (вспомним цель и характеристику проекта) никто особенно не увлекался, классическая графическая оболочка CDE им, мягко говоря, не блещет, и симпатичный, с точки зрения не знакомого с ОС Unix человека, экран уже привлекает внимание. Но все-таки главной инновацией была архитектура системы, которая не столько интересна как застывшее явление, сколько крайне симтоматична в истории своего развития.
В одной из предыдущих статей мы уже обсуждали вопросы программной архитектуры, в другой — бегло обсудили проблемы middleware — основного связующего компонента, "клея", с помощью которого создаются большие программные системы. И если в предыдущих публикациях звучали больше рассуждения, то теперь настало время подкрепить их мнением практикующих разработчиков одного из самых ярких проектов в мире freeware: "Отказом от CORBA в пользу нашего собственного, оптимизированного под задачи middleware, мы смогли добиться большей гибкости, более тесной интеграции и высокой скорости как разработки, так и созданных программ". Все дело в том, что проект KDE в свое время использовал в качестве "клея" одну из реализаций де-факто стандартного механизма поддержки объектной архитектуры CORBA — Mico. Надо сказать, что выбор именно Mico был весьма удачным — это действительно очень неплохая реализация сложнейших стандартов CORBA, но сложность остается сложностью. И в случае с проектом KDE правило рационального программистского мышления сработало безукоризненно: если некоторая технология требует для своего использования N единиц времени на освоение и K — на использование, а ее возможности реализуются собственной разработкой, требующей L единиц времени, и если L N + K, то собственная реализация — рациональнее. Именно так разработчики KDE и поступили, создав два основных "клеящих" механизма, на которых строится вся система.
Первый механизм — DCOP, "настольный коммуникационный протокол" (Desktop COmmunication Protocol), очень близок к описанной в недавней статье о программных шинах организации Software Bus (SB). Так же, как и выдуманная абстрактная программная шина, DCOP использует в качестве коммуникационного канала сокеты, правда, его конструкция максимально упрощена за счет "привязанности" к технологии X Window. Активное применение мощных сервисов последней (а X Window на деле — куда более серьезная система, чем просто высокоуровневый драйвер видеокарты) — ICE (Inter Client Communication, "межклиентское взаимодействие") — позволило в кратчайшие сроки и с минимальными затратами создать крохотную, буквально в несколько сотен строк C/C++, реализацию весьма функциональной программной шины, расширяющей абстрактную модель SB возможностью обмена данными, преобразованными в последовательный поток (это в мире middleware часто именуется маршаллингом или сериализацией). Слово "настольный" в названии DCOP использовано очень метко — "общение" с помощью SB DCOP возможно только в пределах одного компьютера. По большому счету, это даже не ограничение, а весьма продуманный ход, позволяющий повысить защищенность рабочих станций, на которых выполняется KDE.
Второй механизм также вполне "укладывается" в рамки рассмотренных прежде абстрактных моделей. Его назначение — расширение возможностей "общения" между программами за жесткие границы одного компьютера, установленные DCOP. Для решения этой задачи разработчики KDE использовали очень симпатичные и простые идеи, положенные в основу системы поддержки распределенных вычислений XML-RPC ("XML — удаленный вызов процедур"). Для поддержания XML-RPC в KDE применяется постоянно выполняемая программа-демон kxmlrpc, реализация которой подкупает смехотворными размерами и простотой. По сути, kxmlrpc — это… не совсем обычный, но все же Web-сервер, транслирующий запросы, соответствующие спецификациям протокола XML-RPC, в сообщения программной шины DCOP. Выделение критичного к безопасности сервиса в отдельный демон, потенциальные возможности мониторинга всех обращений "из внешнего мира" к ресурсам компьютера и введения правил и политик управления "общением с внешним миром" — это не все достоинства архитектурной идеи KDE. Простота протокола XML-RPC позволяет не просто писать клиентское ПО на любых языках программирования, но и быстро разрабатывать интерпретируемые "облатки" для созданных задолго до появления KDE программ, без низкоуровневой модификации интегрируя их в единое целое с новыми приложениями KDE. И наконец, XML-RPC позволяет практически полностью "отрывать" пользовательский интерфейс действительно сложных приложений (в первую очередь, научных и инженерных) от реализации собственно семантической части программы.
Итак, с "клеем" KDE мы почти разобрались. После тяжких битв с тысячами страниц спецификаций и комментариев к спецификациям CORBA он не просто кажется смехотворно простым, он действительно прост. Что означает — прикладным программистам не нужно тратить годы на изучение служебных сервисов, никакого отношения к сути решаемой задачи не имеющим. Ну а там, где прикладному программисту "легче жить", там появляются и приложения, которыми легче пользоваться. Что, по большому счету, успех KDE подтверждает полностью.
Но вернемся к архитектурным "инновациям" KDE. Настало время называть вещи своими именами, и потому слово инновация в предыдущем предложении закавычено. На самом деле, никаких особых инноваций во всем описанном выше нет — все это в той или иной форме было задолго до появления самой первой версии KDE. С теми же проблемами "клея" столкнулись разработчики CDE, они использовали практически те же архитектурные решения (программная шина на основе механизмов ICE X Window и сокетов). XML-RPC — красивая идея, породившая SOAP (Simple Object Access Protocol, "простой протокол доступа к объектам"), также не является изобретением команды KDE. И все-таки, если уж и раздавать "призы симпатий", то идеологи и разработчики KDE заслуживают, по мнению автора, самой важной награды: "За трезвое отношение к технологии и здравый смысл". К сожалению, таких призов никто не присуждает…
Оставшаяся часть "инноваций" в KDE также ничего неожиданного не преподносит. Если "склеивание" в пределах одного компьютера специально созданных компонентов осуществляется фактически программной шиной, "склеивание" внешних по отношению к компьютеру компонентов — транслятором протокола XML-RPC в сообщения программной шины и, наконец, "вклеивание" классических приложений — скриптовыми "облатками" XML-RPC, то на внутрикомпонентном уровне в KDE используется тривиальная слоистая (layered) архитектура с объектно-ориентированными "отклонениями". Библиотеки (слои) — основа основ внутрикомпонентной модели KDE, с их помощью достигается и повторное использование кода, и стройная простая организация системы. "Каркас" (framework) библиотечной модели именуется KParts, и все приложения KDE являются "наполнениями" небольшого перечня "каркасных" моделей — part ("часть", объединяющая пользовательский интерфейс и его функциональность, способная становиться частью другой part), plugin ("вставка", не обладающий свойством включения в part расширитель функциональности, возможно, с пользовательским интерфейсом), part manager ("управляющий частями", абстрактный механизм, отвечающий за компоновку parts в единое целое, запуск и остановку их выполнения и т. д.) и, наконец — mainwindow ("главное окно" — абстракция, собирающая воедино под управлением part manager множество необходимых parts, а также plugins).
Приложения
По сути, KDE — не столько множество приложений, сколько инфраструктура для создания этих приложений. Но все же базовый набор (который в терминах KDE именуется kdelibs и kdebase) дает одно главное приложение, сегодня неизбежно попадающее в класс "убойных". Это, естественно, броузер-навигатор файловой системы Konqueror. Печальная судьба де-факто стандартного броузера Netscape, "привязанность" броузера Opera к ОС Linux и, наконец, медленное развитие Mozilla большого разнообразия в выборе пользователям ОС Unix не оставляют. Впрочем, благодаря Konqueror и легким текстовым броузерам ситуацию назвать ужасной нельзя. Konqueror неплохо справляется с отображением большинства сайтов, и интенсивная трехнедельная эксплуатация его не вызвала у автора серьезных нареканий. Кроме того, входящий в состав релиза 2.2.2 Konqueror весьма быстр (визуально ощутимо быстрее предыдущих версий) и не смертельно ресурсоемок. Но и это не главное. Главным на сегодняшний день достоинством KDE и ее лучших приложений остается локализация. Основанная на поддерживающем Unicode на всех уровнях проектирования тулките (библиотеке графических примитивов пользовательского интерфейса) Qt и хорошо поддержанная сообществами freeware-разработчиков разных стран в базовых приложениях KDE никаких проблем с локализацией не имеет. За исключением одной, вяло перетекающей из версии в версию, — переключателя языка для клавиатурного ввода. Добиться от него работоспособности принципиально можно, но, слава Богу, Unix всегда предоставляет более радикальные способы решения проблем. Впрочем, об этом позже.
Если вернуться к обсуждению Konqueror, то его разработчикам можно сделать много комплиментов. Несмотря на то что концепция Explorer-подобного файлового менеджера далеко не всем по душе (включая и автора статьи), Konqueror действительно хорош и в этой роли. Естественно, как и на десктопах пользователей ОС Windows, где прочно "поселился" какой-нибудь представитель Norton-подобной программы, для интенсивной работы с файлами дополнить Konqueror чем-то схожим (или по вкусу — аналогичным, например, каким-либо "последователем" XTree) необходимо. А вот для просмотра больших "свалок" документов, персональных сборников документации и архивов изображений Konqueror, без сомнения, хорош. Для каждого файла типа pdf или ps (Postscript), а также для всех файлов изображений и html он посредством прочих компонентов KDE строит пиктограммы, отображающие реальное содержимое файла. Процедура их построения не слишком быстрая, но, учитывая достаточно хорошо реализованное кэширование, она не раздражает. В части же возможностей Konqueror как броузера можно сказать одно — броузер как броузер, достаточно современный, естественно, со своими нюансами, но все же — легально бесплатный и работающий. В целом, он оставляет очень хорошее впечатление.
Второй элемент базового набора — "управляющий центр KDE". И если Konqueror хочется хвалить, то эта подсистема вызывает больше вопросов, чем хвалебных эпитетов. К сожалению, многое, что касается пользовательского интерфейса этого весьма критичного элемента, просто не продумано или явно делалось впопыхах. В нем слабо реализовано управление запуском компонентов KDE (точнее — никак), сравнительно небольшой перечень подменю настроек образует плохо сгруппированное месиво, в котором сугубо машинно-зависимые подсистемы могут соседствовать со свойственными только KDE настройками. Впрочем, это можно считать болезнью роста, и раз уж разработчики KDE поставили перед собой цель создать действительно пользовательскую среду для рабочих станций Unix, от "привязанности" к конкретному представителю многочисленного семейства Unix-клонов им неизбежно придется отказаться, по крайней мере, в "управляющем центре KDE".
Остальная часть базового набора приложений, по большому счету, особой ценности не имеет. У всех них есть аналоги, отличающиеся или большей функциональностью, или меньшей ресурсоемкостью, или еще какими-нибудь достоинствами. Оконный менеджер kwm, панель kpanel, масса всевозможных меню, пиктограммы, ассоциированные с файлами данных или приложений на Рабочем столе, — все это, конечно, хорошо, но совершенно не обязательно. KDE весьма некритична к собственному окружению, и если оно раздражает либо назойливым изобилием всех этих "красивостей", либо весьма высокой ресурсоемкостью, без ущерба для работоспособности и удобства от множества этих "погремушек" можно отказаться. Приложения KDE прекрасно "живут" под управлением ряда оконных менеджеров — BlackBox, IceWM, WindowMaker и других. В частности, WindowMaker позволяет "за бесплатно" радикально решить проблему переключателя языка благодаря прекрасно работающей собственной реализации этой важной функции.
Дополнительный набор приложений KDE весьма обширен. Очень хорош почтовый клиент KMail — весьма продуманная, удобная и приятная в использовании программа. Симпатии вызывает и ее "партнерша" — программа чтения новостей KNode. В принципе, комбинацию Konqueror + KMail + KNode можно считать главным "убойным" набором приложений KDE, и если бы кроме них в KDE ничего не было, проект бы все равно оставался исключительно удачным.
Качество утилитарных приложений в KDE достаточно высокое, но многие из них проигрывают своим конкурентам из мира классических Unix-задач. Так, программа просмотра файлов ps и pdf — Kghostview, несмотря на внешнюю симпатичность, далеко не так "всеядна", как ее древняя и "уродливая" предшественница — gv (многие pdf-файлы, созданные в распространенной системе подготовки документов FrameMaker, можно просмотреть только с помощью gv).
Всяческие игры и прочие "погремушки" из дистрибутива KDE автор не устанавливал, впрочем, потенциальные пользователи такой системы заинтересованы на самом деле не в них. А, естественно, в реальных возможностях KOffice — офисного набора приложений, в состав которого входят текстовый процессор, электронная таблица, графические редакторы и полукоммерческий аналог редактора диаграмм Visio — Kivio. Увы. Сегодняшний KOffice весьма далек от пригодного к реальному использованию состояния. Практически все программы из его состава ведут себя крайне ненадежно, и после недельного наблюдения за их "падениями" в результате самых невинных операций автор отчаялся добиться чего-либо удобоваримого от KOffice. Нестабильность работы пакета удивительна — крохотный eps-файл может быть прекрасно импортирован в KWord, вставлен в текст, но при попытке открыть этот же файл векторным графическим редактором Kontour (для которого векторный же eps — формат "полуродной") Kontour успешно "падает". То же самое касается и попыток сохранения невинно форматированного текста в rtf-формат из KWord — оно удается через раз. И т. д. и т. п. Возможно, нелокализованная установка KOffice работает намного устойчивей, но для реальной работы с русским и украинским языком пакет еще крайне "сырой".
Инсталляци и надежность
В соответствии с выдуманными для самого себя условностями автор устанавливал KDE 2.2.2 исключительно из исходных текстов, а в соответствии с заявленным разработчиками KDE "тотальным характером" системы — на два компьютера под управлением ОС FreeBSD 4.4. Процесс установки базовой системы можно считать удовлетворительным из-за "втянутого" в него сильно зависимого от ОС Linux единственного совершенно некритичного компонента. С подобной мелкой неприятностью неизбежно столкнутся и пользователи прочих (не Linux) Unix-совместимых ОС. В ходе инсталляции никакие "трюки" (подобные ставшему модным фокусу с динамическими библиотеками, именуемому objperlink) умышленно не применялись.
После установки система была подвергнута сравнительной проверке на "утечку памяти" — были запущены несколько приложений, и компьютер оставался включенным неделю. Для сравнения, тест на "утечку памяти" проводился без KDE — только с каноническими (но весьма ресурсоемкими) Unix-приложениями. Тест KDE, увы, не прошла, "выев" за неделю "летаргического сна" море памяти (такой же тест, но с запущенными задачами — представителями "Unix-классики", Motif- и Tcl/Tk-приложениями, утечек памяти не выявил).
В ходе неинтенсивной эксплуатации обнаружились и "болячки" броузера Konqueror — "падения" в совершенно непредсказуемых ситуациях (в первую очередь, при открытии больших html-страниц практически без графики и без java-скриптов) с интенсивностью 2—5 раз в день и до непригодности ненадежное поведение большинства элементов KOffice.
Бегло брошенный взгляд "внутрь" KDE, главным образом в исходные тексты реализации ключевых сервисов и протоколов, также не сильно порадовал. Знакомые каждому программисту C/C++ подозрительные размещения групп объектов переменного размера в буфере фиксированного размера (о, эти предположения о том, что все должно быть всегда так, как хочется программисту) здесь встречаются…
Не подводя итогов
Проект KDE — без сомнения, умный и нужный проект. Базовые, "убойные" приложения системы хороши, архитектурные идеи — также хороши. Остается надеяться, что проявленный в этом проекте здравый смысл и трезвый взгляд на технологии сохранится и в дальнейшем — тогда KDE действительно станет Очень Хорошей и Нужной Системой.