GUI для демок Cursed Earth

[v1s0r]

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

С другой стороны, не хочется заставлять людей вводить в командной строке много текста.
Я склоняюсь к мысли сделать демки и гуи к ним разными прогами. Определить интерфейс общения между ними и запустить их через PIPE. Т.е. задача гуи - именно хороший гуи и больше ничего (кстати, написание действительно хорошего гуи само по себе исскуство). Гуи будет командовать спайком, посылая ему в stdin (или по TCP) какие-то команды, например загрузить такой-то уровень. Список же уровней гуи будет получать от спайка.

Можно выделить набор полезных спайков и сделать к ним гуи. Один я точно не справлюсь, нужна помощь. Может кого заинтересует. Лучше писать на чём-то кросс-платформеном, wxWidgets, Qt. Если кто-то хочет изучить эти либы - добро пожаловать. Будут более менее реальные задачи.

Жду отзывов, возражений, других предложений или ещё чего-нибудь)

[Sagrer]

предлагаю по возможности не извращаться с пайпами, стандартными входамивыходами и иже с ними и просто грамотно в коде разделить интерфейс и логику - тогда будет возможно из одного и того же кода скомпилить и консольную утилиту и GUI. Всмысле, скажем у нас есть (всё условно) demo.h и demo.cpp с кодом консольной main() - внутри только то что отвечает непосредственно за, скажем обработку аргументов командной строки и запуск уже нужной логики.

Одновременно у нас есть demogui.h и demogui.cpp с кодом GUI-шной main() - внутри только код ответственный за GUI и опять же запуск нужной логики.

Вся логика лежит в отдельных файлах h-cpp - они линкуются и в консольный и в гуишный проект, одни и те же.

По крайней мере так не придётся маяться с синхронизацией двух потоков в GUI - большинство GUI-шных оболочек к консольному софту, имхо, на редкость паршиво работают именно по этой причине %).

[levdev]

предлагаю по возможности не извращаться с пайпами, стандартными входамивыходами и иже с ними и просто грамотно в коде разделить интерфейс и логику - тогда будет возможно из одного и того же кода скомпилить и консольную утилиту и GUI. Всмысле, скажем у нас есть (всё условно) demo.h и demo.cpp с кодом консольной main() - внутри только то что отвечает непосредственно за, скажем обработку аргументов командной строки и запуск уже нужной логики.

Одновременно у нас есть demogui.h и demogui.cpp с кодом GUI-шной main() - внутри только код ответственный за GUI и опять же запуск нужной логики.

Вся логика лежит в отдельных файлах h-cpp - они линкуются и в консольный и в гуишный проект, одни и те же.

По крайней мере так не придётся маяться с синхронизацией двух потоков в GUI - большинство GUI-шных оболочек к консольному софту, имхо, на редкость паршиво работают именно по этой причине %).
[right][snapback]40056[/snapback][/right]

Хотя в C++ не силен, но полностью согласен с Sagrer'ом. Ну а при разработки самой ГУИ, думаю и либы помжно поюзать и подучить

[v1s0r]

Да, о таком разделений я не подумал. Хорошо, пошевелю мозгами ещё на досуге.

А насчёт синхронизации не согласен. По крайней мере, в Qt. У неё отличный и стабильный API для subprocess и сети, я им не раз пользовался.

[Sagrer]

А насчёт синхронизации не согласен. По крайней мере, в Qt. У неё отличный и стабильный API для subprocess и сети, я им не раз пользовался.

да я не спорю про API, просто KISS никто не отменял и какой смысл городить то без чего можно обойтись? %).