[Interest] Using Qt as backend for plugin to be loaded on a host software
Sze Howe Koh
szehowe.koh at gmail.com
Wed Sep 16 17:05:27 CEST 2015
On 16 September 2015 at 21:36, Nuno Santos <nunosantos at imaginando.pt> wrote:
> I’m developing a plugin to be loaded by a music software host (VST). There
> are some lighter alternatives to provide graphics, network and other kinds
> of useful resources but I want to use Qt. I simply Love Qt!
> When the plugin is open by the host, it provides a window ref to the plugin.
> On Window it is a HWND handle, on Mac it is supposedly a WindowRef.
> I have a working prototype for Windows. I don’t think it is all correct but
> its working. When the plugin is first started I check for the existence of a
> QApplication and start one if not.
> Then I create the main controller for my plugin and the QQuickView to draw
> on the window. To create the QQuickView i’m first creating a QWindow with
> the ptr to HWND handle as parent:
> window = QWindow::fromWinId((WId)ptr);
> view = new QQuickView(window);
> view->rootContext()->setContextProperty("controller", _controller);
> This is actually working quite well on Windows. The same strategy however,
> doesn’t work on a Mac. When I try to create a QWindow::fromWinId the result
> is a crash with the following stack trace:
> 2015-09-16 14:26:18.526 Live[91339:1091079] -[NSHIObject
> setPostsFrameChangedNotifications:]: unrecognized selector sent to instance
> - The first question is: what is QWindow::fromWinId is expecting to be able
> to create a window? An NSView?
> - The second question is: the stack trace says that NSHIObject didn’t
> recognized the selector setPostsFrameChangedNotifications. What is a
> NSHIObject? I can only find references to HIObject from the HIToolbox and
> that belongs to the Carbon frame work. So far I haven’t been able to call
> Carbon methods inside my Qt environment even referencing -framework Carbon
> - Third question: On window I have an issue with the QApplication args and
> argv. On debug, there is an ASSERT that says that origArgc is different from
> the actual argc/argv. On release mode it crashes. Why does QApplication
> needs to receive the exact same arguments as the initial app?
> - Fourth question: how should I keep my run loop running without depending
> on the host? On Windows I have created a windows thread to call
> qApp->exec(). Although a warning that exec should be called on main thread
> it WORKS! How safe is this? Is there any other recommended option? What
> about Mac OS X?
I don't have experience with your other questions, but I know this one.
This approach works fine on Windows; I'm doing something similar in my
current project. Q(Gui)Application can be safely created in a non-main
thread. Just make sure that you all create all your GUI classes and
run their methods in that same thread.
However, this approach won't work on OS X. Cocoa requires all GUI
operations to be performed in the main thread:
For OS X, see the comments under the answer at
-- Kuba Ober suggests a way to inject your Qt code into your main
thread. Note: I don't have a Mac, so I have never tested this myself.
Please let me know if it works, because I'd like to support OS X with
my project in the future.
(Note: One difference between my project and yours is that I only
create new windows in my plugin; I don't use Qt to manipulate an
existing window. I don't know if this will make a difference to you or
> I have been google a lot specially about the NSHIObject and I can’t find an
> answer, not even a simple lead. The closest I have is vstgui, a GUI
> framework for VST plugins that has open source code and support for Carbon
> and Cocoa backends but the NSHIObject is intriguing me because I can’t find
> any explicit reference on how to deal with it.
> Any thoughts would be high appreciated.
> Thanks in advance,
> With my best regards,
More information about the Interest