Обо мне

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

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

О проекте

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

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

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



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



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



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

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

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

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

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

Действительно ли разработчики Akonadi даже не рассматривали Sqlite? На странице проекта в Techbase говорится об обратном:

Почему не используется sqlite?

Мы пытались. Правда. Он не очень хорошо обрабатывает параллельный доступ к данным, что в лучшем случае ведёт к медленной работе, но у нас также случались блокировки (deadlocks) и ошибки транзакций. Как только это будет исправлено в sqlite, изменить Akonadi для его использования не составит проблем

Об этом же писал один из разработчиков Akonadi в рассылку kmail-devel ещё в октябре 2006-го года. Лично мне кажется, что за прошедшие с того времени годы им уже банально надоело отвечать на вопросы об SQLite.

Собственно, в разделе часто задаваемых вопросов на сайте Sqlite пишется следующее:

Несколько процессов могут открывать одну и ту же базу данных одновременно. Несколько процессов могут совершать операции SELECT одновременно. Но только один процесс может модифицировать базу данных. [...] Если в вашем приложении часто возникает необходимость в параллельном доступе к базе, вам стоит рассмотреть возможность использования клиент-серверной СУБД.

Akonadi изначально предназначен для того, чтобы предоставлять доступ к данным (в том числе и на запись) нескольким приложениям одновременно, и sqlite просто не проектировался для таких задач.

Конечно, если речь идёт о мобильных системах, то требования к параллельному доступу не такие критичные, в то время как ограниченные ресурсы не позволяют отдать на откуп Virtuoso 80-100 мегабайт памяти. Существует проект мобильного порта Akonadi, в котором как раз и используется sqlite, но он, к сожалению, развивается довольно медленно — последнее изменение датировано июнем 2009-го года.

Я только что узнал, что openSUSE всё больше и больше открывается сообществу. У них даже появился сайт http://features.opensuse.org, где любой может предлагать улучшения и изменения, и сообщество может за них голосовать. Я слышал, что 75% пользователей openSUSE использует KDE в качестве оболочки, и тем не менее, KDE не предлагается по умолчанию. Так почему бы не составить пожелание (feature request), и не посмотреть, чего хочет сообщество?

Я решил попробовать. Пожалуйста, голосуйте за мой запрос здесь: https://features.opensuse.org/306967

Эти слова появилась 28-го июля в блоге Фрэнка Карлитсщека (Frank Karlitschek), мэйнтейнера сети openDesktop.org (включающей KDE-Look.org, GNOME-Look.org, KDE-Apps.org и многие другие сайты) и KDE-разработчика. И не смотря на то, что к этой записи пришло всего 14 комментариев, она стала началом очередного грандиозного флеймвара, отголоски которого донеслись и до linux.org.ru. Ну а запрос Фрэнка остаётся самым популярным и обсуждаемым на openFATE — том самом features.opensuse.org, с 68% голосами «за» и 15% «против» (согласно прошлогоднему опросу пользователей openSUSE, 68% из них предпочитают KDE, а 27% — GNOME, так что Фрэнк всё-таки ошибся на 7%).

Исторически SUSE Linux был KDE-центричным дистрибутивом, но это начало меняться после того, как над ним получил контроль Novell. Кстати говоря, изначально Novell вообще хотел избавиться от KDE, но под давлением сообщества им пришлось смириться с его существованием. В openSUSE появился выбор рабочей среды при установке (сначала это был выбор между KDE и Gnome, затем — между Gnome и KDE). Но как утверждает Sebastian K?gler, за последние годы openSUSE всё дальше и дальше удалялся от того, чтобы быть лучшим дистрибутивом для пользователей KDE, да и многие разработчики KDE, которые ранее были пользователями SUSE, перешли на альтернативные дистрибутивы.

