On Tue, 22 Nov 2011 09:10:14 ext Adriano Rezende wrote: > 2011/11/21 Alan Alpert <alan.alp...@nokia.com>: > > On Tue, 22 Nov 2011 00:50:28 you wrote: > >> 2011/11/21 Alan Alpert <alan.alp...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development