[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
foreign.
Unless we can convey the same information in another way, of course.
Ciao,
Alberto
More information about the Development
mailing list