Он также отмечает, что решение оставить выбор рабочего окружения пользователям создаёт странный прецедент. При установке openSUSE вас не спрашивают, какой вы предпочитаете браузер, почтовый или IRC клиент или командную оболочку, есть также определённая предлагаемая по умолчанию файловая система. Тем не менее, новому пользователю всё-таки приходится отвечать на вопрос о выборе между Gnome и KDE (ни одна из опций не выбрана по умолчанию!), о которых он может ничего и не знать.

Надо отметить, что сейчас Novell является одним из крупнейших спонсоров KDE, а ещё год назад openSUSE считался единственным дистрибутивом, в котором «удачно собрали KDE 4.0″. Даже у меня тогда сложилось впечатление, что openSUSE выглядит как один из немногих дистрибутивов, где уделяют должное внимание KDE, и я решил попробовать на него перейти.

Что ж, openSUSE мне показался довольно неплохим дистрибутивом для неискушённых пользователей (одна только «установка в один клик» чего стоит), но с KDE в нём были явные проблемы. openSUSE 11 вышел через 5 месяцев после KDE 4.0, а openSUSE 11.1 — через 5 месяцев после KDE 4.1. То есть буквально через месяц после выхода свежего дистрибутива, используемая в нём версия KDE становилась морально устаревшей! Можно было использовать наиболее свежую версию из Factory-репозитория, но работа этих версия была очень нестабильная. Достаточно сказать, что я с openSUSE сбежал через месяц-полтора после выхода KDE 4.2,  и баг с невозможностью удалить виджеты (виджеты-то удалялись, но появлялись снова после перезагрузки) был так и не исправлен (естественно, в других дистрибутивах о таком баге даже и не слышали)! Надо ли объяснять, как неудобно экспериментировать с Plasm’ой, если я даже не могу толком удалять виджеты?

Проблема, однако, не в одном openSUSE. Достаточно сказать, что с выходом KDE 4.0 практически все дистрибутивы допустили ошибку с активным продвижением новой версии, ещё не готовой для всеобщего использования, хотя разработчики KDE и говорили, что этого делать не стоит. Если вы помните, именно в то время Линус Торвальдс громко заявил, что отказывается от KDE, поскольку в используемой им Fedora активно навязывается сырой KDE 4.0.

Со времён 4.0 разработчики дистрибутивов словно соревнуются, кто больше бэкпортирует кода из нестабильной ветки и внедрит в свой стабильный релиз KDE, из-за чего возникает ещё больше странных и неожиданных багов, за которые пользователи винят разработчиков KDE, а вовсе не дистрибутива. Так делают все дистрибутивы «большой тройки» — Ubuntu, Fedora и openSUSE (последний — особенно рьяно), и по странному совпадению, во всех трёх развитию и стабильности GNOME’а уделяется всё возможное внимание, в то время, как KDE является для них скорее навязанной опцией.

В любом случае, до тех пор, пока не появится простой, дружественный для новичков и что также немаловажно — заслуживший популярность (как раз по последнему пункту в последнее время сильно проигрывает Mandriva) 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.

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

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

Начнем прежде всего с этого вопроса. Я – обычный студент-недоучка Иркутского Государственного Лингвистического Университета. В свободное время увлекаюсь разными вещами, на ноутбуке использую Linux и KDE4. Учусь по специальности «теоретическая и прикладная лингвистика», здесь нас преподы в общем-то называют «технологи». На самом деле нам до технологов как этим преподам до осознания принципа open source. Есть у нас даже курс лекций под названием «Программирование в перспективных средах», где нам странный препод дает решать задачки на Delphi. В общем-то, для того чтобы научиться программировать язык как таковой не особенно принципиален, с другой стороны, каждый язык программирования определяет в какой парадигме вы привыкнете «думать». Это, конечно, имхо, но все же.

В этой статье я постарался не использовать конкретных имен, потому что кому надо – тот найдет, а кому не надо – незачем и говорить.

Знакомство с проектом

