<html><head></head><body><p dir="ltr">Hi Joshua,<br>
I fully agree with you. We are developing commercial software and started with plenty of years ago. About 10 years ago we started to use osg and embedded osg view into a qt widget based on the osg-qt project at that time. It worked smoothly since then. Now we are on the latest releases of osg and qt and we never had to touch our embedding class. The only thing I am missing is the compatibility of threading. But we can live with that and I'm not limited in threading inside qt.<br>
Qt is great for development of cross platform user interfaces and frees me of Microsoft related usage of system interfaces. During all those many years there were only 2 cases where something didn't work as expected. But we could debug and fix it due to open source.<br>
So we are happy with the combination of qt and osg. Both are reliable, stable and have excellent features in their field. <br>
Werner</p>
<br><br><div class="gmail_quote">On 27. Juli 2018 19:19:17 MESZ, Joshua Tree <mocca4us@outlook.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">I have to chip in here. Qt is the most reliable, industry standard UI for C++, period. In part this success is due to the moc autogeneration, which could get you out of SFINAE madness.<br /><br />Now, there are huge firms that adopted Qt for decades and run multi billion dollars systems on it. <br /><br />That said, the Qt source is online and you can modify it as you wish to test a solution. It is puzzling to me how this is still a pending and recurrent issue for over a decade and a half I follow OSG.<br /><br /><br /> I have used Qt and OSG back in 2003, 15 years ago with success. <br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> On Jul 27, 2018, at 12:03 PM, Robert Osfield <robert.osfield@gmail.com> wrote:<br /> <br /> Hi Andrew,<br /> <br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> On Fri,
27 Jul
2018 at 17:14, Andrew Cunningham <andrewC@mac.com> wrote:<br /> I would agree QT is not perfect but on the flip-side<br /> - It is the 'last man standing' of x-platform UI's.<br /></blockquote> <br /> This is down to the weakness of the alternatives rather as much as the<br /> strength of Qt.<br /> <br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> - It's actively developed using the latest C++11/14 standards and supported by both a commercial organization and a robust LGPL community<br /></blockquote> <br /> Will they get rid of the non standard C++ extensions and pre-compiling nonsense?<br /> <br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> - Is has a new lease of life through PyQT5 and PySide being the 'de-facto' way to build Python based desktop UI's.<br /> - QML is quite interesting<br /></blockquote> <br /> There is
simply
too much pushed into Qt over the years. The lack of<br /> focus on the core functionality hurts it.<br /> <br /> I say this from experience, we've pushed too much functionality into<br /> the OpenSceneGraph distribution over the years, I can see the<br /> mistakes, but with backwards compatibility being an important factor<br /> for end users it's not easy to just make radical changes.<br /> <br /> What the computer industry is a nice neat, small C++11 UI library with<br /> good hooks to building scripting integration on top of.<br /> <br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> I don't know why QT and OSG seem to fight each other so much, but it seems a PITA to get things working properly as the OP and I have both found mysterious issues popping up that require trips into the debugger and the QT and OSG source. I had to advocate for OSG as other developers were keen to use QT3D instead.<br
/></blockquote> <br /> OSG integration with 3rd party windowing toolkits has generally been<br /> pretty straight forward - once the basics have been written it doesn't<br /> take much to update and keep things working.<br /> <br /> Our experience with Qt is not like this at all. X11, Win32 they've<br /> been pretty rock solid for way over a decade now. OSX has required<br /> jumping through a hoops because Apple doesn't care about developers as<br /> much as it cares about vendor lock-in.<br /> <br /> Over the years the OSG hasn't added extra burden on the 3rd party<br /> windowing toolkits, it's exactly the same as it has always been, just<br /> create a GL context and allow the OSG to call makeCurrent() and<br /> swapBuffers and we are pretty well done. It *should* be simple. It<br /> is requires is the 3rd party windowing toolkit not to screw around<br /> with things. It's Qt screwing around with things that is breaking<br /> things, they have lost sight of what the
Windowing API should be doing<br /> and trading on the toes of application develop codes/3rd party SDK's<br /> like the OSG.<br /> <br /> Qt *is* broken in this respect. It really should be down to the Qt<br /> support to help you work out how to fix this.<br /> <br /> --<br /> <br /> It terms of thinking about migrating away from OpenSceneGraph to Qt3D,<br /> this might solve the Qt integration issue, but it just further cements<br /> the lock-in to Qt, you'll end up tied to their future success or<br /> failures.<br /> <br /> The future of scene graphs isn't OpenGL/OpenGL ES, it's Vulkan, so if<br /> you really want to migrate to another scene graph then it should be<br /> Vulkan based if you want it to be future proofed. Qt3D might be<br /> ported to Vulkan, but it'll still be tied to Qt and all the baggage<br /> that goes with it.<br /> <br /> Modern computing should be based around well designed and<br /> functionality focused components that can be mixed and matched as
to<br
/> the needs of the applications. One stop shop SDK's and vendors that<br /> try to give you solutions for a wide range of functionality will give<br /> you lowest common denominator solutions rather than best of breed.<br /> <br /> This philosophy isn't Qt specific, but is something that I feel<br /> developers should bare in mind when considering what tools to use and<br /> deeply they should tie themselves to them.<br /> <br /> Robert.<br /><hr /><br /> osg-users mailing list<br /> osg-users@lists.openscenegraph.org<br /> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br /></blockquote><hr /><br />osg-users mailing list<br />osg-users@lists.openscenegraph.org<br /><a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br
/></pre></blockquote></div></body></html>