[Development] Removing QContactThumbnail class from QtContacts API

shane.kearns at accenture.com shane.kearns at accenture.com
Tue Jan 31 12:23:22 CET 2012


Hi Cristiano,

Would you be able to use a data url, for example to handle vCard PHOTO fields that are embedded rather than linked?
They are rather inefficient though.

An end-user feature you may be losing is the ability to snap a photo of somebody when taking their phone number and have that show up in the address book.
While you could store some kind of link to the photo album, this isn't likely to be a simple file: url.


From: development-bounces+shane.kearns=accenture.com at qt-project.org [mailto:development-bounces+shane.kearns=accenture.com at qt-project.org] On Behalf Of cristiano.di-flora at nokia.com
Sent: Tuesday, January 31, 2012 05:45
To: development at qt-project.org
Subject: [Development] Removing QContactThumbnail class from QtContacts API

Hi,

>From the old mobility times there has always been confusion in Contacts API between the QContactThumbnail and QContactAvatar.
An excerpt from our docs:
"
The content of the thumbnail detail is static once set. That is, in order to change the thumbnail of a particular contact, the user must modify the detail and update the contact. This is in contrast to the QContactAvatar<http://doc.qt.nokia.com/qtmobility-1.2/qcontactavatar.html> detail, which contains URLs to resources; the actual content of the resource might be changed dynamically by person, group or organization for which the QContact<http://doc.qt.nokia.com/qtmobility-1.2/qcontact.html> is a digital representation. That is, the content of a QContactThumbnail detail is set by the user who has created the contact, but the content of a resource identified by a URL specified in a QContactAvatar<http://doc.qt.nokia.com/qtmobility-1.2/qcontactavatar.html> detail is set by whoever owns the resource which the URL identifies.
"

Now, the reality is that returning a Qimage from QContactAvatar class is not a great idea, since not all the back-ends support real thumbnails, and hence this approach can lead to inefficiency, because:

  1.  The specific image format for a thumbnail depends on several factors which are out of control of the Contacts middleware API
  2.  In back-ends where storing directly some binary blobs might not be possible or desirable, we end-up storing anyway the image to file system
We are now thinking of removing the detail from the API, and give more "power" to the URL based approach adopted in QContactAvatar.
What do the others think? Any objections to killing the QContactThumbnail class in one shot?
Will we be able to use only one single detail type (e.g. QContactAvatar) based on URL and not Qimage?


Ciao!
-Cristiano

________________________________________
Cristiano di Flora, PhD

SW Architect / Technical lead,

MP - Qt Software development

Visiokatu 3
33720, Tampere (FINLAND)

________________________________________

________________________________
Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120131/d3f429f4/attachment.html>


More information about the Development mailing list