Для этого в будущих версиях 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.

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

Интерфейс остальных приложений организован по похожей схеме — стартовая страница, навигационное дерево со списком элементов и показ подробной информации в полноэкранном режиме. Увидеть всё это в действий можно на приложенном видео. Здесь видно, как Stephen использует мобильные версии KMail, KAddressBook и KOrganizer для получения данных с удалённого сервера Kolab (с которого получает данные и его ПК).

Хотя сейчас эти прототипы способны только на чтение данных, участники проекта планируют создать по настоящему мощный и многофункциональный PIM-проект, с большей частью достоинств и «вкусностей» настольных версий. Также следует помнить, что внешний вид, показанный на скриншотах и видео, не является конечным, над ним будут серьёзно работать после решения остальных важных проблем.

Обо мне

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

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

О проекте

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

На первой стадии я планирую реализовать все составные элементы диаграмм в виде Flake-форм. Flake – это низкоуровневая библиотека для отрисовки и управления содержимым в документах KOffice. Вот формы, которые я планирую сделать до окончания первых сроков:

• Блоки разной формы с текстом и, если надо, картинками внутри:



• Форма, объединяющая блоки в многоуровневые деревья, и оптимально распределяющая свободное место:



• Соединители с произвольной траекторией, управляемые двумя рычагами и соединяющие элементы:



• Формы для группировки элементов:

Вторую часть лета я проведу в работе над Braindump: интегрируя туда написанное и добавляя всякие фичи, попытаюсь довести его до уровня XMind.

Кстати, разработчики basKet проявили интерес к проекту, и тоже планируют использовать эти наработки у себя.

По ходу дела, постараюсь отписываться в свою живую ленту.

От редакции: мы будем рады, если другие русскоязычные участники GSoC также расскажут о себе и своих проектах на страницах K Notes. Пожалуйста, свяжитесь со мной по электропочте gotletter[at]gmail.com. И помните: мы знаем, как вас зовут и где вы живёте. Сопротивление бесполезно!

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

Конечно, это видение включает многое из того, что пока ещё не реализовано в приложениях 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!

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

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

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

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

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

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.

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

«Уважаемые Palm,

Когда вы выпустили Pre, все были восхищены великолепной работой, которую вы проделали. Все, кроме Apple, им не понравилась такая сильная конкуренция.

Вы решили применить обратную инженерию для базы данных «протокола» iTunes, который используется в устройствах Apple, и задействовать его в устройствах Pre. А это огромный плюс, синхронизация Pre с сервисом iTunes на обычном ПК или Apple без установки дополнительного ПО.

И вы не вкладывались в разработку собственного ПО для компьютеров, так как это не ваше направление. Ваше дело – продавать телефоны, не ПО. Однако я не думаю, что отдать на аутсорсинг эту задачу Apple было хорошей идеей.

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

Но, если у вас есть проблемы по этому поводу, если больше некому помочь, и если вы хотите разрешить текущую ситуацию, вы всегда можете нанять КОМАНДУ РАЗРАБОТЧИКОВ AMAROK!»

Далее следует рассказ о том, какой замечательный Amarok, о том, что он работает везде и нужно лишь немного времени, чтобы «вылизать» и стабилизировать код для Windows и Mac. Есть большая доля правды в этих словах.

Ах, если бы всё сложилось по самому лучшему сценарию?! Вот если бы команда разработчиков получила реальный заказ и финансовую помощь, быть может, одно из самых динамично развивающихся приложений под KDE стало бы лучше, стабильней, доступней. Это было бы уже другое свободное ПО…

Поживём, увидим.

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

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

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

Почему же KHTML до сих пор входит в KDE?

Есть ряд причин, по которым KHTML продолжает своё развитие. Во-первых, он используется не только в Konqueror, но и в KMail, Kopete и других приложениях. Из-за этого KHTML не может быть исключён из состава KDE, по крайней мере, на протяжении разработки KDE4.

Но самое главное — KHTML существует потому, что есть разработчики которые хотят над ним работать. Если человек работает над каким-либо проектом бескорыстно в своё свободное время, имеем ли мы право от него требовать, чтобы он вместо этого занялся чем-то другим, что его вовсе не интересует? WebKit — очень большой проект, над которым работает множество людей, многие из которых получают за это зарплату. Вячеслав Токарев говорит, что ему не интересно следить за работой такого множества людей и стараться успевать за ними.

Тут, конечно, играет роль и психологический аспект: если в команде KHTML каждый разработчик — «демиург», то влившись в команду WebKit, они будут одними из тысячи.

Таков закон развития открытого ПО: разработка должна поддерживаться мотивацией разработчиков. Если разработчик не хочет работать над чем-либо сам, или же ему не платят за это деньги, то наступает застой. Мы видим это на примере KDE Windows, который, при большом спросе на этот проект, развивается довольно медленно из-за сликом малого количества мотивированных разработчиков и проблем с взаимодействием между энтузиастами и работниками компаний. Мы видим, как при работе по несколько лет без релизов, как это было с KDE4 до выхода 4.0 и KOffice2 до выхода KOffice 2.0, многие разработчики теряют мотивацию и опускают руки. Мы видим, как разработчикам KOffice не интересно заниматься поддержкой форматов MS Office, а релиз KDE4-версии K3b появился на горизонте только после того, как Mandriva начала спонсировать его разработку.

А что же с WebKit KPart?

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

Сегодня, правда, один из разработчиков, работавший над этим проектом, признался, что есть гораздо более сложная проблема: Konqueror слишком глубоко интегрирован с KHTML, и простая замена KPart не приведёт к хорошему результату. Konqueror очень сильно завязан на API KHTML, а различия между KHTML и WebKit в настоящее время очень глубокие.

Вдобавок, как пишут многие разработчики, использующие QtWebKit, его развитие происходит довольно медленно. К примеру, в Plasma совсем не использует KHTML, а исключительно QtWebKit, и как пишет её главный разработчик Аарон Сейго, он разочарован текущим состоянием интеграции WebKit в Qt.

В комментариях к его заметке разработчик основанного на QtWebKit HTML-редактора также жаловался на отсутствие нужного ему функционала. Впрочем, представитель Qt Software Ariya Hidayat посоветовал разработчикам высказывать свои замечания на IRC-канале #qtwebkit.

Что ж, похоже, решения проблемы с KDE-браузером приходится ждать со стороны разработчиков QtWebKit и таких браузеров, как Arora и Rekonq. Оба этих проекта пока ещё находятся в ранней стадии развития, но обещают надлежащую интеграцию с KDE.

Чтобы ещё больше порадовать пользователей, в текущем 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 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.