Hi Shane and others, While I see your point about embedded PHOTO details of vcards, at the same time I do not feel it's a good idea to keep the Thumbnail detail as it is, since the actual optimal format for that image would be very much dependent on the specific platform / configuration that the clients will be running on. In other words, just embedding the thumbnails there as Qimages it's something that looks nice for examples and demos, but not really usable or efficient for real work applications. The vcard related issues should be addressed then in the import phase, where the importing / exporting functionality should most probably store that embedded image into the platform by using the platform-specific image management / thumbnail creation framework(s), which in turn is a feature that IMHO goes beyond the scope of the QTPIM module and its APIs. Removing QContactThumbnail and leaving the AvatarURL will still allow managing this kind of contact data, and delegating the actual creation of image objects from the URL to clients.
One improvement might be to add a convenience contactlistmodel to our API, which would include anyway a default imageprovider, allowing clients to create lists of contacts with images. Ideally, such an image provider should get the images from a proper thumbnail framework based on some extra properties of such a model to specify also resolution / size of the desired images. Hope this helps to bring the discussion to next steps, which include at least: * answering the question about removing or not removing the QContactThumbnail detail * Getting more information about how to access proper thumbnail via existing Qt5 APIs * Deciding how to handle images embedded in vcards Br, -Cristiano ________________________________________ Cristiano di Flora, PhD SW Architect / Technical lead, Nokia MP - Qt Software development Visiokatu 3 33720, Tampere (FINLAND) Mobile: +358 (0)50 4872919 ________________________________________ From: "ext [email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Tue, 31 Jan 2012 11:23:22 +0000 To: Cristiano di Flora <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>> Subject: RE: Removing QContactThumbnail class from QtContacts API 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: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of [email protected]<mailto:[email protected]> Sent: Tuesday, January 31, 2012 05:45 To: [email protected]<mailto:[email protected]> 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
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
