DataLife Engine > Linux > Дорога в KDE4

Дорога в KDE4


25 января 2008. Разместил: podpole
За последние несколько месяцев вышли две бета-версии, и объем программ, загруженных в репозитории исходных кодов, просто феноменален. На ежегодной конференции KDE, на сей раз проходившей в Глазго, были представлены текущие отчеты, экранные снимки и новые функции. Похоже, что мы стоим на пороге очередной революции рабочего стола KDE. Но те, кто ожидал получить от неминуемого релиза нечто вроде «пиршества функций», будут разочарованы: это «нечто» вам в принципе уже знакомо, если вы смотрели любую из бета-версий. Даже один из основных разработчиков KDE признает, что первый выпуск «четверки» предложит обычному пользователю не так уж много новшеств. «Версия 4.1 явно будет релизом рабочего стола, за который ухватится больше пользователей, по сравнению с 4.0», признался недавно в своем блоге Аарон Сиего [Aaron Siego]. KDE 4, несомненно, представляет собой плод чрезвычайных усилий: на уровне кода изменилось все. И это очень важно, ведь если цикл KDE 4 продлится столько же, сколько KDE 3, то на основе этих библиотек и API люди будут создавать приложения еще добрых лет десять – целый век для компьютеров. Но пользователи с ходу в восторг не придут. KDE 4 в этом начальном релизе – скорее каркас, чем интегрированное окружение рабочего стола. Революция в программировании приведет и к пользовательской революции: когда на новую платформу портируют большинство основных приложений KDE, перемена будет разительной. Иными словами, обычному пользователю придется подождать, пока разработчики приспособятся к новой технологии. Это смахивает на ожидание второго эшелона игр, реализующего потенциал новой консоли; надеемся, что ситуация с KDE 4 будет немного лучше, чем с запуском PlayStation 3...

Столпы мудрости
Лучший способ получить представление о том, как работает процесс создания KDE – а иногда как не работает – это сравнить программы двух последних ежегодных конференций KDE. Призрак KDE 4 маячит за обеими конференциями, но включаемые технологии и API, с которым будут иметь дело разработчики, меняются. В Дублине на конференции 2006 г. фигурировали Plasma, Phonon, Solid, Decibel, Akonadi. Почти год спустя, в Глазго, конференция Akademy занималась почти тем же, но с несколькими серьезными купюрами. Plasma исчезла полностью, как и Solid. И даже технологии, пережившие девять месяцев между конференциями, в Глазго появились со слегка смещенными акцентами. Презентация Decibel, например, шла под грифом «Что это такое и как его использовать» – непохоже на срез развития после месяцев напряженной работы. Базовые технологии 2006 года были вытеснены в 2007 другой
идеей – KDE Pillars [pillar – столб, англ.]. Этот сборник основных разработок, сгруппированных в русле конференции 2007 г., содержащий презентации, которые любой с хотя бы половинным интересом к KDE 4 просто обязан изучить. Для внешнего мира Pillars – лучший показатель того, что именно группа разработки KDE 4 считает наиболее важным в следующей версии. К удивлению, в Pillars вошли только две основные технологии из упомянутых на конференции
2006 г. – Decibel и Akonadi. Остальные будут для большинства людей в новинку, так как на Strigi, Flake, Sonnet и WebKit до этой конференции лишь изредка намекалось.

Самое интересное имя – Flake, хотя оно в большей степени связано с KOffice 2.0, чем с KDE 4.0. Это описание абстрактного уровня для документации и форматирования, вводящего такие вещи, как, например, цветовые пространства sRGB и CMYK, векторные описания точек, функция загрузки и сохранения в ODF и встроенные объекты в виде «фигур» в интегрированном офисном пакете KDE. Sonnet, с другой стороны, это довольно тщательно сделанный модуль проверки орфографии или «сервис словаря» – качественно иного масштаба, чем ряд других технологий в KDE 4, с которыми Sonnet роднят разве что высокие амбиции. Не довольствуясь ролью очередной библиотеки проверки орфографии, Sonnet намерен стать расширяемым, для удовлетворения потребностей в многоязыковой поддержке, переводе и даже грамматической проверке: разработчики KDE всегда славились предложением новых идей.

