Отделение кода от гуя, best practices

Вот тебе ещё более костыльный вариант. Бэкенд отдаёт что-то вроде формы для заполнения с обязательными и необязательными полями. Фронтенд эту форму читает и по ней строит гуй который призван эту форму заполнить.

Сейчас каждый бекэнд отдает свой виджет, вставляемый в нужное место, через который и настраивается. Некрасиво.

- Отдаете «описание» параметров бекенда

- Рисуете универсальный интерфейс позволяющий редактировать параметры (форма редакторов), криво, косо, но редактировать (большинство будет состоять из флажков, комбобоксов, инпутов для цифирь)

- Когда универсальная форма редакторов дюжекрива выходит для какогото бекенда рисуете в редакторе точку расширения и внее вставляете кастомынй редактор (не всю форму меняете, а только редактор нужного параметра)

на яве всеь этот код пишется за полдня

почитайте про MVC.

Имхо, тут нужна фабрика виджетов, которая для каждого бекэнда будет отдавать нужный виджет\виджеты.

А как делаете в своих проектах вы?

Выделяю буфер в разделяемой памяти, либо использую mmap'нутую структуру-посредник, либо открываю сокет...

Есть ли в проекте другие задачи? Если есть - займись ими.

Подписался

ковыряю сейчас один проект, у него вся логика сделана демоном, уи на Qt, связь через D-Bus.

разбить каждый из модулей на две части - одна часть - логика, другая - графический интерфейс

а в чем костыльность?

P.S.: проект не мой, я просто разместил объяву^W^W
P.P.S.: имхо, правильно тут говорят про MVC

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

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

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

Про такой вариант тоже подумал, скорее всего к нему и приду для настройки бэкендов. А для визуализации данных, подумываю сделать qml'ные формы. Не знаю только как они внутри обычного qwidget будут жить.

Ну зачем, зачем QML?

Забудь про фримена бекендны. нету никаких бекендов, есть интерфейс. Так вот, у тебя интерфейс не правильный. Он должен быть унифицирован для твоего случая, а он - нет. Не унифицирован. Решишь проблему неправильного интерфейса - постигнешь дао.

на яве

я тоже за java с некоторых пор, в смысле лютобешеноплюсую.

Чтоб визуализация была свистящей и пердящей.

Дешифруй, пожалуйста. Что делать в случае если интерфейс нельзя унифицировать?

Сейчас хочу сделать все по уму.

Если тебе только нужно не тащить некий графический код в некое место, воспользуйся RPC (remote procedure call).

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

Порядок действий такой:
1. копируешь проект и называешь первую копию «сервер», а вторую - «клиент». Сервер будет заниматься работой, клиент - графикой.
2. просматриваешь весь код. Выстраиваешь линию разреза по классам/функциям, которые занимаются графикой и которые ты по этой причине не хочешь тянуть туда, где будут железки. Называешь их «классы/функции отображения».
3. Смотришь, с какими классами/функциями, оставляемыми в сервере, они взаимодействуют. Называешь их «классы/функции для отображения».
4. Повторяешь пункты 3 и 4, пока не достигнешь следующего результата:
- как можно меньше точек обращений к «классам/функциям для отображения»
- достаточно маленький трафик через границу
- главный цикл обработки событий Qt должен оказаться на стороне клиента
- «классы для отображения» должны быть твоими классами, а не классами Qt.

5. Выбираешь скриптовый язык, поддерживаемый SWIG, для встраивания в сервер. Допустим, tcl, php или mzscheme. Рассмотри такие вопросы, как безопасность, многопоточность, обработку ошибок, вопросы освобождения памяти, поддержку кириллицы, если она нужна.
6. Все «классы для отображения» оборачиваешь в этот язык. Рекомендуется использовать SWIG. Работа со SWIG довольно легка и приятна, ты можешь быстро обернуть десятки классов, поддерживаются и шаблоны, всё прилично документировано.
7. Реализуешь listener, который позволяет клиенту вызывать собственно связь «клиент-сервер», например, с помощью сокетов. Задача - чтобы ты мог в клиенте печатать команду, а команду выполнял бы встроенный в сервер интерпретатор.
8. Все обращения «классов/функций отображения» к «классам/функциям для отображения» подменяешь на вызовы интерпретатора через listener. ВОзможно, ты захочешь для этого написать (или нагенерить) классы-представители для каждого «класса для отображения», тогда работа над клиентом будет состоять в замене «классов для отображения» на представителей.

Немного сумбурно получается, но сам я по этому пути до конца не ходил, поэтому не могу выдать точно работающую стратегию с учётом всех граблей. Немного пробовал, вроде так должно получиться. Конкретно, я пытался сделать обёртки для полной VCL (библиотека видгетов Delhpi), чтобы пользоваться ей из Common Lisp. Остановил меня большой объём работы, а остальные вопросы, перечисленные в плане, были решены. Так что я не рекомендую так, попытайся ограничиться маленьким набором классов.

В итоге у тебя так и останется по видгету на бекенд (и ведь ты не ставишь задачи от этого отказаться, проблема с тем, что ты не хочешь тянуть графику к железке, я правильно понял?), только этот видгет будет оставаться на клиенте, а содержательная часть обмена информацией с прибором будет идти через скриптовый язык.
В идеале, тебе придётся сделать через скриптовый язык только несколько обработчиков событий, которые ты будешь вызывать из видгетов на Qt.

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

Полезную функциональность, написанную на полноценной библиотеке виджетов, крайне сложно свести к маленькому набору, недаром она большая. Если так пытаться делать, в итоге ты косвенно получишь копию всего функционала в костыльно-уродливом виде, причём, каждый раз будешь вспоминать, как сделать в этом костыльно уродливом виде то, что делается в Qt за три строки, утыкаться в недостающие места, дописывать на ходу, делать новые баги, вызывающие эффект ряби (ведь рисовальщик - общий). Во всяком случае, у меня так получилось, может, я лузер. Кроме того, если реализация будет сильно динамической, то она может ещё и медленно работать, не говоря о трудности отладки.

Вот, кстати, влезу с вопросом. Сам натыкался на этот swig, и возник интерес: неужели с ним проще сделать GUI, чем, скажем, используя те же C+GTK?

MVC спасёт отца русского костылестроения

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

так у тебя в ОП всё написано, в чём проблема то?

Не знаю, т.к. некогда не пытался сделать C+GTK. С Qt приходилось работать и с tk немного. Я вообще не линуксоид, я просто иногда сюда захожу для фана. Да и SWIG был на уровне экспериментов. Однако, эти эксперименты показали, что SWIG- это хороший инструмент, в котором продуманы все нюансы практики.

Спасибо за пищу для ума.

Насчет SWIG, я так понял у него свой препроцессор, у Qt свой. И SWIG если нужно будет натравливать уже на мокнутые файлы, то, мне кажется, будет тот еще геморрой.

Тогда извини.