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
