[osg-users] Integrate Qt into OSG - not OSG into Qt osgQt

Jan Ciger jan.ciger at gmail.com
Wed Oct 2 11:02:15 PDT 2019


Hello,

On 02/10/2019 15:23, Trajce Nikolov NICK wrote:
> Hi community, 
>
> I am struggling with the design of such a task. And I am a bit
> familiar with Qt and other UI frameworks. The task is to embed the
> whole Qt framework into OSG - including the event processing and let
> OSG render ( through RTT ) the widgets content.
>
> Any clue, hints what direction I should take?
>
> Thanks a bunch as always!
> Nick


Ufff, you are in for quite a battle, I am afraid. I have done this few
years ago when we were using Ogre and OSG for our virtual reality
simulators at work and we needed a proper UI framework to display user
interfaces inside the application. 

You have basically two options:

a) Render the Qt widget/window into a texture/image, grab that and
display it as an OSG texture. Input from OSG can be fed into Qt's event
system by artificially creating and injecting events.

This works and it is how we have done it. Qt widgets can render
themselves into an image/texture directly, simply by calling their
render() method with proper arguments. We were able to display most Qt
widgets and render QML using OSG textures. Where things get very hairy
is the state management between OSG and Qt (Qt uses its own OpenGL
backend for rendering and assumes that it is in a certain state!) and
then input. When you aren't rendering Qt the usual way by showing
windows on screen but you only call render() and grab a texture, Qt will
not initialize some internal state relating to issues such as cursor,
keyboard focus, state of some widgets, etc.

The result is that you will have problems with cursor disappearing,
widgets not accepting keyboard input, keyboard shortcuts not working and
myriads of other problems like this. It can be solved to some degree by
digging into the Qt's source code, seeing which flags it is relying on
where and then manually calling the necessary functions to ensure that
they are set correctly. We have managed to get it to such shape that the
UIs were usable but if you need a very complex UI you will likely run
into problems. Also OSG's event system doesn't handle anywhere close to
the gamut of input events that Qt does, so a lot of things will have to
be emulated.

b) Implement a new Qt backend running on top of OSG. 

Qt implements several of these backends, including a basic framebuffer
and OpenGL already, that is how they port Qt to different platforms,
such as phones or embedded hardware. This would be probably cleaner
approach if you really need the entire Qt to work but also a lot more
work than the above, because the API is fairly extensive, not super well
documented (this are really the dirty guts of Qt you aren't supposed to
normally see)  and may not have a completely straightforward mapping to OSG.

Good luck,

Jan





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20191002/b9b5e1fd/attachment.sig>


More information about the osg-users mailing list