[osg-users] osgQt + OSG 3.6.2 Status

[Robert Osfield]

On Fri, 27 Jul 2018 at 18:19, Joshua Tree <mocca4us at outlook.com> wrote:
>
> 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 exactly the same can be said for the OSG.  Doesn't mean


> 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
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org