На страницах этого блога мы не раз упоминали видение разработчиков будущего «ориентированного на задачи» окружения. Идея заключается в том, что когда вы переходите от одного вида деятельности к другому, рабочее окружение должно перестраиваться под каждую задачу. Пока что это отражено в пользовательском интерфейсе исключительно в виде концепции activities (что до недавнего времени в русском переводе было «занятиями», но сейчас является «комнатами» — да простят меня переводчики, но «занятия» мне кажутся более подходящим словом). Сейчас занятия — это всего лишь группы виджетов, между которыми можно переключаться с помощью всеми любимого зум-интерфейса (или виджета переключения занятий), а с выходом Plasma Desktop 4.3 занятия стало возможным ассоциировать с виртуальными рабочими столами.

Что же сами разработчики хотят от занятий? Занятие может включать в себя группу окон различных приложений; файлы, ассоциированные с проектом; группы контактов и т.д. Идея в том, чтобы работая с одним занятием, вы как можно меньше отвлекались на другие — так что почтовый клиент будет отображать только письма, ассоциированные с занятием,  чат-клиент спрячет лишние контакты и комнаты, а браузер уберёт подальше вкладки с анекдотами и прочими вконтактами.

Конечно, это видение включает многое из того, что пока ещё не реализовано в приложениях KDE, однако немалая часть низкоуровневого кода для поддержки занятий уже написана. В частности, для KDE SC 4.4 реализована поддержка занятий в подсистеме управления метаданными Nepomuk, так что любое приложение может «поинтересоваться» у этой подсистемы, какое занятие сейчас активно (правда, в KDE SC 4.4 ни одно приложение этого пока ещё не делает).

Chani Armitage пишет, что примерный план реализации связанных с занятиями возможностей выглядит так:

• KDE SC 4.4: зум-интерфейс всё ещё присутствует, но единственная его уникальная возможность — перемещение виджетов между занятиями. Nepomuk может сообщать приложениям, какое занятие сейчас активно.

• KDE SC 4.5: KWin научится ассоциировать окна с занятиями и показывать их только при активации соответствующего занятия. Одно окно может быть ассоциировано с любым количеством занятий (по умолчанию новые окна показываются во всех занятиях). Вместо зум-интерфейса будет введён «менеджер занятий». Прощай, ручка слива cashew в углу экрана, мы будем скучать!

• KDE SC 4.6: KWin будет сохранять и восстанавливать сессии (т.е. состояние окон), связанные с занятиями. Приложения начнут предлагать возможности по отображению данных, специфичных для занятий. Возможны эксперименты по автоматическому назначению занятий для новых окон.

• KDE SC 4.7: ???

• KDE SC 4.8: Profit!

Со времени выхода KDE 4.0 Аарон Сейго и товарищи уделили немало времени, реализую всё новые и новые возможности в Plasma. Для KDE 4.4 это верно, как никогда. Вместе с ростом кодовой базы, насчитывающей тысячи строк, расширялась и пользовательская база, а также сфера использования — особенно с перспективами выхода версий Plasma для мобильных устройств и нетбуков. Растёт также и количество ошибок: на KDE Bugzilla сейчас насчитывается около 740 открытых отчётов о неисправностях, связанных с проектом. Это не настолько плохо, как могло бы быть (одна ошибка на 240 строк кода), но всё же далеко до идеала.

Исторически январские релизы Plasma приносили большее количество новых (и значительных) возможностей, в то время, как в июле было больше исправлений ошибок и менее значительные нововведения. По мнению Аарона Сейго, после выхода KDE 4.4 самое время заняться «наведением лоска», а потому он предлагает ввести временный мораторий на добавление новой функциональности Plasma.

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

На чём же стоит сейчас сосредоточиться?

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

Вместе с тем, Аарон высказывает опасение, что концентрация на исправлении ошибок может отрицательно сказаться на мотивации разработчиков. Тем не менее, другие разработчики идею Аарона поддержали.

Не пугайтесь акронимов в заголовке, просто Gary Greene начал работу над полной (по возможности) поддержкой Exchange для персонального информационного менеджера KDE, о чём и сообщает в своём блоге.
Основным мотивом послужило желание избавиться от необходимости иметь дело с Outlook и Entourage с одной стороны, и Evolution — с другой.

