[Development] Foreign windows, embedding and transiency

[Samuel Rødal]

On 12/11/2012 12:45 PM, Sletta Gunnar wrote:
>
> On Dec 11, 2012, at 12:33 PM, Samuel Rødal <samuel.rodal at digia.com>
>   wrote:
>
>> On 12/11/2012 12:03 PM, Alberto Mardegan wrote:
>>> Hi all,
>>>     while digging a bit more deeply into the code of QX11EmbedWidget (in
>>> order to port it to Qt5), I started wondering if we really need a
>>> special API for embedding, or whether QWindow could already offer most
>>> of it:
>>>
>>> ==========
>>>     QWindow::QWindow(QWindow * parent)
>>>
>>>     Creates a window as a child of the given parent window.
>>>
>>>     The window will be embedded inside the parent window, its coordinates
>>>     relative to the parent.
>>> ==========
>>>
>>> What about adding an API to create QWindow objects for foreign windows
>>> as well? (by "foreign window" I mean a window created by another process)
>>>
>>> Then we could provide embedding functionality by using the QWindow
>>> constructor or the QWindow::setParent() method. Also, the
>>> QWindow::setTransientParent() could be use to set our QWindow as
>>> transient for a foreign window.
>>> Of course, this might not work in all platforms, but the documentation
>>> could explain where it works and where it doesn't.
>>>
>>> In order to create a QWindow for a foreign window, there might be a
>>> special subclass of QWindow (QForeignWindow?) or maybe it could just be
>>> a QWindow with a special Qt::ForeignWindow flag (and maybe a constructor
>>> like QWindow::QWindow(WinId foreignWindow)).
>>>
>>> Your opinions on which way foreign windows could be created (and on
>>> whether all of this sounds like a good idea to you) are very welcome. :-)
>>
>> This worked for QWidgets in Qt 4 by passing a native window handle (WId)
>> to create(). However, then we also knew at compile time what the native
>> windowing system would be.
>>
>> Is it possible to define a WId type that will work on X11, Wayland, and
>> any other theoretical windowing system on Unix platforms?
>
> We already have the WId in the QPlatformWindow::winId() function. It is #define'd as a quintptr. If that is not good enough for this usecase then it won't do much good for QPlatformWindow::winId() either.

True. I guess the API could look something like "static QWindow 
*QWindow::fromWinId(WId id)". Are there any other reasons to introduce a 
QForeignWindow API? For instance new methods that would not make sense 
for any QWindow?

--
Samuel