On 3/16/2011 3:41 PM, ext Adriano Rezende wrote:
>> Question to the list; are there better techniques for exposing properties to
>> a common element from a specific implementation - and be able to use such
>> properties in the implementation effectively? Can attached properties be
>> used for this without breaking the ability to deploy the App to a different
>> platform that doesn't have this property?
>
> We could provide some elements to handle these platform specific parts
> in a more declarative way, using bindings and connections. A possible
> approach would be as follows:
>
> ===
> Button {
> id: button
>
> // active binding when platform is meego
> PlatformProperty { target: button; platform: "meego"; name:
> "color"; value: "red"; }
>
> // active binding when platform is symbian
> PlatformProperty { target: button; platform: "symbian"; name:
> "foobar"; value: 1; }
> PlatformProperty { target: button; platform: "symbian"; name:
> "font.pixelSize"; value: 30; }
>
> // listen for signals when platform is symbian
> PlatformConnections { target: button; platform: "symbian";
> onFooBarChanged: print(button.platform.foobar); }
> }
> ===
>
> So we could handle these 'ifdefs' in an more elegant way, providing a
> portable source code.
>
> Accessing these properties directly would result in a non-portable or
> a non-declarative source code. Like the following:
>
> ===
> Button {
> platform.color: "red"
> platform.foobar: 4 // this will crash on meego, since foobar does not
> exist
>
> onFooBarChanged: {
> // this will crash on meego, since foobar does not exist
> }
> }
>
> Button {
> Component.onCompleted: {
> if (qt_components_platform == "meego")
> platform.color = "red";
> else if (qt_components_platform == "symbian")
> platform.foobar = 4;
>
> // handle specific connections
> }
> }
> ===
>
> A possible implementation for the PlatformProperty can be as follows:
>
> ===
> import Qt 4.7
>
> Binding {
> id: binding
> property string name
> property string platform
>
> property: "platform." + name
> when: binding.platform == qt_components_platform // global context
> }
> ===
I can't help but think that this problem should be solved on the QML
language / QtDeclarativeEngine level. What if QML 2.0 would support
conditional imports, e.g.
import QtQuick 2.0
import qt.components 2.0
conditional import com.meego 2.0 as meego
conditional import com.symbian 2.0 as symbian
Button {
text: "Hello World"
meego {
color: "white" // common property
}
symbian {
color: "black" // common property
autoRepeat: true // symbian specific
platformStyle: ButtonStyle {
// whatever
}
}
}
Don't take either the syntax nor the concrete properties too seriously.
Anyhow, has anybody discussed ideas like that with the core developers
of QML?
> However, I dislike the idea of having to handle multiple platforms in
> the source code. IMO Nokia needs to converge to a single API for all
> platforms Symbian, Meego and future ones.
It's not only about the API. You want to have properties set to
different values, use different icons, etc. for different platforms,
even if the API is the same. That's just not very well supported right
now in the language.
Regards
Kai
> Currently, if the difference between these APIs are small. I would
> prefer to have a few redundant properties/signals in the common API,
> instead of having to handle these extensions in my code.
>
> Br,
> Adriano
> _______________________________________________
> Qt-components mailing list
> Qt-components@qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-components
--
Kai Koehne
Software Engineer
Nokia, Qt Development Frameworks
Nokia gate5 GmbH
Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany
Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B
Umsatzsteueridentifikationsnummer: DE 812 845 193
Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori
_______________________________________________
Qt-components mailing list
Qt-components@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-components
