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

[Hausmann Simon]

Hi,

I think API wise it was the right decision to make the content item the default property,
because unlike the menubar or the toolbar it is not optional. And therefore every user of
ApplicationWindow would have to specify it every time, which is pretty annoying.

The lack of default items is what annoys me the most about for example the Qt 4 based cascades API,
it requires writing what feels redundant QML code.


Simon

________________________________________
From: development-bounces+simon.hausmann=digia.com at qt-project.org [development-bounces+simon.hausmann=digia.com at qt-project.org] on behalf of Thomas Hartmann [Thomas.Hartmann at digia.com]
Sent: Tuesday, July 02, 2013 10:26
To: development at qt-project.org
Subject: Re: [Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders

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.


_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development