QContactType::TypeGroup is meant to represent a group of entities with shared contact details (eg, a local football club might have a mailing-list email address, a clubhouse phone number, etc). Individual contacts can have membership in groups (so various friends can be members of the football club group). I don't think that overloading TypeGroup with aggregation semantics is a great idea, personally.
We had a discussion a while ago (I cannot remember where, and a quick grep through QTBUG-31824 failed me) about adding a new QContactType::TypeFacet (to match stdlib nomenclature) or QContactType::TypeConstituent where contacts of those types represent "service- or sync-endpoint-specific contact instances which are aggregated into a 'full' contact". The "full" contact would be a QContactType::TypeContact contact, and it would have QContactRelationship::Aggregates relationships with the Facet/Constituent contacts. Then it comes back to what Konstantin suggests: each Facet/Constituent belongs to the particular addressbook (eg, the OwnCloud addressbook, the Fruux addressbook etc) and the Aggregate/Full contact belongs to the FullContacts addressbook. If the user edits the contact on the device, you generate a "local" Facet/Constituent which is also linked into the aggregate. The aggregate can be regenerated on every write, or on every read, depending on the desired performance characteristics for the device / which trade-offs are preferred. Note that this is the way we do it in nemomobile's qtcontacts-sqlite engine, however we use rather artificial separations based on synctarget (string) filtering, rather than Addressbook collections (we'd definitely prefer Addressbook collections, going forward). Cheers, Chris. www.qinetic.com.au - Qt And QML User Experience Specialists On Tue, Jan 20, 2015 at 7:23 AM, Renato Araujo <rena...@gmail.com> wrote: > For what I understand every detail already have such functionality > [QContact.detailUri] with this field you can specify from which contact > this detail belongs, based on QContact.Guid; > > Is correct to say that a contact which the type is "TypeGroup" is a meta > contact with information from different contacts (A merged contact)? > > > > > > > > > Renato Araujo Oliveira Filho > > On Mon, Jan 19, 2015 at 6:12 PM, Konstantin Ritt <ritt...@gmail.com> > wrote: > >> IMO, such a merged contact should belong to a special "address book" - >> one that aggregates contacts and knows which field/detail came from this or >> that real contact. >> >> Regards, >> Konstantin >> >> 2015-01-20 0:27 GMT+04:00 Renato Araujo <rena...@gmail.com>: >> >>> Hey guys, >>> >>> I started to implement the class QContactCollection based on >>> QOrganizeCollection[1]. Until now I just copy the code from QOrganizer >>> module and renamed some classes. >>> >>> The idea of QContactCollection is to represent an "address-book". And >>> with this we can create/remove/modify collection and query contacts based >>> on the collection id. >>> >>> This looks great, but I have one concern about that. How to represent >>> contacts that are present in more than one "Address book" (merged >>> contacts)? In this case the contact can have more than one collection. >>> >>> Do you have any idea how to solve that? >>> >>> Should we use a different approach? >>> >>> What about use QContactCollectionId as a derived class from >>> QContactDetails? >>> >>> >>> [1] https://codereview.qt-project.org/#/c/104026/ >>> >>> >>> Thanks >>> Renato Araujo Oliveira Filho >>> >>> _______________________________________________ >>> Development mailing list >>> Development@qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> >> > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
