Полное разделение логики и приложения

Посмотри на transmission.

Сделать программу сервером, а гуй - клиентом. Можно и на локальных сокетах, как mocp, например.

Сделать программу сервером, а гуй - клиентом.

Думаю так и есть, главное выбрать наилучший вариант их взаимодействия.

Посмотри на transmission.

Как я понял там прям из кода вызывается библиотека общая(при очень, очень беглом взгляде), значит будет зависит от выбранного языка для логики-сервера программы. Хотя я мог ошибиться со своим беглым взглядом

Там есть графические клиенты (их несколько) и демон, которые по tcp общаются.

Если у тебя и интерфейс, и логика однозначно будут крутиться на одной машине, то можно выбрать какой-нибудь IPC, типа тех же юникс-сокетов, shared memory.

Но сетевые сокеты универсальнее. Лучше их пока ничего не придумали.

Смотря какова функциональность программы. Отделение интерфейса от логики сродни попыткам сделать микроядерную систему - можно, и способов немало, но результат будет столь тормозным и нефункциональным, что укатает любого фаната. Хорошо ещё, если ты делаешь что-то вроде торрент-клиента, там гуй вторичен.

zeromq

MVC

Бери, mvc как метод разделения. А то, как части mvc между собой будут комуницировать вопрос отдельный, как в классике с обсервер паттерном, а можно обмен сообщениями (с command processor pattern'ом). Но начинать с mvc в любом случае надо.

Логика - консольная утилита, гуй - надстройка.

Web же. Раздельнее не бывает.

Между серверной частью и клиентской надо проложить чёткий и до конца документированный интерфейс.

Паттерн MVC со всеми подвариантами.

Изучай опыт поколений, не изобретай велосипед. :D

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

Так серебрянной пули нет, зависит от ситуации. Вот примеры разных вариантов: X-CD-Roast (вызов утилит), SMplayer (управление дочерним процессом через stdin), GMPC (управление демоном по сети), NetworkManager (управление демоном по dbus), Transmission (уже упоминали, демон с rpc на json).

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

Потоки, глобальные переменные, флаги и статическая линковка. Эталонно вышло :)

По поводу MVC, ИМХО отталкиваться надо от протокола между гуи и движком, а потом уже смотреть, подходит ли MVC.

Потоки, глобальные переменные, флаги и статическая линковка. Эталонно вышло :)

Хоть одну плохую технологию назови.

SOAP, мой друг, только SOAP. Стандартизованное, широко применяемое решение с поддержкой от ведущих производителей программного обеспечения. Тысячи архитекторов бизнес-приложений не могут ошибаться.

SOAP, мой друг, только SOAP.

И ROPE, гы...

придерживайся при проектироании разделения: MVVM с одной стороны, и SOA - с другой.

Что бы при ошибке в GUI, и последующем его перезапуске, сама программа сохраняла свое состояние.

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

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

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