MAPI (Messaging Application Programming Interface) можно перевести как «прикладной программный интерфейс почты», и его поддержка — это опция номер один, если вы хотите, чтобы ваш почтовый клиент умел общаться на равных с сервером Microsoft Exchange.

MAPI на своём веку повидал множество изменений, и является трудной, активно маневрирующей целью для F/OSS-проектов, пытающихся обеспечить совместимость с этим протоколом. Одним из таких проектов является библиотека Openchange: её интеграцией с KDE PIM и будет заниматься Gary. Openchange, как реализации сервера Microsoft Exchange под управленим Unix, активно используется в Evolution, почтовом (и не только) приложении для среды GNOME.

Будет совсем не лишним, особенно для бизнес пользователей, иметь схожий уровень интеграции и в среде KDE.

Детали реализации поддержки MAPI

1. Основная цель — 100% паритет с Outlook в плане поддержки MAPI: Почта, Контакты, Календарь, Заметки, Журнал, Общие Папки, Задачи и Проекты.
2. Использование или неиспользование библиотеки openchange для реализации всего этого списка будет определяться на основе тестов и полноты функциональности.
3. Работа не будет вестись с нуля: за основу берется код, начатый в 2007 Brad Hards и доработанный Alan Alvares в рамках GSoC 2008.
4. Это будет Akonadi-ресурс, общающийся с Exchange-сервером на Extended MAPI/RPC, а с сессионным демоном Akonadi посредством D-Bus.
5. Где необходимо, будут задействоваться различные библиотеки проекта Samba4, чтобы мимикрировать под Active Directory-бэкенд Exchange-клиента, но по возможности, предпочтение будет отдаваться LDAP.

Далеко не секрет, что костыль, используемый в Palm Pre для работы с программой  iTunes Store недавно подвергся гонению. Прочитать об этом можно на новостных сайтах рунета, например, здесь, здесь, тут и вот тут.

В связи с этим, команда разработчиков Amarok решила написать открытое письмо, вот приблизительный смысл текста (на скорую руку): Читать далее »

Если вы следите за KDE Planet, то наверняка заметили очередной холивар вокруг KHTML и WebKit (а если следите давно, то знаете, что эта тема поднимается далеко не в первый раз).

KHTML нельзя назвать плохим продуктом. Не случайно ведь Apple, создавая WebKit, взяла за основу именно его. Но ситуация с современным развитием веба такова, что требования к браузерам и веб-приложениям стремительно растут, маленькие команды не успевают за этими изменениями, стандарты не отображают реального положения дел, а веб-разработчикам приходится во многих случаях адаптировать свой код для каждого браузера.

За разработчиками основных браузерных движков стоят большие организации и финансовая поддержка. За разработкой KHTML стоят три человека, которым просто нравится работать над ним в свободное время.

В результате, попытавшись воспользоваться единственным входящим на настоящий момент в KDE4 браузером, вы будете весьма ограничены в возможности использовать современные веб-приложения, игнорировать популярность которых просто невозможно. Но самое ужасное — многие дистрибутивы даже не включают в свой состав другие браузеры! Представьте себе впечатления человека, начавшего знакомство с Linux’ом с Kubuntu LiveCD. Не имея возможности даже воспользоваться своими любимыми веб-сервисами, он надолго потеряет желание повторять такие эксперименты.

Читать далее »

Как мы уже писали, в KDE 4.3 разработчики добавили поддержку нового протокола системного трея. Часть приложений уже переделали с учётом требований нового протокола, ещё больше программ планируется окучить к выходу KDE версии 4.4

Чтобы ещё больше порадовать пользователей, в текущем trunk реализована такая штука:

Обычный плазмоид в системном лотке

Plasma-виджеты теперь могут быть встроены непосредственно в область уведомлений — см. значок батареи на скриншоте выше. Графического конфигуратора пока нет, но очевидно, что он появится в ближайшем будущем.