Я узнал о проекте KDE4 for Windows и стал пристально следить за его развитием. Конечно, сначала у меня интернета даже толком не было – сидеть с GPRS соединением по рублю за метр – это жестоко. Но уже тогда меня манило всеми правдами и неправдами попробовать. Затем пришел анлим и возможность такая предоставилась. Первым релизом, который я попробовал был 4.0.64, если мне не изменяет память. Идея того, что все приложения KDE можно будет использовать и на Windows меня заинтриговала. А большое количество багов только прибавило огня – с помощью удобной утилиты в составе KDE багрепорт по приложению можно было написать за минуту.

Примерно в это же время я стал часто сидеть в IRC на канале проекта. Там разговаривал с разработчиками, узнавал новости, выяснял интересующие меня моменты. Часто стал ходить на страничку проекта. Поначалу ставил все по описанию с той страницы. Что-то получалось, что-то нет. Бежал опять на канал, выяснял что да как. Оказалось что страница с инструкцией довольно сильно устарела, потому что документирование никогда не было сильной стороной разработчиков, особенно когда команда работает в поте лица из-за нехватки человекоресурсов. Тогда я предложил переписать инструкцию. Сел и минут через 30 она была уже готова. Отдал человеку, он проверил, поправил мои ошибки (как грамматические, так и смысловые) и внес изменения в страницу, которая работала на движке Wiki. Тогда я глянул на русский вариант этой же страницы и обновил и его тоже. По ходу дела я замечал, что нет пакетов локализации. Оказалось, их и не было никогда на этой платформе. Я пробовал качать файлы из SVN и переводить их, но это не особо получалось. Даже хотел попробовать вступить в команду переводчиков, но что-то как-то не заладилось с ними. Да и не пытался сильно.

Потом мне показали Commit filter – штука, которая посылает каждый коммит выбранного разработчика или в выбранный проект к вам на мыло. Так я стал следить за основными изменениями в коде. Естественно, в С++ я вообще не шарил, так, просто по комментариям к патчам и по ключевым словам BUGFIX, например, мог понять что тут кой-чего пофиксили, или тут добавили новую фичу.

Еще то тут, то там пытался делать какие-нибудь креативные работы. Пробовал делать MsStyle который бы привносил бы оформление окон в стиле Oxygen, а также стандартных виджетов (в приложениях KDE виджетам можно придать стиль Oxygen одной галочкой в System Settings).

В какой-то момент пробовал учить С++, с переменным успехом и начальными «победами». Качал книжки по программированию, но мало какие дочитывал до трети даже. Слишком сложно мне все казалось. А человек, с которым мы довольно сильно сдружились, все чаще стал намекать, мол, а этот баг ждет пока его пофиксишь именно ты =)

Первый билд

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

В то время я еще много качал разных дистрибутивов Linux, и у меня раздел на диске размером около 20 гигабайт был забит образами дисков. И тут случилось «несчастье» – при проверке очередного дистрибутива (проверял я их установкой в специально отведенный для таких проверок раздел) я по запарке форматнул все свое накопленное добро.

Надо еще отметить, что к этому времен я уже скачал книжку о программировании в Qt4 и начал довольно успешно продвигаться по главам. То, что для меня казалось жуткими танцами с бубном (вроде установки и настройки компилятора, не говоря уже о самой компиляции) оказалось совсем тривиальной задачей. Становилось действительно интересно.

И тут, когда в очередной раз мой друг в привате предложил мне скомпилить KDE из исходников я просто не смог найти оправдания чтобы не делать этого: места теперь у меня навалом, начальный чекаут на 128kbps – да у меня выходные впереди! Да и совсем недавно мне дали особые права на bugs.kde.org – я мог сам закрывать баги, а созданные мной репорты не нуждались в подтверждении (стандартный статус репорта – UNCONFIRMED, мои же создавались уже как NEW). И я решился на сборку из исходников.

Для поддержания действительно свежего состояния было решено использовать питоновый скрипт emerge, который был разработан специально для KDE for Windows и не имеет ничего общего с emerge из Gentoo.

