art_zh wrote:И кто будет разрабатывать софт под 2 разных (аппаратно-несовместимых) GUI?
Вот тут мне показалось, что есть некоторая натяжка. Прикладникам вообще должно быть пофиг на аппаратную несовместимость, если нужные функции наличествуют. Понятно, что где-то без деталей не обойтись, и 24-битное изображение придется считать по 3 байта, а не по 4. Но в чем, объясните мне, разница в выводе текста системной функцией? Не с твоей стороны как ядерщика, а с моей -- как прикладника? Ну, номер шрифта другой. Ну, размеры другие. И всё.
Вначале нужно решить, как будет реализована поддержка новых шрифтов и предложить конкретный API. Вероятно, даже в двух вариантах -- с введением новых функций, и без них (если такое возможно). Еще перечислить поименно функции, которые будут затронуты оптимизацией. И разговор об условной компиляции сразу станет предметным.
Если вдруг выяснится, что добавление шрифтов дает новый API, может оказаться логичным
текущее ядро вынести в legacy -- выпустить его наконец-то как ветку 0.7.8, а самим сосредоточиться на транковой 0.8 -- уже с новым API. А любителям старины, соответственно, предлагать 0.7.8, и через какое-то время даже получить статистику о ее фактической популярности относительно 0.8.
Если же в будущем хомячки внезапно начнут роптать об отсутствии 24-битной графики, -- что же, это новая реальность, которую придется осознавать заново, уже имея полноценные шрифты. К тому времени и практика по ним наработана будет, и полезность доказана, и всё остальное. Тогда-то и станет ясно, то ли портировать новые фишки из 0.8 в legacy-ветку, то ли наоборот, логичней и проще напрячься и вернуть поддержку 24-битной графики в 0.8. Ну, или будет некому, как обычно.
А без развития и выпуска новых версий -- никуда, только в сторону. Пример с Miranda NG
показателен.