Действительно портабельный графический тулкит

А есть ли такой тулкит, к которому бы не требовался биндинг? Не веб-интерфейс. Просто чтобы программа на любом ЯП могла рисовать GUI через IPC, например сокеты. Не протокол иксов, а высокоуровневее. Есть такое?

Нет.
Сейчас набегут и скажут, что есть xlib, но с ним всё то же самое, но плюс ещё иксы.

Про xlib я и сам вспомнил. Но он завязан на иксы (вычеркиваем портабельность) и очень низкоуровневый.

Без оборачивания такой протокол всё равно будет сложно использовать, посмотри на xcb. А вообще, тот же gtk ведь сейчас так и работает, не через ipc, но gobject имеют интроспекцию и в gjsэто используется на полную. Осталось только пробросить эти вызовы через сокеты и на другой стороне по интроспеции сознать объекты.

А вообще, для удобной работы, потребуется многое обернуть, получится переизобретение glib с доступом к объектам поверх сокетов как минимум. Гораздо проще отделить ui frontend в самом приложении и сделать протокол взаимодействия с основной частью

Мням. Это же гуевый сервер просто как бэ, а не тулкит.

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

Тулкит с встроенным сервером же) Кстати не обязательно использовать сокеты, обмен информацией через пайпы, файлы - тоже подойдет.

Это в любом случае изобретение X.org
Тут не раз кричали, что X.org меденно, старо, костыликококо, покастуй сторонников wayland шоп они тебе объяснили по-хардкору почему.
P.s порт иксов на винду существует, кстати. Xming например.

Но он завязан на иксы (вычеркиваем портабельность)

А куда Xы не портированы?

Вот эти две вещи в ту же степь:

http://habrahabr.ru/post/212013/ Тулза для создания GUI на Qt из баша

https://en.wikipedia.org/wiki/IUP_(software) Оно вроде как скриптуется на Lua и интерактивное. Но в деле не пробовал.

А ничего, что в X.org нужно все низкоуровневые вещи руками делать и нельзя написать hello world аналогично GTK в три строчки?

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

Ну правильно представляешь, поэтому я и написал про gobject + gtk. У них есть свой формат интроспекции, он поможет создать обёртки. Из обёрток генерировать xml, передавать, парсить и вызывать нужные объекты. Впринципе не так много работы нужно проделать, gobject к это давно подготовлен. И сигналы там тоже завёрнуты. То есть по сути надо написать транспорт - gobject -> xml -> socket -> xml -> gojbect

Есть забавная хрень, называется PlanB. Выросла из Plan9 (советую про него почитать, если не в курсе). Так вот там GUI строится через манипуляции структурами файловой системы, т.к. создание/удаление файлов и директорий. Там вообще все «файлы» (в терминологии этой ОС - коробки, боксы). GUI приложения можно запаковать в tar, перенести на другую машину, распаковать, и в результате будет создано окно того приложения со всеми элементами.

http://lsub.org/ls/planb.html - про систему
http://lsub.org/ls/demos.html - посмотреть демки
Там сами видосы и ссылки на google video, которое уже повыпиливали. Так что качайте, сохраняйте для потомков.

Plan'ы рулят! Linux по сравнению с ними полный сакс!

Аналогичным образом можно таскать dosbox и пускать программы для DOS'a.

А есть ли такой тулкит, к которому бы не требовался биндинг?

Просто чтобы программа на любом ЯП могла рисовать GUI через IPC, например сокеты.

Ты не совсем понимаешь, какие проблемы решают биндинги. Среди основных проблем:

• Преобразование структур данных родных для одной среды в родные структуры другой. Самый банальный пример - преобразование строк UTF-8 в UTF-16.
• Предоставление функционала тулкита в родном/естественном виде для клиентского языка. Например, для какого нибудь Ruby было бы естественно предоставлять ООП-style функционал Gtk в виде встроенных в язык классов, наследования, итп., а не заставлять программиста пользоваться «низкоуровневыми» методами Gtk. Ещё один банальный пример - отображение родных Ruby string'ов на соответствующие стринги Qt, чтобы при вызове Qt'шного метода можно было бы написать foo.bar(«string») вместо вызова String.new... и последующей передачей результата методу.

Это, конечно же, не полный список, но даже эти 2 пункта показывают, что использование сокетов вместо «обычного» FFI магическим образом основных проблем не решат, по той простой причине, что на какой-то из сторон всё равно указанные моменты придётся решать.

Есть Qt, в котором есть все, в том числе базы данных

Про «базы данных»(С) прошу поподробнее.

А то про ИНТЕРФЕЙС к СУБД (e.g. JDBC (и то НЕ в Swing'e и не ATW и не SWT) я же всего лишь скромный «жабабыдлокодер»(R)) я знаю, а про наличие целой БАЗЫ ДАННЫХ в ГРАФИЧЕСКОМ ТУЛКИТЕ - это что-то новенькое я сегодня открыл для себя.

В каком мухобалалайском радиотехническом колледже Gregon-кун узнал о наличии баз данных в графическом тулките? Где таких востребованных специалистов делают?

хочется странного? просто использовать Qt уже скучно? в теории можно использовать Swing/JavaFX без биндингов из любого язычка который работает под JVM, на практике не пробовал

На Android я где-то с год назад тыкал палочкой две вполне рабочие реализации. Так что есть.

И где Xов нет?

gtk пока ещё над Xами выстроено. Спокойно с других компьютеров запускается. Это, ага, та самая сетевая прозрачность.

Да, я тоже такую штуку представил, только с JSON вместо XML.

Не веб-интерфейс. Просто чтобы программа на любом ЯП могла рисовать GUI через IPC, например сокеты. Не протокол иксов, а высокоуровневее. Есть такое?

Всегда использовал Tk для этого. Дергается в принципе из любых языков.

QML.

А чем тебе xlib не нравится? Или OpenGL?

Не веб-интерфейс.

А он-то чем не угодил?

gtk-server изобретаем?

Просто чтобы программа на любом ЯП могла рисовать GUI через IPC, например сокеты.

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

Не веб-интерфейс

Это почему?

Нет ничего кроме Cocoa API!

А есть ли такой тулкит, к которому бы не требовался биндинг? Не веб-интерфейс. Просто чтобы программа на любом ЯП могла рисовать GUI через IPC, например сокеты. Не протокол иксов, а высокоуровневее. Есть такое?

Хороший тулкит ведёт себя как фреймворк, то есть можно сразу садиться и писать. IPC — это вам не «сразу садиться и писать», надо ещё через этот IPC обращаться как-то, да так, чтобы не тормозило.

А тормозить оно будет в любом случае, если абсолютно все операци идут через IPC.

Про «базы данных»(С) прошу поподробнее.

Предлагаешь каждый раз писать «в том числе абстрагированный интерфейс к абстрактному ODBC и конкретным СУБД MySQL, SQLite, Postgres и другим»?

А куда Xы не портированы?

На AVR!!!

Почему никто не назвал Tk, в котором все часто так и делается?

Нет, но давно мечтаю, чтобы это родилось и убило тот выкидыш, в который сейчас превратилось HTML и иже с ними.