No, what I was talking about doesn't require that everything be in one process or be solely Qt. 

The simple case I mentioned allows any mixture of processes using any type rendering, Qt, OpenGL, HTML5.  It's just in 
this case because there is no window manager the applications themselves are responsible for their own layout.  If the 
set of windows display on the screen is fixed then this can work OK.  Each process arranges to create their window with 
the appropriate size and positions it at the appropriate place and you're done.

Where this doesn't work is where things need to be more dynamic, especially if you're aiming for fancy effects.  If you 
want to have windows come and go and change positions then it helps to have something central to do this which is where 
window managers come into the picture.  If you're developing a product like a typical smartphone you need a window 
manager, if it's something like a medical device which has a fixed set of windows in a fixed arrangement then you might 
not.

A window manager can be a regular graphical application which has its own windows or it can do nothing but window 
management.  The restriction about Qt apps acting as window managers is that to do anything in screen you have to create
 a screen context and their are two types of them, application contexts and window manager contexts and the current QNX 
plugin creates a application context.  If you're writing a Qt app there is nothing to prevent you from creating a 
separate window manager context it's just that Qt doesn't do anything much to help you.

I'm not sure when the new plugin will be available (I'm no longer working on Qt).  We are actively working on 
upstreaming the code so the time depends partially on how long it takes to get the Qt community to accept it.  I've no 
idea when QNX would provide binaries for it though once it has been upstreamed the source will be publically available. 
 One complication with it is there are aspects of it that make use of new features of screen that have not yet been 
released, they're not essential for most of the core functionality but they make it all a little harder.


________________________________________
From: Nick Barton [community-noreply@qnx.com]
Sent: Thursday, February 04, 2016 4:00 AM
To: ostech-core_os@community.qnx.com
Subject: RE: QT with composite windows

Thanks for your email Roger

I don't think the first solution will be enough as it won't provide the ability to mix technologies i.e. QT apps, Open 
EGL apps, HTML5 apps.

Also if I've understood you correctly, they won't be separate QNX processes but QT threads running QT Windows i.e. it 
would still be a monolithic app. I'm trying to avoid that architecture as it is cumbersome to maintain, inflexible in 
deployment to different product streams (we have many derivitave products that have more or less features), harder to 
manage the processes i.e. mapping resources to a HMI process that implements safety function, also control via the High 
Availability Module HAM.

When will the plugin you are working on be available?

-----Original Message-----
From: Roger Maclean [mailto:community-noreply@qnx.com]
Sent: 03 February 2016 17:01
To: ostech-core_os@community.qnx.com
Subject: RE: QT with composite windows

I don't entirely understand your question but I'll try to provide some information that might help.

Each QWindow is associated with a separate screen window.  If you have multiple Qt processes, each with a QWindow with 
their x, y, width and height properties set so that they are not totally overlapping they should all show up on the 
screen at the same time.  This might be enough if your needs are very simple i.e. you have a fixed layout of the screen.

If you require more than this you are likely to want a process to act as a window manager.  This will get events from 
screen notifying it of the creation of top level windows from other processes and it can change positions, z-order, 
displayed sizes and visibility of these...