[Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders
Gunnar.Sletta at digia.com
Tue Jul 2 09:46:16 CEST 2013
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.
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
More information about the Development