Поражает, как много изменилось за последние двенадцать месяцев. Этот период мог бы быть использован для шлифовки существующих библиотек и роста над прежним уровнем разработки. Но даже лучшие планы не работают и в коммерческом мире, как с Microsoft Vista или Apple OS X последней версии, и тем более не работают в мире открытого ПО, где большинству разработчиков приходится манкировать полным рабочим днем и семейными обязанностями во имя изменения мира. Возможно, как раз по этой причине многие вещи выпали из генерального плана выпуска KDE 4. Некоторые из основных технологий, описанных в январском номере, пострадали от нехватки разработчиков, либо внимание переключилось на новые технологии, занявшие их место.

Важнейшее изменение – полная переработка поискового механизма. Не так давно мы говорили об ажиотаже вокруг проекта Tenor. Его расхваливали как поисковую систему, способную «утереть нос всем». И даже термин «поиск» был недостаточно хорош для проекта Tenor, фактически являвшегося механизмом контекстуальных связей.



Но всего этого оказалось мало, чтобы дать должный импульс его развитию, и работа по Tenor тихо зачахла. Это обычная проблема любого рода разработки: реклама суперфункции, не подкрепленная своевременным и осязаемым выпуском, всегда будет создавать проблемы для всего проекта. К счастью для KDE 4, кончина Tenor оказалась лучшим для него подарком, так как два новых проекта моментально заняли опустевшее место, и на сей раз они работают.



Strigi
Пользователи и разработчики KDE уже давно признали потенциал мощного, обособленного, эффективного и проникающего поискового механизма. На языке современного рабочего окружения эти термины сливаются в так называемый семантической рабочий стол: возможность для различных документов и приложений сосуществовать и говорить друг с другом конкретным и прозрачным способом. Семантические столы сыграют ключевую роль в успехе KDE 4, и значительную часть этой функциональности представляет встроенный поиск. Известно, что инструменты поиска в Linux – отнюдь не диковина. Нам есть из чего выбирать, включая прекрасный Beagle в Gnome и мощную технологию поиска от ребят Google, которую мы рассматривали в LXF97.

Двенадцать месяцев назад в KDE был Kat, но все изменилось с внедрением еще одной новой технологии поиска, называемой Strigi (произносится «стриги», а происходит от латинского «strigi»: это скребок, которым в римских банях удаляли грязь с кожи, предварительно натершись маслом). Естественная реакция на это «Ой, нет, пожалуйста, не надо нам нового поиска»: ведь мозговой центр KDE известен привычкой формулировать великие идеи, оставляя за бортом такую «мелочь», как их осуществление.



Но Strigi обещает быть другим, и, пожалуй, является лучшим кандидатом на эту работу, чем его идейный предок Kat. Основной разработчик Strigi Йос ван ден Эвер [Jos van den Oever] грыз гранит ранних поисковых систем, что вдохновило его написать свою собственную. Хотя на вид Strigi мало отличается от предшественника, но, похоже, ему хватает силенок, чтобы стать еще одной новой поисковой системой. Главный его козырь – производительность: обычно она отталкивала пользователей от принятия решения на переход к использованию технологий поиска, а Strigi может похвастаться серьезным превосходством над аналогами. Превосходство достигнуто за счет использования потоков данных вместо загрузки всего содержимого файла, что не только снижает требования к используемой памяти до минимума (вечные путы других инструментов поиска), но и делает построение поискового индекса гораздо более управляемым.

Nepomuk
Механизм контекстуальных связей из Tenor не был забыт. Есть инструмент, идущий рука об руку с Strigi, который добавляет метаконтент, необходимый поисковому движку для распознавания типа данных. Он называется Nepomuk – возможно, лучшая в мире аббревиатура. Nepomuk – это ‘Networked Environment for Personalized, Ontology-based Management of Unified Knowledge’ [Сетевое окружение для персонализированного, онтологически-ориентированного управления унифицированными знаниями]; не бойтесь, нам тоже не по зубам это понять.

Nepomuk не является собственно KDE-проектом: это открытый проект, финансируемый Европейским сообществом. С учетом бюджета в 11,5 миллиона евро, это серьезная заявка на стандартизацию в данной области, которая только выиграет от всеобщего пользования одинаковыми инструментами. KDE 4 станет первым крупным проектом, использовавшим Nepomuk: Strigi позаимствует его запасы и стандарты для своего индекса. Идея заключается в нахождении связей между различными видами медиа-содержимого и построения контекстной структуры на базе этих связей. Допустим, вы в чате обсуждаете с кем-нибудь ранее полученное вами письмо.

Nepomuk сохранит ссылку c чата на электронную почту, а также любые дополнительные ссылки,



