On Fri, 27 Jul 2018 at 18:19, Joshua Tree <mocca...@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.osfi...@gmail.com> > > wrote: > > > > Hi Andrew, > > > >> On Fri, 27 Jul 2018 at 17:14, Andrew Cunningham <andr...@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@lists.openscenegraph.org > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org