[Qt-components] QML component APIs and techniques

Martin Jones martin.jones at jollamobile.com
Fri Jan 11 01:24:07 CET 2013


On 11/01/13 10:02, Alan Alpert wrote:
> On Thu, Jan 10, 2013 at 3:22 PM, Martin Jones
> <martin.jones at qinetic.com.au> wrote:
>> On Fri, Jan 11, 2013 at 2:48 AM, Bache-Wiig Jens <Jens.Bache-Wiig at digia.com>
>> wrote:
>>>
>>> Did anyone look into standard icon naming? (which was oddly one of the
>>> bigger problems when co-ordinating meego vs symbian API).
>>
>>
>> I suppose that typically these are exposed via an imageprovider.  If it
>> really is too hard to name them all identically across all platforms then It
>> may be easiest to simply define a set with a unique provider name, e.g.,
>> "image://openicon/up_arrow.png", and allow each platform to provide an
>> "openicon" imageprovider that maps to their own icons.
>
> Note that there's a problem with imageproviders - they're tied into
> the pixmap cache and so can only be used by QtQuick. You can't even
> write a proper custom QQuickItem which accepts imageprovider URLs.

Maybe its time for QtQuick to polish up QQuickPixmap and make it public.

> It
> certainly doesn't work with non-QtQuick component sets, like Cascades
> (I almost suggested image providers to them, but then found out it
> can't be done right now).
>
> That doesn't mean the QtQuick component sets can't use image
> providers. But they should be aware of the limitations and realize
> that it needs some work in the long run. Image providers are the right
> answer conceptually, but we don't have a good implementation right
> now.

Qml has QQmlImageProviderBase which QtQuick subclasses to provide 
QQuickImageProvider, so the QQmlEngine API is useful.  Any other element 
library could provide similar functionality in their Image element - it 
just needs to do something sensible with "image://".

But, we're getting off topic.

Martin.




More information about the Qt-components mailing list