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 [email protected]: > 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]] > On Behalf [email protected] > Sent: Tuesday, January 31, 2012 05:45 > To: [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 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Mathias Hasselmann <[email protected]> http://openismus.com/ _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