Скачал питон, subversion, настроил переменные окружения, определился с утилитами и запустил первый билд. Сначала был чекаут Qt и его зависимостей, потом началась его компиляция. О, это был (и остается по сей день) адски долгий и мучительный процесс. Затем легче – kdelibs, kdebase-* и далее.

Уже тогда мне открыли секрет – портируется не что-нибудь, а то, что считалось привилегией только Linux и X11 рабочих операционных систем – сама Plasma!

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

Был момент когда из commit filter мне пришлось выбирать все патчи (а точнее номера коммитов), которые парни сделали для Plasma. Задача немудрёная, но все же было приятно, что попросили именно меня – мне очень хотелось быть полезным.

Первый патч

Как вы уже знаете, для установки KDE на Windows используется специальный установщик. В нем было много недостатков и до сих пор есть ‘room for improvements’, так сказать. И вот нашел я очередной баг: с очередным релизом их список изменился, но странным образом – один релиз из stable был продублирован в unstable. Так как в нестабильной ветке не было такого релиза, то соответственно и установщик попадал впросак при попытке выбрать именно его. Товарищ мой предложил мне покопаться в коде. А, чем черт не шутит. Полез смотреть… Так как мой наставник был более знаком с устройством установщика, то он сразу указал примерно в каких файлах нужно искать ответ.

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

Я корпел над смыслом этого отрывка кода порядочно. Перелистал его вдоль и поперек, на бумаге записывал последовательно значения всех переменных в каждый момент выполнения кода (я и сейчас не знаю как пользоваться такими утилитами в нормальных IDE, которые имеют возможность отслеживать эти данные, но меня это не сильно напрягает). Все впустую.

В следующий день я корпел еще дольше и таки смог найти ошибку. Но ведь найти ошибку – не все. надо еще ее исправить! Хм… А ведь я ни разу еще не писал ничего в чужом коде.. Аж даже растерялся что сделать. Полистал Assistant и нашел нужный мне метод. попробовал добавить его и… получилось! =)

Нет смысла описывать мои чувства на тот момент. Мой куратор объяснил мне как создать патч и сказал, что будет лучше, если я открою багрепорт и прикреплю к нему свой патч. Было жутко непосебе, ведь фактически это он нашел баг, и он навел меня на него, пусть и исправил его все же я… Я сделал как он просил и вскоре багрепорт был закрыт. #174452 – RESOLVED: FIXED

Модуль

С того патча прошло какое-то время. Мой куратор сказал что у него назрело задание для меня – написать модуль, который бы регистрировал plasma.exe как оболочку Windows вместо explorer.exe. Честно говоря, я был несколько напуган. Писать модуль… Да я понятия не имею как это!

Все было гораздо проще – сказали взять модуль попроще и выкинуть из него все ненужное. Ну, ломать – не строить! Скопировал модуль смайлов в отдельную папку, скомпилил – работает. начала медленно его кастрировать пока не осталась одна только форма. Скомпилил, установил. работает. Пустышка.

Чтобы с ней работать мой друг заставил меня подать прошение на SVN аккаунт. Нехотя, я все же сделал это, и почти тем же вечером я получил его! Мне выделили местечко в playground’е, где я взращивал свое детище. Кстати, свой первый же коммит я закосячил – не вписал log message >_< Ну, первый блин…

Так я начал работу над своим модулем. В него начал набивать мясо – первые пара виджетов для выбора между существующими оболочками. Данные читались из реестра с помощью функций библиотеки Qt, поэтому с ужасами WinAPI я имел счастье не встречаться. Зато по ходу узнал много полезного, и понял большую часть того, что читал в книжках. на самом деле, многие записи просто были непонятны мне. Но мой наставник помог. Он очень понятно мне все объяснял, так что в общем-то я вполне неплохо освоил это дело.

