[osg-users] osgQt + OSG 3.6.2 Status

[Joshua Tree]

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.

Now, there are huge firms that adopted Qt for decades and run multi billion dollars systems on it. 

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.


 I have used Qt and OSG back in 2003, 15 years ago with success. 

> On Jul 27, 2018, at 12:03 PM, Robert Osfield <robert.osfield at gmail.com> wrote:
> 
> Hi Andrew,
> 
>> On Fri, 27 Jul 2018 at 17:14, Andrew Cunningham <andrewC at mac.com> wrote:
>> I would agree QT is not perfect but on the flip-side
>> - It is the 'last man standing' of x-platform UI's.
> 
> This is down to the weakness of the alternatives rather as much as the
> strength of Qt.
> 
>> - It's actively developed using the latest C++11/14 standards and supported by both a commercial organization and a robust LGPL community
> 
> Will they get rid of the non standard C++ extensions and pre-compiling nonsense?
> 
>> - Is has a new lease of life through PyQT5 and PySide being the 'de-facto' way to build Python based desktop UI's.
>> - QML is quite interesting
> 
> There is simply too much pushed into Qt over the years. The lack of
> focus on the core functionality hurts it.
> 
> I say this from experience, we've pushed too much functionality into
> the OpenSceneGraph distribution over the years, I can see the
> mistakes, but with backwards compatibility being an important factor
> for end users it's not easy to just make radical changes.
> 
> What the computer industry is a nice neat, small C++11 UI library with
> good hooks to building scripting integration on top of.
> 
>> 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.
> 
> OSG integration with 3rd party windowing toolkits has generally been
> pretty straight forward - once the basics have been written it doesn't
> take much to update and keep things working.
> 
> Our experience with Qt is not like this at all.  X11, Win32 they've
> been pretty rock solid for way over a decade now.  OSX has required
> jumping through a hoops because Apple doesn't care about developers as
> much as it cares about vendor lock-in.
> 
> Over the years the OSG hasn't added extra burden on the 3rd party
> windowing toolkits, it's exactly the same as it has always been, just
> create a GL context and allow the OSG to call makeCurrent() and
> swapBuffers and we are pretty well done.  It *should* be simple.  It
> is requires is the 3rd party windowing toolkit not to screw around
> with things. It's Qt screwing around with things that is breaking
> things, they have lost sight of what the Windowing API should be doing
> and trading on the toes of application develop codes/3rd party SDK's
> like the OSG.
> 
> Qt *is* broken in this respect. It really should be down to the Qt
> support to help you work out how to fix this.
> 
> --
> 
> It terms of thinking about migrating away from OpenSceneGraph to Qt3D,
> this might solve the Qt integration issue, but it just further cements
> the lock-in to Qt, you'll end up tied to their future success or
> failures.
> 
> The future of scene graphs isn't OpenGL/OpenGL ES, it's Vulkan, so if
> you really want to migrate to another scene graph then it should be
> Vulkan based if you want it to be future proofed.  Qt3D might be
> ported to Vulkan, but it'll still be tied to Qt and all the baggage
> that goes with it.
> 
> Modern computing should be based around well designed and
> functionality focused components that can be mixed and matched as to
> the needs of the applications.  One stop shop SDK's and vendors that
> try to give you solutions for a wide range of functionality will give
> you lowest common denominator solutions rather than best of breed.
> 
> This philosophy isn't Qt specific, but is something that I feel
> developers should bare in mind when considering what tools to use and
> deeply they should tie themselves to them.
> 
> Robert.
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org