[osg-users] osgQt + OSG 3.6.2 Status

[Robert Osfield]

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.