Если вы недавно собрали свежую версию KDE из разрабатываемой ветки SVN-репозитория и хотите лично опробовать новую фичу, откройте файл $KDEHOME/share/config/plasma-desktop-appletr, найдите в нём systray-секцию и добавьте новый пункт (здесь [Containments][3][Applets][63] используется в качестве примера):

[Containments][3][Applets][63][Configuration][Applets][137]
geometry=24,2,22,22
immutability=1
plugin=battery
zvalue=0

За новость сердечно благодарим Marco Martin aka notmart.

Разработчики KDE решили несколько изменить свою обычную схему работы, и открыли основную ветку разработки (то, что в терминах систем контроля версий называется trunk — «ствол») для возможности добавления нового функционала ещё до выхода стабильного релиза KDE 4.3. По сути это означает, что открыта разработка KDE 4.4. Таким образом, сейчас существует три основных ветви разработки KDE:

• стабильная ветвь, от которой отделяются релизы KDE 4.2.x;
• «стабилизирующаяся» ветвь, которая с выходом KDE 4.3 станет текущей стабильной веткой;
• нестабильная ветвь (тот самый trunk), в которой ведётся работа над новыми и экспериментальными возможностями.

Не стоит пугаться: разработчики будут с не меньшим вниманием отноститься к подготовке релиза KDE 4.3 и исправлению ошибок в этой ветке. К слову, KDE 4.3 RC 1 уже отделён от «стабилизующейся» ветки и планируется к выпуску 30-го июня.

С другой стороны, это изменение развязывает руки разработчикам, у которых имеются готовые патчи, которые не могут быть включены в KDE 4.3 из-за стабилизации этой ветки.

К сожалению, уже после отделения релиз-кандидата был обнаружен баг, связанный с именованием тем Plasma в KDE 4.3, из-за чего некоторые виджеты (в частности, Lancelot) выглядят неправильно при использовании plasma-темы Air. Эта ошибка уже исправлена в основных ветках KDE 4.3 и trunk, но останется в KDE 4.3 RC.

Недавно на OpenNet’е появилась заметка об инициативе Аарона Сейго по построению брэнда СПО. Заметка вышла короткая, и не все поняли, о чём там идёт речь. Впрочем, оригинальный пост Аарона также вызвал у многих ряд вопросов, на которые он постарался ответить.

Итак, в чём же суть проблемы?

Проблема в отсутствии узнаваемого бренда свободного десктопа. Приведу пример: пейзаж с зелёными холмами, синим небом и облаками, кнопка «Пуск» и значок «Мой компьютер» однозначно ассоциируются с Windows XP. А скриншоты Windows 7 легко узнать по картинке с рыбкой и изменённой панели задач. Достаточно бросить беглый взгляд, и сразу понятно, о какой системе идёт речь.

В мире СПО есть несколько узнаваемых брендов: скажем, коричневая цветовая схема однозначно ассоциируется с Ubuntu. Но Ubuntu — это всё-таки один из дистрибутивов (хотя у многих Linux уже и ассоциируется однозначно с Ubuntu), причём его варианты (Kubuntu, Xubuntu или Ubuntu Studio) могут иметь совершенно другой внешний вид.

Важно, что если Ubuntu ассоциируется с коричневым цветом, а openSUSE — с зелёным, это сильно размывает брэнд Linux’а вообще, тем более, что распространённость каждого отдельного дистрибутива на фоне конкурирующих ОС ничтожно мала.

Значит, Сейго хочет развивать брэнд KDE?

Нет, в перспективе речь идёт о развитии брэнда свободного десктопа вообще. Это потребует координации среди разработчиков разных рабочих окружений, и наверняка понадобится немало времени и усилий, поэтому Аарон начинает с более простой для себя цели — развитии взаимодействия с создателями дистрибутивов, чтобы они не выбрасывали характерные части artwork’а KDE, полностью заменяя их своими изображениями, логотипами и темами. Но на этом он останавливаться не собирается.

