<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 13, 2015 at 11:00 AM, Robert Osfield <span dir="ltr"><<a href="mailto:robert.osfield@gmail.com" target="_blank">robert.osfield@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""></span>...</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">osgViewer is fully threaded, something that cannot be said of Qt etc, where threading is a messy after thought.<br></div></blockquote><div> <br><br></div><div>That is perhaps a bit harsh. In general, there is no problem with threading in Qt at all and there is a fairly decent threading library included with it. However, you need to be aware that the GUI library itself is not thread safe (pretty much no GUI libraries are) and if you wish to integrate an external library with Qt, it needs to respect that. Normally you should practically never need to use threads to drive the UI, so that shouldn't be an issue in 99.5% of the cases. The rest is covered by various tools provided by the library, such as asynchronous tasks, networking in the background, etc.<br><br></div><div>I have done a lot of integration of both OSG and Ogre3D with Qt for my work and I have worked with wxWidgets in the past as well. I think the far larger problem with Qt (and also wxWidgets and other "big framework" type UI libraries) is that these are not really GUI libraries but complete application frameworks. Their programming model is very different from what OSG or simulator/game programmers assume and one can't just "cherrypick" bits and pieces needed by the application. It is an all or nothing proposition - either you design you application following the design principles of hte framework and then everything works like magic, or you don't and then you can't really use it. <br><br>These frameworks are all event driven (no busy main loop, application is sitting idle waiting for input instead!), expect to have full control of the top level application event loop (weird things happen if this isn't the case) and often they expect to fully manage OpenGL state too if you are using the provided OpenGL support. These "impedance mismatches" make things difficult when two libraries with such assumptions meet in a single application. <br><br></div><div>Generally speaking, Qt, wxWidgets and similar are great if you are building an UI-centric desktop application, using standard UI elements and an embedded OpenGL/OSG window. Especially the Qt Designer is very hard to beat when it comes to quickly building the application interfaces. A typical application using this could be perhaps something like a CAD program, mesh visualizer/editor or something like Google Earth (uses Qt). <br><br>On the other hand, if your goal is a realtime application with relatively lightweight UI using custom graphics elements that is being rendered by the 3D engine itself, such as a simulator or a game, then it is better to use specialized middleware. CEGUI is rather primitive, but there are tools like Coherent UI, Scaleform, libRocket, etc. We have tried to use Qt and its new QML system to render a GUI *inside* of an OSG application (render QML to texture and display using OSG) and while it is possible, it requires a lot of non-trivial hacks because the library is simply not written with such use case in mind at all. I certainly don't recommend this approach. <br><br></div><div>Regards,<br><br></div><div>Jan<br></div><div><br><br></div></div></div></div>