[Development] Foreign windows, embedding and transiency

Alberto Mardegan mardy at users.sourceforge.net
Tue Dec 11 13:30:17 CET 2012

On 12/11/2012 12:47 PM, Sorvig Morten wrote:
> I've been planning this a bit from he perspective if the Cocoa port, here's what I think I need:
> - A Qt::WindowFlags flag ("Qt::NativeWindow")

OK. Though I'd prefer to call it Qt::ForeignWindow, to make it obvious 
that it's not owned by this process (Qt::NativeWindow just seems to tell 
that the QWindow is associated with a native window, which is always 
true, AFAIU).

> - An basic API for setting the native window*, for example a function exported by QPlatformNativeInterface.
> - Nice API in QtMacExtras

What API would you need?

> - The implementation itself in the cocoa plugin.
> I don't think we should create QWindow subclass. We could add a constructor instead of using QPlatformNativeInterface, and then we would perhaps not need a flag either.

I'd rather use a constructor than the QPlatformNativeInterface, and 
Samuel's idea of using a static one is also nice. The reason why I was 
suggesting a different class is simply to keep the QWindow code as 
simple as possible; QWindow for foreign windows might need to have a 
special implementation for the virtual methods inherited from QSurface 
(BTW, we might want to add a "Foreign" enum value to 
QSurface::SurfaceType). Having it as a separate subclass could also help 
with the documentation, by avoiding putting a lot of different concepts 
into QWindow's. But indeed having a subclass is not strictly needed.

However, the flag is needed: the QPA plugin needs to know whether a 
QWindow is foreign or not. The xcb plugin would also take care of 
implementing the XEmbed protocol when it sees that the parent window is 
Unless we can convey the same information in another way, of course.


More information about the Development mailing list