[Development] Window{} API for QML

[Adriano Rezende]

2011/11/21 Alan Alpert <alan.alpert at nokia.com>:
> On Tue, 22 Nov 2011 09:10:14 ext Adriano Rezende wrote:
>> 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.
>
> 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.

Yes, it makes sense if that is the main reason. If we have more
control over the imports through a filter or something, we could block
high level widgets to keep the application integrity when using third
party plugins. A sandbox environment is a great feature to have in
QtQuick2. I wish I could have more spare time to work on it.

Br,
Adriano