[osg-users] osgQt + OSG 3.6.2 Status

Sat Jul 28 08:38:17 PDT 2018

Hi Joshua,
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.
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.
So we are happy with the combination of qt and osg. Both are reliable, stable and have excellent features in their field. 
Werner

On 27. Juli 2018 19:19:17 MESZ, 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20180728/4608af92/attachment.html>