типа вложений и других участников беседы. У Nepomuk есть и аспект общения: вы делите определенные области базы контекстных данных с вашими сетевыми контактами. Например, упомянутый ваш собеседник получит доступ к тому самому электронному письму, и этот аспект предположительно определил наличие слова «онтология» в титуле Nepomuk.



WebKit
На прошлогодней конференции Akademy также намекалось на интеграцию некоторых изменений KHTML от Apple в основную ветку развития KHTML. Этого не произошло. По факту, развитие KHTML за последние 12 месяцев почти не продвинулось, и движок рендеринга web-страниц недостоин надвигающего релиза рабочего стола четвертого поколения. Ларс Кнолл [Lars Knoll], один из первоначальных разработчиков KHTML, допускает, что это произошло из-за отношения Apple к команде разработчиков KHTML после его ветвления ради использования в рамках web-браузера Safari. Но Ларс также говорит, что его мнение постепенно изменилось после того, как Apple в конце концов открыла WebKit для использования под свободной лицензией. WebKit содержит все модификации KHTML от Apple и многие другие дополнения для браузера. Сейчас разработчики стремятся добиться совместимости WebKit с KDE, хотя предстоит еще много работы, прежде чем это станет реальностью. Интеграция WebKit будет означать, что web-элементы в KDE будут предлагать такой же уровень совместимости, как собственный браузер Apple, Safari. Если возможности web-браузера мирового класса войдут в движок HTML KDE, это может преобразить конкуренцию в
мире браузеров. При проблемах с корректным отображением сайтов, с такими же проблемами столкнется и Safari от Apple, и исправить их можно будет быстрее.

Plasma
Наиболее предвкушаемая технология в KDE 4 – Plasma, всеобъемлющая функциональность для интеграции виджетов рабочего стола, т.е. «правильная» SuperKaramba. Но реализовать эту технологию чрезвычайно трудно. Бета-версия KDE 4 не сумела выявить большую часть ее потенциала; возможно, именно этот аспект KDE 4 больше
всего пострадал в плане скорости разработки. Несмотря на то, что она уже завладела сердцами и умами пользователей KDE, развитие Plasma страдает из-за того, что главный автор, Аарон Сиего, один из самых занятых людей, какие нам встречались. Он не только участвует почти во всех связанных с KDE конференциях на планете, но также активно продвигает открытые решения. Взгляните, например, на его презентацию в 2006 г. на TPOSCON (Транстихоокеанской конференции по открытому ПО), озаглавленную «Как OSS облагораживает общество», на Google Video.

Этот суматошный график нанес ущерб развитию Plasma, и заложенный в нее потенциал пока не раскрывается. В текущих бета-версиях KDE Plasma отважно заняла место по умолчанию на рабочем столе, но обычный пользователь поимеет с этого только симпатичные аналоговые часы – слабое оружие для революции. Мы все уверены, что Plasma еще покажет класс; посмотрите рассылки разработчиков KDE, и вы увидите, что здесь не хватает только четкого
плана развития и добавочных рабочих рук, но это не специфика KDE – такова природа всех решений с открытым исходным кодом.

Новые идеи «засвечиваются», и программисты предпочитают сначала убедиться в их работоспособности, а потом уж трубить об их возможностях. Именно такое происходит с Plasma, и в общем графике KDE 4 очень мало информации о развитии проекта. Это удивляет, если вспомнить, что Plasma – лицо KDE-технологий по части «украшательств», но и характеризует личность стоящего за ней разработчика. В конечном счете, разработчики KDE 4 уверены, что финальные версии их рабочего стола заткнут критикам рты. Отсутствие промежуточных обновлений означает лишь напряженную деятельность разработчиков, а не отсутствие прогресса.

Альфа- и бета-версии KDE 4 продемонстрировали построение кодовой базы Plasma, но не виджеты и приложения, ожидаемые пользователями, а ведь именно они, более чем что-либо другое, будет влиять на прием, оказанный KDE4.



В новой версии найдется мало такого, с чем пользователи смогут «поиграть». Но так же было и с первоначальным релизом SuperKaramba. Важен потенциал технологии, и это касается всех работ, ведущихся в KDE 4. Да, старт будет трудным, и неизбежны жалобы пользователей, что по сравнению с KDE 3.5 ничего не изменилось, но здесь заложен мощный потенциал, реализуемый только через новые уровни абстракции, новые библиотеки и API – то, над чем напряженно трудится команда разработчиков KDE. Пусть даже по первости KDE 4 будет вылитым KDE 3.5, только чуть быстрее и чуть красивее: это уже неплохо. LXF