Здравствуйте!

В свое время я не без удовольствия прочитал замечательную статью «Гитаризм для линуксоида — why not?». И решил написать небольшое продолжение этой статьи и рассказать о некоторых вещах более практического плана, а именно создать небольшое руководство для тех, кто, скажем, неожиданно решил увековечить свое творчество путем записи относительно непростого гитарного произведения. :)
Итак, поехали.

Когда solution-файл содержит достаточно большое число проектов, сборка бинарных файлов превращается в процесс, требующий ощутимого количества времени, а отчет о сборке в простыню размером в несколько мегабайт. Лично у меня подобная строка в самом конце при таких масштабах вызывает недоумение:

========== Build: 258 succeeded, 1 failed, 40 up-to-date, 1 skipped ==========

А помимо недоумения закономерный вопрос: а что, собственно, сломалось? Есть, конечно, вкладка «Error list», но она к сожалению не показывает названий проектов — только файлы, а при таком объеме исходного кода, да с учетом того факта, что над этим solution'ом работает большая команда, довольно проблематично определять на память принадлежность того или иного файла к определенному проекту (читай определять виновных в сломанной сборке). Пролистывать же отчет в поисках имени проекта, содержащего ошибки, на мой взгляд, не совсем целесообразно.

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

Раз уж так получилось, что я начал свое существование на Хабре именно с топика о том, как создать плазмоид, то было довольно странно, если бы я в итоге в качестве логического развития той статьи не написал бы это. И вот, наконец, все получилось. И не что-нибудь, а Хабраплазмоид, отражающий карму и рейтинг выбранного пользователя! :)

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

Однако лично я знаю очень мало людей (если быть честным, всего двух), которые хотя бы в малой мере пользовались преимуществами открытого исходного кода используемых ими программ. Основные аргументы: я не знаю, где этот самый код брать; я не знаю, как это все потом собирать; я боюсь сделать из своего дистрибутива помойку, собирая собственные модули.

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

Для иллюстрации всех приемов и механизмов я поставил перед собой довольно просто осуществимую, но не имеющую никакой практической ценности цель: у меня есть часто используемая утилита wget и я кровь из носа, как хочу, чтобы она со мной здоровалась при каждом запуске. Вот хочу и все тут. К этому и будем стремиться.

Начиная с версии 4.x, на смену проверенных с годами, но морально устаревших (по этому поводу, конечно, мнения могут и разделиться) KDesktop, Kicker и SuperKaramba в KDE пришел Plasma Desktop. Этот фреймворк представляет рабочий стол (по крайней мере, его видимую часть), как совокупность виджетов или плазмоидов. Обзаведясь в один прекрасный момент некоторым количеством свободного времени, я решил немного разобраться с Plasma SDK, реализовав функцию, которой на тот момент мне действительно не хватало в составе моего рабочего стола. А функция эта — возможность без привлечения дополнительных приложений отправлять записи в LiveJournal. То есть этакий миниклиент, встроенный прямо в десктоп. «Было бы здорово», — подумал я и принялся ворошить интересующую предметную область.

Для того, чтобы осуществить все, что описано далее, в системе должны присутствовать, собственно, KDE4, а также следующие установленные пакеты: kdesdk, kdebase-devel, kdelibs-devel, cmake. В зависимости от дистрибутива, пакеты могут иметь немного другие названия (я привожу имена для Fedora Core), но общий смысл, думаю, ясен.