Build Kicker from KDE3 inside KDE4

[midenok]

Get kicker from here:
svn://anonsvn.kde.org/home/kde/tags/KDE/3.5.10/kdebase/kicker

Put Kicker nearby Plasma. Try to compile it like Plasma is compiled. You will see a lot of unresolved dependencies which you need to port into KDE4-style.

[midenok]

1. Do not compile following directories, exclude them from processing:

• applets
• extensions/dockbar
• extensions/kasbar
• extensions/sidebar
• menuext

[midenok]

Я тут ещё разок подумал на эту тему. И пришёл к выводу, что подход "вширь" здесь не совсем подходит. Здесь нужен подход "вглубь". По крайней мере, начинать надо с него. Что это означает? Мы делаем маленький, но компилирующийся и работающий стаб. Затем по-маленьку накидываем туда классы из кикера, параллельно решая все зависимости и каждый раз добиваясь компиляции и безотказной работы. Итак, вот примерный план работы:

1. Создать компилируемый и работающий стаб. Для этого нужно создать пустую поддиректорию (как мы делали с кикером), создать там один .cpp файл и закинуть туда самый начальный класс из плазмы (тот, который мы видели в отладчике, потомок от QApplication с методом kdemain()). При этом, этот класс надо очистить от всей функциональной "шелухи". Т.е. сделать его абслоютно пустым, так чтобы не было никаких зависимостей и наш исходник компилировался без проблем.
2. Затем этап второй -- добиться успешного запуска. Что это означает? Нужно, чтобы вместо kdeinit_plasma в KDE4 (в скрипте startkde) запускался наш новоявленный модуль. Назовём его для простоты kicker4. Это, возможно, сопряжено с небольшими осложнениями. А именно, возможно нужно будет накинуть какой-то функционал из kdemain() и появятся какие-то зависимости. Что именно нужно будет накинуть, не взяв ничего лишнего -- это уже задача интеллектуальная.
3. Этап третий. Мы уже имеем запускающийся (и возможно сразу же завершающийся) kicker4. Можем заходить в него в отладчике. Теперь мы начинаем по-маленьку накидывать туда функционал из kicker3 (так я буду называть kicker из KDE3, чтобы не было путаницы). Какой именно функционал -- тот, который будет рисовать что-то на экране и оставит запущенным kicker4 не позволяя ему завершиться.Отрисовываться будет остов от панели taskbar из kicker3. Пока что, на этом этапе больше ничего не нужно -- никакие события от мыши и клавиатуры можно не обрабатывать. Подозреваю, что уже этот минимальный функционал потянет за собой какие-то зависимости из kde3. Интеллектуальная задача будет состоять в том, чтобы решать есть ли такой функционал в kde4, и если есть -- адаптировать эти зависимости под функционал из kde4. Если же мы в kde4 ничего похожего не найдём, придётся тащить из kde3, итеративно пытаясь решить эту интеллектуальную задачу. И так -- до тех пор, пока мы не удовлетворим все зависимости только средствами kde4.
4. Т.е. идея в том, что мы с минимальным продвижением вперёд каждый раз добиваемся работающего кода. Именно это залог успеха. Итак, мы уже имеем запущенную панельку в kicker4. Она ещё пока ничего не умеет делать, только светится на экране. Теперь, уже порядком намонстрячившись в разрешении зависимостей, мы начинаем потихоньку накидывать остальной функционал из kicker3 применяя методику п.3. Параллельно решая вопрос что надо, а что нет. Т.е. накидывать будем не всё подряд, а только процентов 70 того, что действительно полезно. Мусор брать не будем.
5. Этап пятый -- удовлетворить требования KDE4 к kicker4. Ведь не только оболочка требует что-то от окружения, но и окружение может задавать какие-то стандарты, которым должна удовлетворять оболочка. Это может быть не сразу заметно, а в процессе тестирования, когда будет выясняться, что некоторые компоненты KDE4 использовали для своих нужд плазму и в отсутствии её работать отказываются. Будет решаться накидыванием этого функционала из плазмы в kicker4.