[Kde-pim] configuration in akonadi-next

Aaron J. Seigo aseigo at kde.org
Tue Dec 16 21:52:28 GMT 2014


On Tuesday, December 16, 2014 21.07:26 Michael Bohlender wrote:
> I agree with the per account (resource) configuration UI and I want to work
> on it.

Awesome :)

So some implementation details .. in the akonadinext repo there is 
common/resource.h .. it contains a class called ResourceFactory which is the 
class which is loaded from a resource plugin. It creates Resource objects, 
registers the data facades and should provide some API for handling 
configuration of an account.

Given the name of a configured account, it should be able to provide a UI with 
the values loaded; without a name it should provide a "blank" UI. It would be 
very special if the UI was done with QML and was able to adapt in future to 
the device form factor ... sounds like a job for a KPackage of QML :)

Configuration data should probably end up in a standard location and use a 
standard format (QSettings?). The config UI needs to write them, and the 
Resource class needs to be able to read them. In turn that implies that the 
Resource constructor will need to take a name with which to load its UI.

Summary: ResourceFactory is where most of the magic should happen, and both 
ResourceFactory::createResource() and Resource::Resource() need to accept a 
name for configuration purposes.

> How does this relate to KAccounts in your mind?

It would be up to the resource. For local resources which have no account 
(e.g. a local ical file) it makes no sense to use KAccounts. For remote 
resources requiring authentication, KAccounts makes lots of sense.

For those resources, in a "perfect world" we'd use KAccounts to hold the 
configuration data, do authentication (keeping credentials away from clients) 
and hopefully also use to host the config UI. I haven't looked at the state of 
KAccount recently (infrastructure or GUI) though I do know that the 
libaccounts it wraps is solid.

> This also looks like a great GSoC project for next year. Though it might
> not fit our schedule.

Yes, it would make a perfect GSoC project. Wish we could cheat with the time 
:)

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141216/b6ad5644/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