Hold your horses.
There are some restrictions here and before jumping into "yeah!", let's list
them and agree if those are acceptable.
QML element needs to contain the used property i.e adding properties in QML is
not possible. In practice, we cannot have
*Button.qml*
Item {
...
property QObject platform: QObject {
property string iconSize: "medium"
}
...
}
This leads into pattern of:
#1 Need to create platform specific QML elements for each component i.e. in
this example, the MeegoButtonProperties need exits as own QML element:
*Button.qml*
Item {
...
property MeegoButtonProperties platform: MeegoButtonProperties {}
...
}
#2 cannot extend the base class implementation (even within the components
library):
*ToolButton.qml* // let's assume that ToolButton would be "derived" from Button
Button {
...
platform: MeegoButtonProperties {
property string toolbutton_specific_property
}
...
}
does not work and I could not find a way how to make it work .. also
*ToolButton.qml*
Button {
...
platform: MeegoToolButtonProperties {
}
...
}
Does not work because, the property 'platform' is type of MeegoButtonProperties
and it is not expandable (even the type of 'variant'). This leads into the
situation where the MeegoButtonProperties must contain all the platform
specific properties also from all the subclasses - the subclasses can only
change the default values.
-P
>-----Original Message-----
>From: Nurmi J-P (Nokia-MS-Qt/Tampere)
>Sent: 14.03.2011 10:52
>To: Malmqvist Mathias (Nokia-MS/London); Rantanen Vesa (Nokia-
>MS/Tampere); Jokela Pekka.E (Nokia-MS-Qt/Tampere); Hartz Henrik (Nokia-
>MS-Qt/Oslo); qt-components@qt.nokia.com; Karlsson Erik.B (Nokia-
>MS/Helsinki)
>Subject: RE: [Qt-components] Platform-specific properties in a cross-
>platform world
>
>That's nice! Don't we have a clear winner here? :)
>
>--
>J-P Nurmi
>
>
>> -----Original Message-----
>> From: qt-components-bounces+j-p.nurmi=nokia....@qt.nokia.com
>> [mailto:qt-components-bounces+j-p.nurmi=nokia....@qt.nokia.com] On
>> Behalf Of Malmqvist Mathias (Nokia-MS/London)
>> Sent: 11. maaliskuuta 2011 17:46
>> To: Rantanen Vesa (Nokia-MS/Tampere); Jokela Pekka.E (Nokia-MS-
>> Qt/Tampere); Hartz Henrik (Nokia-MS-Qt/Oslo); qt-
>> compone...@qt.nokia.com; Karlsson Erik.B (Nokia-MS/Helsinki)
>> Subject: Re: [Qt-components] Platform-specific properties in a cross-
>> platform world
>>
>>
>> Having explored the support for grouping properties a bit more, I've
>> found that
>> it kind of works, as long as you get the syntax just right.
>>
>> Below is an example that show what works. The key points are (see
>> matching
>> references in the code below):
>> (1) The grouping element has to be instantiated as a property of its
>> specific type.
>> Using a variant type does not work.
>> (2) Once the grouping element has been instantiated by its parent, it
>> can be
>> accessed by anyone creating an instance of the parent
>> (3) The on...Changed syntax works as expected too
>>
>> The only slight issue I've noticed is that the on...Changed signal
>> seems to be
>> triggered also for the initial value, not just when it changes after
>> that, as is usual.
>>
>> Note that (1) means the grouping element has to be defined in its own
>> file. I.e. this
>> won't work: property variant platform: QtObject { property string
>> iconSize: "medium" }
>>
>>
>> Here's the example of what works:
>>
>> *MeegoButtonProperties.qml:*
>> import QtQuick 1.1
>> QtObject {
>> property string iconSize
>> }
>>
>> *Button.qml*
>> import QtQuick 1.1
>> Item {
>> ...
>> property MeegoButtonProperties platform: MeegoButtonProperties {
>> // (1)
>> iconSize: "medium"
>> }
>> ...
>> }
>>
>> *MyApp.qml*
>> import QtQuick 1.1
>> Item {
>> ...
>> Button {
>> id: button
>> anchors.centerIn: parent
>> iconSource: "theIcon.png"
>> platform.iconSize: "large" // (2)
>>
>> platform.onIconSizeChanged: print("Icon size changed!") //
>> (3)
>> }
>> MouseArea {
>> anchors.fill: parent
>> onClicked: button.platform.iconSize = "small" // (3)
>> }
>> ...
>> }
>>
>>
>>
>>
>> Cheers
>> Mathias
>>
>> ------------------------------------------------------------
>> Mathias Malmqvist
>> UX Prototype Lead
>> 10 Great Pulteney Street, London, W1F 9NB, UK
>> Got no reply? Try giving me a call:
>> Mobile: +44 (0)77 6522 2738
>> http://www.nokia.com
>> ________________________________________
>> From: Rantanen Vesa (Nokia-MS/Tampere)
>> Sent: Wednesday, March 09, 2011 1:10 PM
>> To: Jokela Pekka.E (Nokia-MS-Qt/Tampere); Hartz Henrik (Nokia-MS-
>> Qt/Oslo); qt-components@qt.nokia.com; Karlsson Erik.B (Nokia-
>> MS/Helsinki)
>> Cc: Malmqvist Mathias (Nokia-MS/London)
>> Subject: Re: [Qt-components] Platform-specific properties in a cross-
>> platform world
>>
>> As we urgently need to have some convention here, we internally sat
>> down
>> together with Erik and came up with the following. Unless squashed, we
>> will go forward with it when it comes to our current styles in
>> development.
>>
>> ====
>>
>> - Private properties are named "privateSomething". For example,
>> "privateParrot".
>> - Platform/style -specific properties are named "platformSomething".
>> For
>> example, "platformPerch".
>>
>> ====
>>
>> We chose to avoid:
>>
>> - Underscores and special characters, as they are alien in QML and
>> sometimes cause problems, as illustrated in the discussion below.
>> - Names of styles/platforms/OSes themselves, as they are prone to
>> change
>> over time and subject to other non-technical restrictions.
>> - Abbreviations, as those are generally to be avoided in Qt.
>>
>> Furthermore, it would be a very good idea to isolate such properties
>to
>> different QML files altogether - and luckily if we want to go to that
>> direction in the future, we can easily do so.
>>
>> If you have an excellent counter-proposal, kindly voice that ASAP!
>>
>> Br,
>>
>> - Vesa.
>>
>> On 09.03.2011 09:42, "ext pekka.e.jok...@nokia.com"
>> <pekka.e.jok...@nokia.com> wrote:
>>
>> >There is a "feature" in QML that the property name has to start with
>> >lower case letter. Although, this is only enforced in the
>> "onXyzChanged"
>> >paradigm. Properties starting with '_' do generate the change notify
>> >signal, but the only way they can be utilize that is to create own
>> >property as
>> >
>> >SomeComponent {
>> > variant myCopyProperty: _property // platform specific property
>in
>> >SomeComponent
>> > onMyCopyPropertyChanged: console.log("_property changed")
>> >}
>> >
>> >This isn't too appealing for the developers.
>> >
>> >Can one make signal connections in QML? The documentation is always
>> >"connecting" to the onXyzChanged convention - not to the actual
>> >xyzChanged signal.
>> >
>> >The grouped properties would be THE solution, but unfortunately not
>> >possible.
>> >
>> > -P
>> >
>> >>-----Original Message-----
>> >>From: qt-components-bounces+pekka.e.jokela=nokia....@qt.nokia.com
>> >>[mailto:qt-components-bounces+pekka.e.jokela=nokia....@qt.nokia.com]
>> On
>> >>Behalf Of ext mathias.malmqv...@nokia.com
>> >>Sent: 04.03.2011 20:09
>> >>To: Hartz Henrik (Nokia-MS-Qt/Oslo); qt-components@qt.nokia.com
>> >>Subject: Re: [Qt-components] Platform-specific properties in a
>cross-
>> >>platform world
>> >>
>> >>
>> >>In the "custom" branch implementation I've stayed away from using
>the
>> >>"__" prefix
>> >>altogether, mainly because QML fails to automatically create the
>> >>"Changed" signals
>> >>for these properties. I.e. if a property is defined like this
>> >>
>> >>property bool __myPrivateProperty
>> >>
>> >>this won't work
>> >>
>> >>on__myPrivatePropertyChanged: print("it changed!")
>> >>
>> >>nor will this:
>> >>
>> >>__onMyPrivatePropertyChanged: print("it changed!")
>> >>
>> >>
>> >>I'm not sure I like the __ convention, but it's probably just
>because
>> >>I'm not a JS developer
>> >>and haven't got used to seeing it.
>> >>
>> >>Anyway, just created http://bugreports.qt.nokia.com/browse/QTBUG-
>> 17950
>> >>
>> >>Grouped properties could perhaps be used for private and platform
>> >>specific properties, but
>> >>the necessary support is lacking, see
>> >>http://bugreports.qt.nokia.com/browse/QTBUG-15269
>> >>
>> >>
>> >>Cheers
>> >>Mathias
>> >>
>> >>------------------------------------------------------------
>> >>Mathias Malmqvist
>> >>UX Prototype Lead
>> >>10 Great Pulteney Street, London, W1F 9NB, UK
>> >>Got no reply? Try giving me a call:
>> >>Mobile: +44 (0)77 6522 2738
>> >>http://www.nokia.com
>> >>________________________________________
>> >>From: qt-components-bounces+mathias.malmqvist=nokia....@qt.nokia.com
>> >>[qt-components-bounces+mathias.malmqvist=nokia....@qt.nokia.com] on
>> >>behalf of ext henrik.ha...@nokia.com [henrik.ha...@nokia.com]
>> >>Sent: Thursday, March 03, 2011 3:43 PM
>> >>To: qt-components@qt.nokia.com
>> >>Subject: [Qt-components] Platform-specific properties in a cross-
>> >>platform world
>> >>
>> >>Hi,
>> >>
>> >>After some internal discussions, we're wondering the best approach
>> for
>> >>making a cross-platform API for Qt Quick components. A bit of
>> >>background; currently, we have a common API that we use an
>apichecker
>> >>test to verify conformance - and we're quite OK there. However,
>there
>> >>are a few properties and features that are platform specific - for
>> >>instance 'focusable' on MeeGo's ImplicitSizeItem, needed for some
>> >>specific item interaction features, or Symbian having 'title' in
>it's
>> >>Page.
>> >>
>> >>The convention we have used so far is;
>> >> * '__' is private and should not be used. Best approach is to
>have
>> a
>> >>QtObject {id:property} with properties for hiding private properties
>> >> * '_' is platform specific, and should be used with care..
>> >>
>> >>however, neither of these illustrate which platform you are locking
>> >>yourself to - and it does not allow encapsulating the platform
>> specific
>> >>property for e.g. Symbian.
>> >>
>> >>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?
>> >>
>> >>Others, please pipe up if I forgot some details about our
>discussion.
>> >>
>> >>Cheers,
>> >>Henrik
>>
>> _______________________________________________
>> Qt-components mailing list
>> Qt-components@qt.nokia.com
>> http://lists.qt.nokia.com/mailman/listinfo/qt-components
_______________________________________________
Qt-components mailing list
Qt-components@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-components
