LINUX.ORG.RU
Форум — Development  

Архитектурное решение: GUI в отдельном процессе


0

0

Начинаем разрабатывать на C++ сложный продукт, моделирующий сложный объект :-). Должен быть насквозь скриптован, часто будет запускаться в пакетном режиме. Не менее часто, однако, будет использоваться GUI. В связи с этим напрашивается решение разделить GUI и функциональность по разным процессам.

Какой механизм IPC для этого лучше использовать? Сокеты смотрятся слишком низкоуровневыми (придется разрабатывать и поддерживать сложный протокол). CORBA выглядит слишком громоздкой...

★★★★
← 1С
Определение серийного номера HDD →

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

anonymous
()

>>CORBA выглядит слишком громоздкой...

Извините, конечно. Это ваше решение выглядит слишком громоздко.

anonymous
()
Ответ на: комментарий от anonymous

>а можешь еще память с данными шарить и из гуя ее атачить просто....

Не значит ли это, что расшаренные данные должны быть POD?

hbee ★★★★
() автор топика
Ответ на: комментарий от anonymous

> Извините, конечно. Это ваше решение выглядит слишком громоздко.

Да без проблем. Ругайте, чем больше, тем лучше :-).

А почему слишком громоздко? Зачем тащить GUI в пакетную обработку? К тому же, когда главный поток заведомо не является гуишным, интерфейс легче сделать более "отзывчивым". Например, в смысле прогрессбаров с возможностью немедленной отмены. Гарантируется, что GUI не будет "замирать", что бесит пользователей.

hbee ★★★★
() автор топика

А не проще ли выделить функциональность в отдельную билиотеку и написать два интерфейса - один командная строка, другой GUI.

fghj ★★★★★
()
Ответ на: комментарий от fghj

> А не проще ли выделить функциональность в отдельную билиотеку и написать два интерфейса - один командная строка, другой GUI.

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

hbee ★★★★
() автор топика
Ответ на: комментарий от anonymous

> Можно попробовать libgconf, в данном случае это то, что надо (IMHO :)

Гм... Погуглил:

libgconf libraries provide the functions necessary to maintain the configuration database.

?

hbee ★★★★
() автор топика
Ответ на: комментарий от hbee

В многопроцессном дизайне потребуется еще более высокая дисциплина для отслеживания асинхронного ввода-вывода. Проблема все равно остается, и решать ее лучше в GUI целиком. Библиотека же будет проще - только reentrancy и thread-safe (что на C++ довольно легко делается, если правильно писать). К тому же, командная строка (посаженная над бибилотекой) будет избавлена от таких проблем.

Хотя, я могу быть не прав.

Ксати, если CORBA не нравится, то можно ведь и просто RPC использовать. В любом случае это зависит от того, какие данные нужно перегонять - если небольшие, лучше RPC/CORBA, большие и структурированные CORBA/XML-RPC, большие и неструктурированные - socket'ы.

anonymous
()

Сокеты - это УЖЕ слишком высокий уровень. Пайпов достаточно. Протокол сложный сочинять не надо. Их уже есть полно готовых. И XML-ные решения, и Лисповские S-выражения, и просто код на Tcl. Это же блин unixway!

flamer
()
Ответ на: комментарий от anonymous

>В многопроцессном дизайне потребуется еще более высокая дисциплина для отслеживания асинхронного ввода-вывода. Проблема все равно остается, и решать ее лучше в GUI целиком. Библиотека же будет проще - только reentrancy и thread-safe (что на C++ довольно легко делается, если правильно писать). К тому же, командная строка (посаженная над бибилотекой) будет избавлена от таких проблем.

>Ксати, если CORBA не нравится, то можно ведь и просто RPC использовать. В любом случае это зависит от того, какие данные нужно перегонять - если небольшие, лучше RPC/CORBA, большие и структурированные CORBA/XML-RPC, большие и неструктурированные - socket'ы.

Спасибо за информацию к размышлению.

hbee ★★★★
() автор топика
Ответ на: комментарий от flamer

> Сокеты - это УЖЕ слишком высокий уровень. Пайпов достаточно. Протокол сложный сочинять не надо. Их уже есть полно готовых. И XML-ные решения, и Лисповские S-выражения, и просто код на Tcl. Это же блин unixway!

Тоже звучит дельно. Спасибо за информацию к размышлению.

hbee ★★★★
() автор топика
Ответ на: комментарий от hbee

Вообще, рекомендую посмотреть на любую Tcl-ную морду - они все по примерно одной схеме построены...

flamer
()
Ответ на: комментарий от hbee

>> Можно попробовать libgconf, в данном случае это то, что надо (IMHO :)

>Гм... Погуглил:

>libgconf libraries provide the functions necessary to maintain the >configuration database.

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

Кстати, на мордочках можно вообще сэкономить, и пользовать gconf-editor для смены параметров.

anonymous
()

Возьми Erlang, там тебе и сокеты и пайпы и корба, если очень хочется. Дальше прикручивай веб/тсл/что хош.

yuriy123 ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← 1С
Development
Определение серийного номера HDD →