Приложение для написания svg.

Браузер

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

Хотя чтобы оно работало строго в режиме сервера — это уже труднее может быть.

node-webkit

Нет там ничего сложного: CGI сишное — вуаля!

Так нет, надо ведь сам браузер заставить слушать на каком-то порту входящие приказы получить SVG. Или придётся инициировать запросы из браузера.

Нифига не понял.

Заходишь, скажем, по адресу: localhost/my-svg, оно тебе рисует SVG и периодически дергает CGI на подкачку новых картинок.

Вот, скажем, псевдо-3D отображение температур в подкупольном у меня так и работает: заходишь, тебе выплевывается SVG-картинка, а вот показания датчиков берутся из CGI, периодически содержимое SVG обновляется (меняются цвет и подписи у кружков, обозначающих датчики) при помощи того же CGI.

Заходишь, скажем, по адресу: localhost/my-svg, оно тебе рисует SVG и периодически дергает CGI на подкачку новых картинок.

А CGI сидит, слушает некий порт, на который приходят новые SVG, а потом, когда браузер его дёргает (предположительно, на другом порту), посылает ему последний полученный SVG?

Да. Только не CGI слушает, а демон, с которым общается CGI.

Скажем, как организуется подача видео с автогида: демон автогида снимает с камеры видео, обрабатывает его в соответствии с текущими настройками и вычисляет смещения; обработанные картинки и данные складываются в циклический буфер в shm.

Другой демон, который работает с приводами автогида, по этим смещениям дает команды приводам.

Вот с подачей видео я еще не разобрался. Раньше делал тупо mjpeg'ом, но надоело таким извратом страдать, хочу через вебсокеты замутить, т.к. попытка работы с html5 никаких плодов не дала (тупо нигде мне никто не подсказал, как это вообще реализовать, а сам нагуглить документацию не смог).

В любом случае, процесс такой: CGI (а в случае с вебсокетами — демон вебсокетов) берет последнюю актуальную картинку из циклического буфера и как-то передает ее пользователю.

А я это все к тому, что как бы ни генерировался этот SVG, результат можно легко передать в браузер в почти реальном времени. Скажем, у меня на информационных панелях в комнате удаленных наблюдений отображаются графики метеорологических параметров. Это — простые SVG, сгенерированные гнуплотом (красивые html5 графики мне лень было выдумывать). Раз в минуту график обновляется по запросу CGI.

Да. Только не CGI слушает, а демон, с которым общается CGI.

Ещё один демон? Так это уже получается какая-то каша из бензопилы. Фактически браузер используется как простой просмотрщик SVG, а вся логика общения по сети перекладывается на самописный демон.

Если я правильно понимаю ТСа, у него на один компонент меньше, чем у тебя. Тебе пришлось написать программу, которая собирает показания с каких-то датчиков и формирует SVG. У него программа, которая формирует SVG, уже есть. Она где-то сидит и периодически подключается к другим компьютерам, которые, соответственно, должны постоянно ждать подключения, и передаёт им новые SVG, которые они должны выводить на экран. Нужно придумать, что поставить на эти компьютеры, которые выводят SVG на экран.

демон автогида снимает с камеры видео, обрабатывает его в соответствии с текущими настройками и вычисляет смещения; обработанные картинки и данные складываются в циклический буфер в shm.

Так у него эти картинки приходят по сети. И ему нужно готовое или минимально костыльное решение, которое бы их принимало и выводило на экран.

Фактически браузер используется как простой просмотрщик SVG, а вся логика общения по сети перекладывается на самописный демон.

Естественно, браузер — и есть обертка для GUI, можно подумать, его еще как-то можно использовать. Мы и на ЛОР через графический браузер ходим лишь потому, что привыкли к этой обертке, а не к links какому-нибудь. Хотя, через links на ЛОРе явно уютней будет!

У него программа, которая формирует SVG, уже есть

Вот, ему остается лишь складывать эти SVG куда-то (можно тупо на диск) и забирать браузером картинки. Кстати, если на диск лить, то никаких CGI не надо: тупо жабкоскриптом обновляешь iframe с картинкой — вуаля!

И ему нужно готовое или минимально костыльное решение

Чем не готовое и минимально костыльное?

Могу тысячи за полторы-две набросать бета-реализацию. Как раз долговой баланс к концу месяца свел бы в 0.

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

XUL

Не матюкайся! Я без понятия, что это. И гуглить не собираюсь.

Тянуть за собой браузер ради такой простой херни, которая на том же Qt за пять-шесть минут реализовывается? Месье знает толк.