Does anyone have experience or recommendations of having Qt and LibCinder play together? I’ve found next to no previous code or even discussion topics on here apart from this one.
My current understanding of Qt is that it must have its QWindow executing on the main GUI thread. All my use of LibCinder has simply relied on Cinder to manage the window, but if I were to introduce Qt, they somehow have to share the Window and render context, and I honestly am a little lost at where to start. All ears if someone has some pointers.
As for why even do this? I’ve been looking for a C++ based Gui library that supports multi-touch which honestly isn’t easy to find. I’ve spent a few weeks with NoesisGui and found their WPF/Xaml approach difficult to work with, so I’m revisiting the question of which library to pick for the long haul. Qt isn’t exactly glamorous but it has pretty much everything you could want out of a basic GUI, I just have no idea of how to make it play nice along side Qt since they both seem to want to own the application window.
I use libcinder extensively for it’s wonderful OpenGl rendering classes, so while I’m ok with a solution where Qt becomes the main window ‘host’ so to speak, I don’t want to entirely give up on rendering some parts using libcinder.
I think it would only be a pleasant setup if Qt handled all of the windowing and GL context setup. ci::gl has the ability to share OpenGL contexts, so you’ll have to dip into that if you want to use things like ci::gl::Batch or ci::gl::Fbo, etc. Doesn’t seem like there’s anything stop that though, and you can also still use any of cinder’s utility classes, ones that don’t realy on the ci::app or ci::gl namespaces.
I agree, I think Qt would behave best (if at all) it handles all the windowing and GL context setup as you mentioned. But… Is there any way to ‘start up’ cinder without the windowing and GL context created by libcinder?
I’m not familiar with any code or examples that achieve this…?
Cinder doesn’t need to be ‘started’ if you are not making an app::AppBase (subclassed for whatever platform you’re on). Since about 0.9.1 or so we separated out non-windowing functionality into the app::Platform global class that can be used for things like loading assets, setting up the base loggers, etc, so if you do need things like that it is still accessible. The original use case here was to command line based tools, such as HTTP clients and asset prepropcessors, but also for game engine plugins and things like that.
Also, if you do a code search for app::Platform::get() in the main cinder codebase, you’ll see that we use it throughout rather than app::whatever(), because Platform doesn’t assume that a windowing envirotnment exists.
The tricky part in getting this to work (which I think would be really cool, gaining the graphics power of cinder with the GUIs of QT), will be getting ci::gl::Context::createFromExisting() ([source line](https://github.com/cinder/Cinder/blob/8998b3f51ea4ef33a5b0e89567fbacd22b76a444/include/cinder/gl/Context.h#L82)) to work. Only code examples I see on a quick skim are how all of cinder's app::Renderer's use it when initializing their window. But keep in mind that cinder's ci::app::RendererGland friends are only meant to be used with aci::app::Window`, not what you want.
Noting the comment above that method here as well:
//! Creates based on an existing platform-specific GL context. \a platformContext is CGLContextObj on Mac OS X, EAGLContext on iOS, HGLRC on MSW. \a platformContext is an HDC on MSW and ignored elsewhere. Does not assume ownership of the platform’s context.