Как известно, Amarok позволяет одинаково легко работать как с локальной, так и с внешними коллекциями, а также копировать и перемещать между ними дорожки. Однако порой простого копирования бывает недостаточно. Например, когда ваш портативный плеер не поддерживает формат, в котором лежат файлы локальной коллекции, или когда нужно уместить больше файлов на носителе. Или когда просто пользователь хочет перекодировать WMA-файлы, принесённые на флешке друга, в нечто более удобное.

Для этого в будущих версиях Amarok появится перекодировка на лету, над которой в рамках GSoC2010 работает Teo Mrnjavac и его наставник Nikolaj Hald Nielsen. При копировании дорожек пользователю будут предложены на выбор три действия — простое копирование, перекодировка с предопределёнными параметрами и перекодировка с собственными настройками.

Текущая реализация использует FFmpeg, но благодаря использованию в коде класса-»обёртки» разработчикам не составит труда перейти на что-то иное. Сам код практически готов, осталось интегрировать его в Amarok. Кстати, Teo уже участвовал в прошлогоднем GSoC — именно он добавил в Amarok многоуровневую сортировку в Списке воспроизведения.

Тем временем Jeff Mitchell занимается портированием плеера на QtSql, что позволит Amarok использовать не только MySQL/MySQL Embedded, но и SQLite. А также облегчит разработку варианта Amarok для мобильных устройств, над которым сейчас работает Jeff.

Правда, перед этим пришлось исправить несколько недостатков в самом QtSql. Прежде всего, Jeff реализовал отдельные драйверы для MySQL и MySQL Embedded, которые должны появится в Qt 4.8. Сейчас и для первого, и для второго используется один и тот же драйвер, причём выбор можно сделать только на стадии линковки (в Amarok этот выбор является обычной run-time опцией). Также он сделал возможным указывать собственные опции для MySQL-сервера (в частности, каталог для хранения БД), а не только определённые здесь.

После выхода Qt 4.8 и окончания работы по наведению некоторого порядка в исходниках самого Amarok (выделение ядра и платформо-специфичных участков кода в отдельные библиотеки, стандартизация пространств имён и заголовков) Jeff приступит к непосредственному портированию на QtSql и разработке мобильного интерфейса на Qt Kinetic.

На прошедшем в январе этого года KDE PIM meeting был анонсирован проект по портированию Akonadi и всех приложений KDE для работы с персональной информацией на мобильные устройства. В этом проекте принимают участие такие организации, как KDAB и Intevation, а также специалисты по шифрованию из G10Code и специалисты по юзабилити из Apliki (последние известны в сообществе KDE по тестам иконок KMail). Основными платформами являются Maemo и WinCE.

Уже имеются первые работоспособные прототипы, о которых рассказал в своём блоге Stephen Kelly, один из работников Intevation. Большая часть интерфейса написана на QML, для действий вроде развёртывания боковых панелей и прокрутки списка используются жесты. Вот так выглядит прототип мобильной версии KMail (все скриншоты можно найти в заметке Stephen):

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

Вчера (26 апреля) были объявлены студенты, прошедшие отбор на Google Summer of Code 2010. Мне повезло оказаться среди них. Авторы K Notes предложили мне рассказать о себе и своём проекте.

Обо мне

Я — студент Белорусского Государственного Университета, готовлюсь по специальности «Компьютерная безопасность». KDE использую с тех самых пор, как впервые установил Линукс (кажется, это был Mandrake Linux 10.1).

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

О проекте

Итак, этим летом я буду работать над добавлением функциональности диаграмм связей (mind maps) в KOffice.

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

На страницах этого блога мы не раз упоминали видение разработчиков будущего «ориентированного на задачи» окружения. Идея заключается в том, что когда вы переходите от одного вида деятельности к другому, рабочее окружение должно перестраиваться под каждую задачу. Пока что это отражено в пользовательском интерфейсе исключительно в виде концепции 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.