[Development] QML import versions

[Rutledge Shawn]

On 18 Sep 2015, at 20:15, Nurmi J-P <jpnurmi at theqtcompany.com> wrote:

>> On 18 Sep 2015, at 17:33, Robin Burchell <robin+qt at viroteck.net> wrote:
>> 
>> On Fri, Sep 18, 2015, at 05:12 PM, Nurmi J-P wrote:
>>> - QtQml 2.2
>>> - QtQml.Models 2.3 (++)
>>> - QtQuick 2.6 (++)
>>> - QtQuick.Particles 2.0
>>> - QtQuick.Controls 1.5 (++)
>>> - QtQuick.Layouts 1.3 (++)
>>> - QtQuick.Dialogs 1.2
>> 
>> You missed QtQuick.Window I think :)
>> 
>> ... which brings me to this:
>> 
>>> Is this something that would be possible to implement already in Qt 5, or
>>> is this Qt 6 material? Does someone strongly oppose the idea?
>> 
>> I have some opposition to the idea because it entirely prevents us from
>> making changes if they are needed. An example of this came up just the
>> other day on IRC: Window{} has a number of major (or at least quite
>> irritating) flaws. A few of us were discussing whether/how it would be
>> possible to fix them in a QtQuick.Window 3.0, without breaking backwards
>> compatibility with older code, and without waiting for Qt 6.
> 
> I think it’s a reasonable trade-off. Qt has lived with this restriction for quite long. :)
> 
> If this is about the Item-based Window, would it make sense to give a different name? Panel? Popup? There’s also something related in the works in Qt Quick Controls 2.

To me, neither of those names create a mental image of a decorated window on a desktop system.  They allow me to continue to wonder if you are looking beyond menus and combo-boxes.

We are talking about a direct replacement for Window, just as flexible as the existing one, but additionally capable of being a simulation of a window on devices that can’t have real windows.  That’s the main reason it needs to be an Item rather than a QQuickWindow.  Other behaviors like being a popup or omitting the frame can be achieved with flags, just as they are now with Window.  We should be able to keep the API the same, as much as possible.