Потом понадобились еще функции, к ним еще виджеты, и новые заморочки – для установки «правильных» обоев я находил отношение сторон при текущем разрешении экрана и выбирал максимальное резрешение с тем же отношением сторон. Так что при разрешении экрана в 1152х864 мне установились обои с разрешением 1600х1200. С другим разрешением – другие.

Были по ходу исполнения идеи, реализация которых требовала использование WinAPI, но в итоге осталась только одна строка для установления атрибута «скрытый» у файла со списком установленных обоев (да-да, такой есть!).

Ближе к релизу 4.2 модуль был убран из playground… чтобы быть перенесенным в kdebase-runtime! Затем этот модуль, вместе с курсорами Oxygen, специально конвертированными для Windows, был упакован в отдельный пакет kde-additional.

Другие проекты

Кроме модуля я заглядывал и в другие проекты. Но только заглядывал – читать чужой код, сами понимаете, неудобно. В общем, только в KDiff я нашел и исправил баг (с появлением двух диалогов открытия файла). Мой куратор подталкивал меня заглядывать в другие проекты. например, когда он портировал Konsole, то предложил мне узнать в чем кроется проблема, что не дает стирать символы. Но этот код был мне не по зубам. Потом был Konvi4 (рабочее название Konversation для KDE4), в котором я также нашел пару багов, но был не в состоянии исправить их. Жаль, конечно, но, видимо, кодер из меня не очень хороший.

После некоторой передышки я для себя занимался колупанием Trayplayer’а с kde-apps.org – плеера без единой формы, который играл музыку, сидя в трее. Прикольная вещь, я почти прикрутил к нему плейлист, но нашел загвоздки и как-то подзабросил и его.

Время от времени я все еще обновляю свой билд KDE, но уже не так часто и баз такого энтузиазма. Надеюсь, это ненадолго. Может после сессии займусь..? Не хотелось бы забрасывать, и тем более не хотелось бы разочаровывать людей.

Это кросс-пост с habrahabr.ru (с небольшими правками :) — LXj)

UPD: Сегодня попробовал опять ковыряться в коде. В итоге смог найти как пофиксить крэш в Konversation4, однако, это был только фикс крэша, сама проблема была несколько глубже. Связавшись с Питером Симонссоном (Peter Simonsson), известным как psn на канале #konversation я обьяснил в чем проблема и он сделал три коммита, после которых смена кодировки работает и Konversation не падает при открытии диалога Identites! :D

Решения, принятые в 4.0, были приняты ради будущего. Будущего, в котором мы будем жить, начиная с версии 4.2, которая будет выпущена 27-го. KDE 4.2 — феноменальный релиз, и в отличие от KDE 3.5, который также был феноменальным релизом, этот новый релиз является платформой, на которой мы можем успешно развиваться и быть конкурентоспособными в следующем десятилетии. Он кроссплатформен, библиотеки гораздо чище, а технологии, доступные пользователю в KDE 4, соответствуют современным требованиям.

Выпустить 4.0 было чертовски сложным решением, которое стоило мне (и, полагаю, другим) бессоных ночей, но это было необходимо нам для того, чтобы избежать стагнации. И когда я говорю «нам», я имею в виду F/OSS десктоп, в том числе Linux десктоп. KDE 4.2 является подтверждением тех решений, и в то время, как 2008 останется крайне сложным годом (особенно для моих нервов ;), мы прошли этот период, и находимся в начале нового. Этот [новый] период продлится не один год, и позволит нам получить миллионы новых пользователей на самых разных системах.

Аарон Сейго о нашумевшем интервью Линуса

Добавлю, что сами разработчики говорили о том, что 4.0 не является релизом для конечных пользователей, но не смотря на это, некоторые дистрибутивы поспешили сделать переход на него. Также напомню, что если бы релиз KDE 4.0 не вышел бы в прошлом январе, мы бы так и не получили работающий релиз драйверов nVidia в октябре, и такой важный релиз, как сегодняшний, был омрачён для владельцев этих видеокарт.

