подскажите пожалуйста как с помощью sciter реализовать интерфейс программы работающий по типу современного браузера,
а точнее одно окно с шапкой с табами которые переключают интерфейсы из других процессов(моих, тоже sciter)
пока на ум пришёл только самый дубовый вариант с child окнами других процессов в основном окне, но браузеры работают по другому,
можно как-то sciter'ом в дочернем процессе рендерить в d2d shared surface чтобы рисовать её в основном gui процессе, и если да, то как передавать из основного gui процесса все события(мышь/клавиатура) на дочерний процесс?
ещё была идея оторвать шапку в отдельное окно, и прилепить снизу окна других процессов, но только не уверен, что эту конструкцию можно будет безболезненно таскать и ресайзить.
Здравствуйте, Bаня, Вы писали:
B>подскажите пожалуйста как с помощью sciter реализовать интерфейс программы работающий по типу современного браузера, B>а точнее одно окно с шапкой с табами которые переключают интерфейсы из других процессов(моих, тоже sciter)
B>пока на ум пришёл только самый дубовый вариант с child окнами других процессов в основном окне, но браузеры работают по другому,
А собственно чем этот вариант плох в твоем случае?
B>можно как-то sciter'ом в дочернем процессе рендерить в d2d shared surface чтобы рисовать её в основном gui процессе, и если да, то как передавать из основного gui процесса все события(мышь/клавиатура) на дочерний процесс?
В принципе для этого подошел бы windowless sciter : https://sciter.com/scilite-windowless-sciter-engine/ , но я остановил работы по нему — нет особого интереса ни у кого.
B>ещё была идея оторвать шапку в отдельное окно, и прилепить снизу окна других процессов, но только не уверен, что эту конструкцию можно будет безболезненно таскать и ресайзить.
Можно и так тоже. Visual Studio например так рисует тени вокруг IDE окна — там четыре VisualStudioGlowWindow — отдельных desktop window по краям.
Просто эту всю конструкцию нужно двигать с пом. Begin/EndDeferWindowPos + DeferWindowPos — т.е. как одно целое.
спасибо за ответы.
B>>пока на ум пришёл только самый дубовый вариант с child окнами других процессов в основном окне, но браузеры работают по другому, CS>А собственно чем этот вариант плох в твоем случае?
где-то читал на форуме ваше же предположение, что при child окнах винда отключает у sciter'а отрисовку через gpu
Здравствуйте, Bаня, Вы писали:
B>Здравствуйте, c-smile, Вы писали:
B>спасибо за ответы.
B>>>пока на ум пришёл только самый дубовый вариант с child окнами других процессов в основном окне, но браузеры работают по другому, CS>>А собственно чем этот вариант плох в твоем случае?
B>где-то читал на форуме ваше же предположение, что при child окнах винда отключает у sciter'а отрисовку через gpu
Разные версии Windows ведут себя по разному в этом случае.
Второй вопрос: А зачем вообще такая конструкция, несколько Sciter'ов на одном окне? Почему не один и несколько <frame>ов ?
Здравствуйте, c-smile, Вы писали:
CS>Второй вопрос: А зачем вообще такая конструкция, несколько Sciter'ов на одном окне? Почему не один и несколько <frame>ов ?
во <frame>ах должны работать подключаемые интерфейсы из других процессов, и эти интерфейсы должны быть полностью "на ты" с html/css/tis посредством native code,
поэтому крутить sciter с фреймами в одном процессе и пересылать евенты в другие процессы очень сложно и не гибко.
Здравствуйте, Bаня, Вы писали:
B>Здравствуйте, c-smile, Вы писали:
CS>>Второй вопрос: А зачем вообще такая конструкция, несколько Sciter'ов на одном окне? Почему не один и несколько <frame>ов ?
B>во <frame>ах должны работать подключаемые интерфейсы из других процессов, и эти интерфейсы должны быть полностью "на ты" с html/css/tis посредством native code, B>поэтому крутить sciter с фреймами в одном процессе и пересылать евенты в другие процессы очень сложно и не гибко.
Тогда вариант с child window я думаю будет самым гуманным.
