[Development] Window{} API for QML
Alan Alpert
alan.alpert at nokia.com
Tue Nov 22 00:37:33 CET 2011
On Tue, 22 Nov 2011 09:10:14 ext Adriano Rezende wrote:
> 2011/11/21 Alan Alpert <alan.alpert at nokia.com>:
> > On Tue, 22 Nov 2011 00:50:28 you wrote:
> >> 2011/11/21 Alan Alpert <alan.alpert at nokia.com>:
> >> > On Mon, 21 Nov 2011 17:26:44 ext Alan Alpert wrote:
> >> >> On Tue, 15 Nov 2011 19:24:50 ext Alan Alpert wrote:
> >> >> > Window{ //Not inheriting QQuickItem, creates a new top level
> >> >> > window.
> >> >> >
> >> >> > property int x
> >> >> > property int y
> >> >> > property int width
> >> >> > property int height
> >> >> > property bool visible
> >> >> > property Orientation requestedOrientation // { Portrait,
> >> >> > Landscape, Š }
> >> >> >
> >> >> > }
> >> >>
> >> >> http://codereview.qt-project.org/#change,9258 in qtdeclarative and
> >> >
> >> > Whoops, that should be http://codereview.qt-project.org/#change,9352
> >> > in qtdeclarative.
> >>
> >> I think it's in a good shape for an initial API.
> >> Some missing features can be added later, like min/max size, modality
> >> and so on.
> >>
> >> Is the Window module really necessary. I think it's a bit redundant to
> >> have Window.Window { }.
> >
> > It's a lot redundant, I was just exaggerating it for the examples.
> > Obviously normal use will be merely
> >
> > import QtQuick.Window 2.0
> >
> > Window{
> > }
> >
> > But the ability to create new top-level windows sounds like the sort of
> > thing you might want to turn off in some cases (e.g. if you're writing
> > an application scriptable in QML). Making it a separate import makes it
> > easier to turn off later.
>
> Yes, I mean if QtQuick2 is designed to reduce memory footprint for
> non-ui applications it makes sense to keep UI components in a separate
> module. I'm just arguing that if the Window module will just contain
> the Window component, it wouldn't worth it to keep this component in a
> separate module, since there are other UI components much less useful
> like the Flipable and the Flow components.
QtQuick 2 is designed for GUI applications only. If you don't want a GUI, then
you shouldn't have to import QtQuick 2 at all in your QML application. And we
do segregate some large groups of components for footprint reasons, like how
QtQuick.Particles 2.0 is separated until you want particle effects.
But the Window{} element is segregated because you'll want more control over
it. Let's say no-one ever uses Flow, but there's still no harm to being able
to create a Flow{} if you're feeling quirky that day.
Imagine that you are using QML as a scripting language for your application.
It allows someone to place MyApp.Button{} where ever they want on the input
form. It's reasonable to allow other graphical primitives in there, like a
Rectangle{}, but you don't want them to create a new Window{} and spoof the
main view of the application (no need to make malicious scripts easy). It
hasn't been implemented yet but it should be possible to say, if you control
the QDeclarativeEngine, allow just these modules: "MyApp.*", "QtQuick 2.0" and
"QtQuick.Particles 2.0". That way you have a more controlled scripting
environment that doesn't open your application to the problems of scripts
creating new windows or loading arbitrary C++ plugins.
--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
More information about the Development
mailing list