Если вам не терпится узнать побольше о 4.2, то большой подробный обзор в двух частях (правда, на английском) можно найти здесь (часть 1) и здесь (часть 2)

Между прочим Аарон упомянул, что на этой неделе проекту KDE исполнилось 12 лет!

Ещё несколько случайных фактов:

• Разработчики называют Qt «кьют». В прочем, для меня это не новость.
• К концу года 15 миллионов бразильских студентов будут использовать в учёбе линукс-десктопы с KDE.
• В KDE приходит множество баг-репортов по поводу процессов вроде kswap (которые на самом деле процессы ядра)
• В чём принципиальное преимущество OpenStreetMap (открытого географического веб-сервиса, интегрированного в Marble) — все коммерческие электронные карты намеренно содержат ошибки, дабы по ним вычислять незаконных распространителей этих карт.

Очередной раз установил kde 4.0.x. Плюнул и стер – как вообще такое можно было выпускать? >>>>

Выпуск KDE 4.0 в том виде, в котором его, собственно, выпустили, прогнозированно вызвал немало нареканий. Хорошо хоть с выходом 4.0.2 обязательную огромную панель можно переместить и уменьшить. А вот другой заметный элемент интерфейса, небольшая инструметальная панель в правом верхнем углу (называемая разработчиками просто «toolbox»), вызывает споры даже среди разработчиков и по сей день. А сегодня в ленте KDE Planet была настоящая кульминация этих разборок.

Проблемы этой панели очевидны: у неё есть множество недостатков с точки зрения интерфейса (некоторые из которых уже были исправлены) и всего два использования. Как подметил Dirk Mueller, особенности toolbox’а таковы:

• он позволяет добавить виджет на рабочий стол;
• на нём есть кнопка «сломать мой десктоп».

Поясню второй пункт:

Аарон Сейго упирается руками и ногами от того, чтобы выкинуть toolbox. Подождите, говорит он, вы ведь ещё на самом деле не видели, что на самом деле должна делать кнопка «сломать мой десктоп» «Zoom out». Для начала давайте я доведу до ума зумирование, а потом вы уже и сами не захотите убирать его. Убрать toolbox сейчас — и нынешние пользователи не увидят его, когда он наконец-то заработает нормально. К тому же, проблемы нужны решать по-настоящему, а не искать способы обходить их. Всё-таки то, что создаётся сейчас, будет основой для KDE на долгие годы, так зачем так рано начинать добавлять грязные хаки и временные решения (которые имеют привычку становиться постоянными)?

Конечно, не все важные проблемы будут решаться сразу. Вопрос, который я должен себе задавать — не лучше ли написать программное обеспечение, которое можно будет использовать и через 10 лет, а пока не обращать внимание на (обычно мелкие) неудобства. Лично я больше не хочу переписывать с нуля оболочку рабочего стола. Никогда.

Что касается глюков в поведении самого toolbox’а — то их-то как раз нужно исправлять (и надо сказать, к сегодняшнему дню большую часть отрепортили и исправили, так что раннее включение его в интерфейс своей цели достигло), а не хаять саму идею.

Главная мысль aseigo — KDE 4.0 и KDE SVN не предназначен для так называемых «нормальных людей». Ими пользуются энтузиасты и тестеры, которых не пугают отдельные элементы интерфейса, связанные с не до конца реализованными фичами. Если же какой-либо дистрибутив хочет продвигать 4.0 как продукт, то это уже их дело спрятать шокирующую правду глючные части.

У внимательного читателя может ещё остаться вопрос: зачем заморачиваться с toolbox’ом, если есть те же контекстные меню? Проблем с контекстным меню две:

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

Всё это замечательно, но я всё же надеюсь, что когда функциональность toolbox’а будет реализована полностью, то Аарон всё-таки согласится добавить возможность скрывать его.