[Kde-pim] [RFC] Contact specific Akonadi API
Tobias Koenig
tokoe at kde.org
Fri Aug 7 17:03:29 BST 2009
Hej,
after renaming KContactManager to KAddressBook I disabled several
functionality in KOrganizer, KMail and some other PIM components
which made use of DBus interfaces of the old KAddressBook to add,
edit or just display contacts. With the shift to Akonadi we go away
from an application based system to a components/service based system.
So applications shouldn't start other applications and control them
via DBus to execute some task, instead code to fulfil the common tasks
should be put into a library and both, the 'main' application
(e.g. KMail for email) and other applications (e.g. a biff plasmoid)
shall make use of it.
So functionality from the old KAddressBook interface should be moved
to a library as well and be usable by any other KDE application.
The question is now:
What tasks are common enough to be worth putting them into the library?
The tasks I came up for contacts are the following:
* tasks without gui involvement
- create a new contact in a predefined address book
- modify a contact with a given uid
- delete a contact with a given uid
- search a contact that matches a given pattern
* tasks with gui involvement
- create a new contact and allow the user to select the target address book
- modify a contact with a given uid by show up a dialog, where the user can edit the contact
- view a contact by show up a dialog
(same functions for contact groups as well)
So my idea was to provide a job based API like in kdepimlibs/akonadi/ that, for the non-gui
tasks, just wrapps the ItemXYZJob classes by converting the payload from/to KABC::Addressee
objects internally. That doesn't add any real value but is a nice convenience layer IMHO.
Depending on the ctor signature, the jobs could behave differently:
ContactCreateJob( const KABC::Addressee &contact, const Akonadi::Collection &collection );
would add the contact directly to the given collection, while
ContactCreateJob( const KABC::Addressee &contact, QWidget *parent = 0 );
would present a collection selection dialog to the user where he can select the collection
himself.
The job based API would allow easy usage in asynchronous and synchronous code by using start()
or exec().
What are your thoughts?
Ciao,
Tobias
--
Separate politics from religion and economy!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090807/5f103fd2/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
More information about the kde-pim
mailing list