I have a Qt application that needs to be used from a VST plugin. However embedding a Qt application into a plugin seems like an incredibly complex task (because of the QCoreApplication event loop, because the host might also use a conflicting version of Qt, and because the plugin needs to find its own set of Qt libraries).
As a workaround I'd like to render my standalone Qt application to the VST plugin's window (for which I know the HWND/NSView).
It's easy to do on Windows, but a little more tricky on macOS.
tldr: I've read about NSWindowSharingType / NSWindowSharingReadWrite which seems to offer what I need on macOS (rendering a process' window into another process' window), but I can't find any example using that.
Does anybody know about that and how to use it ? Or any other way that would allow me to render my Qt widgets into a NSView from a different process ?
The solutions for this are quite nominal:
Your copy of Qt must be put into its own unique namespace - i.e. you have to build your own Qt. In a professional setting you're supposed to be doing this anyway.
The QCoreApplication event loop is fully integrated with NSRunLoop. You don't need to call exec() other than to prime the event loop: i.e. quit the event loop as soon as it is started, and let the host application do the rest. The idiom for this is:
QTimer::singleShot(0, app, &QCoreApplication::quit);
app->exec();
// return to the host app here
The plugin can and should bundle its own Qt, either as a bundled framework, or through static linking.
You can also pass an NSView* to QWindow::fromWinID, IIRC.
Related
I'm running Lazarus Pascal (1.4.2, FPC 2.6.4) on a Intel Mac OS X (10.10) and would like my application window to be visible on all virtual desktops (Spaces). How can I achieve this?
I'm using the Carbon widget set, as the Cocoa widget set is still in early stages of development.
Note: I realize this question is very similar to this StackOverflow question, however that question is geared towards Objective-C. I have no clue how (in Carbon) to use the code suggestion. Mostly because it is Cocoa specific, but also because I have no idea how to link this behavior to my TForm - if that is even possible.
You can use method setCollectionBehavior: of NSWindow with the
NSWindowCollectionBehaviorCanJoinAllSpaces bitwise flag.
Since I can apply the "All Desktop" option in Finder, when I have multiple virtual desktops/spaces, maybe there is an alternative to set this outside of the application? (i.e. something like using "defaults" in Terminal)
I'm writing an application with plugin support. I use C++ and JUCE for that stuff and I want my application to run on windows and MAC OSX (and maybe linux some day).
My plugins have their own GUI. The usual way to display a GUI from a shared library seems to be :
create a new window
get the native handle for it
pass it on to the library
let the library attach its GUI to that handle.
AFAIK that always requires to create a new window for the plugins GUI. My problem is: I would like to have the GUI of the plugins to appear inside the GUI of my host application (= not as a separate window).
I think this is a common thing to do, but I just can't find any concepts for that. How would you solve such a problem?
Thank you very much for ideas and hints!
I'm making a library that will act as a graphics aid, and one of the things I wanted to add was it's own Window creation.
I've seen how people use the default windows code in a Windows application, but that would only work in that project not the library.
Is it possible to add in window creation code into a library and have it behave in such a way like :
windowClass instance = libraryCreateWindow(blah,blah);
instance.showWindow();
Yes, it's possible. There is effectively no difference in creating a window from a library than from the main executable.
Windows belong to a process and are associated with a thread, it doesn't matter where in the code or in what module the window is created. I'm not sure what you're basing the statement "that would only work in that project not the library" on.
You didn't specify whether you were talking about a dynamic or static library, a C++ class library, or even a C#/.NET library, and the implementation details obviously differ depending on language and framework, but the answer should still be yes for any of the above.
I would like to ask the SO community for the following information:
- Is it possible to compile WebKit for Windows8-Metro Environment, either in the form of a WinRT component or just as a linked library in a C++/XAML application?
- Which are the main steps to achieve this goal?
- Which are the possible things that would make this not possible or very difficult?
- Is it an endeavour someone is working on just now?
- Is it possible to gather interested people so they work on this?
I think you will not be able to just "compile" Webkit for WinRT/Metro Style. Metro Style applications are restricted in the kind of API calls they can make, for example there is no GDI/GDI+/MFC for WinRT. WebKit has several building modes that you can use, you can either build it using QT as rendering engine, or using GTK, or plain GDI, but on all those cases, when you create new builds for Windows OSes you will be using GDI at the very end.
Nevertheless, you could modify Webkit source code and add a new rendering engine that uses WinRT new APIs. You could probably become famous if you do.
As a side note, even when there is a "Windows Store" version of Chrome, by looking at the source code of Chromium it seems to me that this version is just a simple app launcher that communicates with the "normal" desktop version using an IPC channel. It does not appear to be a real Windows Store build of the whole source code.
I am not sure if the WinRT environment will allow this, but there is a project called Awesomium that is a wrapper around Google Chrome and Google Chrome is based on WebKit I think. It also has a .NET wrapper, so you can embedd it onto your .NET app.
I never tried using it, neither I know about if this library is applicable with WinRT, but at least it is a start.
Awesomium
Awesomium .NET samples
DownMakerWPF, an application embedding it to display markdown.
WinRT is a combination of managed and native code, so, you have a chance to port WebKit, but remember - native code have some sandbox restrictions.
Also you can choose XNA instead.
I'm quite new to the Mac but reasonably expirienced with windows.
What I need is a window owned opened and closed by the library (dylib).
This is very easy to do in MS Windows but seems not be hard under Cocoa.
I used the code from apple's 'CocoaInCarbon' example with C++ Wrappers.
But the NSApplicationLoad() followed by [NSBundle LoadNibNamed:#"MyWindow" owner:self] fails. Is this caused by the dylib not being a bundle.
Are there alternative ways to open and control a window within a dylib?
Yes, the problem is that it's not a bundle; your nib can't possibly be inside a bundle that doesn't exist, so how would the code find it to open it?
You need to either use a framework (which is a bundle), and ship the nib in that framework, or you need to create the entire window programmatically in your dylib.
It's not a standard practice to just ship dylib on Mac, when the shared library is not very low level and involves GUI in particular. You package it into a framework, so that it can not only have codes in it, but associated resources (nibs, images, sounds) in one place.
Read this Apple document to understand what's going on and how to prepare it. Or, take a look at /System/Library/Frameworks/ to see how the OS X itself provides libraries.