История изменений
Исправление www_linux_org_ru, (текущая версия) :
Этот компилятор ресурсов просто генерирует бинарный конфиг, по которому потом может быть создано дерево виджетов. Такой прообраз xml-я.
А виджеты в винде реализованы в одной из стандартных dll-ок.
я так примерно себе это и представлял
а речь была о том, что эта схема, похоже, позволяет легко реализовать сетевую прозрачность — если предположить, что «бинарный конфиг» перекидывается по сети с хоста А, где исполняется прога, на хост В, и рендерится уже dll-кой хоста В, где его и видит юзер за монитором, подключенным к В
понятно, что эвенты (т.е. мышеклик например) нужно еще двигать по сети обратно с В на А (хотя правильно приготовленная такая система должна обрабатывать как можно больше эвентов прямо на хосте В)
Исправление www_linux_org_ru, :
Этот компилятор ресурсов просто генерирует бинарный конфиг, по которому потом может быть создано дерево виджетов. Такой прообраз xml-я.
А виджеты в винде реализованы в одной из стандартных dll-ок.
я так примерно себе это и представлял
а речь была о том, что эта схема, похоже, позволяет сетевую прозрачность — если предположить, что «бинарный конфиг» перекидывается по сети с хоста А, где исполняется прога, на хост В, и рендерится уже dll-кой хоста В, где его и видит юзер за монитором, подключенным к В
понятно, что эвенты (т.е. мышеклик например) нужно еще двигать по сети обратно с В на А
Исходная версия www_linux_org_ru, :
Этот компилятор ресурсов просто генерирует бинарный конфиг, по которому потом может быть создано дерево виджетов. Такой прообраз xml-я.
А виджеты в винде реализованы в одной из стандартных dll-ок.
я так примерно себе это и представлял
а речь была о том, что эта схема, похоже, позволяет сетевую прозрачность — если предположить, что «бинарный конфиг» перекидывается по сети с хоста А, где исполняется прога, на хост В, и рендерится уже dll-кой хоста В, где его и видит юзер за монитором, подключенным к В
понятно, что эвенты нужно еще двигать по сети обратно с В на А