LINUX.ORG.RU

История изменений

Исправление hobbit, (текущая версия) :

В идеале правильная разработка опен сурс программ должна вести по архитектуре без привязки к какой либо ГУИ-библиотеки.

Это сильно зависит от того, что за программа.

Если какая-нибудь гуйня к БД (каталогизатор там какой-нибудь, он вполне может быть опенсорсным), то там доля ГУИ в коде может приближаться к 99% (вместе с запросами к БД, они тоже будут скармливаться какой-то библиотеке), и «архитектура» идёт лесом. Точнее, архитектура там будет, но совсем другая.

Если, наоборот, это (например) распознавалка изображений с прошаренными алгоритмами — да, однозначно имеет смысл выделить ядро, отвязанное от GUI.

Обычно мы имеем что-то среднее, и приходится идти на компромиссы. Я плохо представляю, как это делается, например, в офисных пакетах, где надо рендерить простыни форматированного текста с графическими вкраплениями с привязкой к области отображения, с учётом прокрутки и др. Там в исходниках нечеловеческий ужас, наверное…

Gnome и KDE — это не библиотеки, это DE.

Исходная версия hobbit, :

В идеале правильная разработка опен сурс программ должна вести по архитектуре без привязки к какой либо ГУИ-библиотеки.

Это сильно зависит от того, что за программа.

Если какая-нибудь гуйня к БД (каталогизатор там какой-нибудь, он вполне может быть опенсорсным), то там доля ГУИ в коде может приближаться к 99% (вместе с запросами к БД, они тоже будут скармливаться какой-то библиотеке), и «архитектура» идёт лесом. Точнее, архитектура там будет, но совсем другая.

Если, наоборот, это (например) распознавалка изображений с прошаренными алгоритмами — да, однозначно имеет смысл выделить ядро, отвязанное от GUI.

Обычно мы имеем что-то среднее, и приходится идти на компромиссы. Я плохо представляю, как это делается, например, в офисных пакетах, где надо рендерить простыни форматированного текста с графическими вкраплениями. Там в исходниках нечеловеческий ужас, наверное…

Gnome и KDE — это не библиотеки, это DE.