[Development] Removing QContactThumbnail class from QtContacts API

[Mathias Hasselmann]

Just store the QByteArray and mention QImage::loadFromData() in API
docs. No need to over-complicate things like by using data URIs.

Alternatively let's do what the GTK folks did years ago with gdk-pixbuf:
Move image loading and saving into a self-contained module.

Ciao,
Mathias

Am Dienstag, den 31.01.2012, 11:23 +0000 schrieb
shane.kearns at accenture.com:
> 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 Ofcristiano.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 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 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 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
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Mathias Hasselmann <mathias at openismus.com>
http://openismus.com/