[Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders

[Thomas Hartmann]

Hi,

the "problem" is that the ApplicationWindow/Window contains a 
contentItem and redirects the default property to this contentItem.

This means Window looks and behaves like an Item when it comes to adding 
children and even anchoring. Therefore we have to treat it like an item 
for most cases like reparenting or anchoring, but not in all cases like 
states or deeper in the stack: painting.

We have to live with the current solution anyway, but there would have 
been alternatives like:

ApplicationWindowItem {
     applicationWindow.menuBar: Menu {
     }

     applicationWindow.statusBar: StatusBar {
     }

    applicationWindow.toolBar: ToolBar {
    }
}

In this case from the C++ side not too much would change, but the 
ContentItem would own the Window. There is still a one to one 
relationship from the ContentItem to the Window and there would be litte 
difference between ApplicationWindowItem and our current 
ApplicationWindow other then the fact that ApplicationWindowItem really 
is the contentItem not just redirects its default property.
Note that ApplicationWindowItem would support states out of the box.

If you look at it from a prototype based inheritance view it might get 
clearer. When using prototype based inheritance an x is an y if it 
behaves like an y (No static class hierarchies).

In the ApplicationWindow case it behaves like an y in many cases, 
because of the default property redirected to an Item. Actually if 
treated as a fixed/static root item it behaves in all cases like an 
Item, except when it comes to states. Therefore I think it would have 
made sense to turn ApplicationWindow into a full blown y/Item
(Than cannot be the child of another Item, though).

This is the pure QML view. I do understand that from the C++ perspective 
Window is quite special, because it holds its own QtQuickView.

 From the tooling perspective this means that we have to deal with
ApplicationWindow/Window in many places since it behaves like a normal 
root Item and can be the target of anchors, while there is always a 
level of indirection to the contentItem.

In the case that the contentItem would have been explicit:

ApplicationWindow {
     menuBar: Menu {
     }

     statusBar: StatusBar {
     }

    toolBar: ToolBar {
    }

    contentItem: Item {
    }
}

we could at least "skip/ignore" the ApplicationWindow for all code that 
handles anchors, transformations etc, because we are only interested in 
the contentItem.


Kind Regards,
Thomas Hartmann

Am 02/07/2013 09:46, schrieb Sletta Gunnar:
> The ApplicationWindow encapsulates a completely different concept compared to normal items and trying to treat them as the same in the design tool makes very little sense.
>
> The ApplicationWindow floats stand alone in the windowing system, it may have menu bar, status bar and toolbar, all of which require dedicated support from the designer to be designable. And the code generated does not go into a QQuickView, but needs to be created as via QQmlComponent::create() as it creates the window itself.
>
> If we want that and if there is time and resources to do it is a different topic. I think we can live without it, at least for while.
>
> cheers,
> Gunnar
>
> On Jul 1, 2013, at 11:56 AM, Bubke Marco <Marco.Bubke at digia.com> wrote:
>
>>
>> Alan Alpert:
>> The items-in-a-scene is an implementation detail (albeit one of the
>> biggest ones), but if you can provide a better implementation for the
>> existing APIs then that would be ideal. If not, we need to start
>> considering trade-offs instead, and maybe these other use-cases are
>> not as important as the application running with high performance
>> on-device. The initial usecases were not MDI, and were not even
>> multi-window. We aren't going to throw in extra abstraction layers for
>> a "potential future". It's much better to maintain flexibility to be
>> able to add abstractions later on, even though abstractions are
>> easiest to implement at the start. One of the hopes for the QML-only
>> API of QtQuick is that we are only restricted by QML versioning
>> (separate from Qt versioning), and this gives us more flexibility.
>>
>> If we implement it new I would opt for a approach where a item would have something like a property isApplicationWindow. This item would be than wrapped in a Window. I think MDI would be possible too with this approach.
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>


-- 
Thomas Hartmann
Software Engineer
Nokia, Qt Development Frameworks

Digia Germany GmbH

Rudower Chausse 13, 12489 D-Berlin

Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht 
Charlottenburg, HRB 144331 B,
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius

Email: thomas.hartmann at digia.com


Digia Germany is a group company of Digia Plc,

Valimotie 21, FI-00380 Helsinki Finland

Visit us at: www.digia.com

------------------------------------------------------------------

PRIVACY AND CONFIDENTIALITY NOTICE

This message and any attachments are intended only for use by the named 
addressee and may contain privileged and/or confidential information. If 
you are not the named addressee you should not disseminate, copy or take 
any action in reliance on it. If you have received this message in 
error, please contact the sender immediately and delete the message and 
any attachments accompanying it. Digia Germany GmbH and Digia Plc do not 
accept liability for any corruption, interception, amendment, tampering 
or viruses occurring to this message.