При правильном подходе должно находиться место и для самоидентификации дистрибутива и/или оконной среды: скажем, при использовании одного и того же узнаваемого изображения рабочего стола по умолчанию, на него могут также наноситься логотипы дистрибутива и рабочего окружения. Некоторые шаги к этому в KDE уже предприняты — скажем, чтобы отобразить свой логотип в меню Kickoff, дистрибутору достаточно заменить файл branding.svg.

Давайте везде напихаем логотипы с Tux’ом!

Дело не только в логотипах, тем более, если их в пользовательском интерфейсе становится слишком много, то они начинают раздражать. Однако, если в разных оконных оболочках на кнопке стартового меню будет изображён один и тот же логотип (вместо логотипа Gnome/KDE или дистрибутива), то это будет шаг в правильном направлении.

К слову, свободный десктоп — это не только Linux.

Почему столько внимания уделяется фоновым изображениям (»обоям»)? Всё равно каждый пользователь ставит фоном ту картинку, которая ему нравится!

Во-первых, в скриншотах обзоров новых версий дистрибутивов и оконных оболочек чаще всего всё-таки используются фоновые изображения, доступные по умолчанию. А обзоры играют важную роль в распространении информации о дистрибутивах. Гораздо больше людей будет судить о внешнем виде свободных ОС по статьям в online-журналах и популярных блогах, чем по разделу «Скриншоты» на LOR’е.

При этом «обои» — это очень заметная деталь интерфейса, особенно если учесть, что практически в любой обзор включается скриншот оболочки без запущенных приложений.

Во-вторых, не стоит недооценивать силу настроек по умолчанию. Многие начинающие не сразу найдут, где эти изображения можно поменять (и вряд ли именно это они будут искать). Усилия по построению бренда делаются именно для привлечения новых пользователей — опытных линуксоидов вопросы брендирования вряд ли интересуют.

При этом со времён KDE 4.0 уделяется немало вниманию качеству фоновых рисунков, включаемых в KDE по умолчанию. В KDE 4.3 их состав будет значительно изменён, причём новые изображения прошли через строгий отбор (далее такую ротацию планируется делать раз в год). Но что мы видим в распространённых дистрибутивах, вроде Kubuntu и openSUSE? Дистрибуторы почему-то не включают большую часть этих тщательно отобранных изображений в свои релизы.

В мире информации необходимы как эффективные методы обмена ей, так и способы ее хранения. В каждой современной системе используется несколько различных СУБД, каждая из которых обладает своими достоинствами и была выбрана для удовлетворения определенных нужд. Однако, разнообразие в форматах порождает проблему совместимости и совместной работы с ресурсами. Чтобы решить проблему дублирования данных и несовместимости форматов, был начат проект Akonadi — четвертый из рассмотренных нами столпов KDE4.

Akonadi создавался как расширяемая система хранения персональных данных и метаданных для настольных компьютеров, обеспечивающая одновременный доступ для чтения, записи и создания запросов. Помимо этого, Akonadi включает несколько компонентов, таких как поиск и кэш, позволяющий получить быстрый доступ к данным, и уведомления об их изменении.

Читать далее »

Ни для кого не секрет что релиз 4.3 должен принести много новшеств и улучшений. Например, KDE отступит от своего фирменного синего цвета в пользу более летнего, скорее всего зеленого. Все дело в том, что релиз 4.3 будет несколько большим, чем очередной набор дополнительных возможностей и исправленных багов.

Когда вышел KDE 4.0 это все же был концептуальный релиз, рассчитанный скорее на разработчиков — они должны были понять что ждет их в будущем и начинать портировать свои приложения на Qt4/KDE4. Для пользователей это был шок — их любимая среда рабочего стола превратилась в нефункциональное убожество и мало кто оценил по достоинству грядущие перспективы. 4.0 не был готов для повседневного использования.

Но время шло и к релизу 4.2 (тот самый «Ответ» на вечные вопросы) KDE достаточно повзрослел и окреп — он стал достаточно стабилен, функционален и на него уже можно было полноценно переселяться большинству закоренелых пользователей KDE3. А теперь пришло время релиза 4.3, который должен действительно уйти в массы. Он более тщательно отполирован, содержит огромное количество новых и вполне стабильных идей, и по-настоящему выглядит как современный рабочий стол.

Читать далее »