[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