[Kde-pim] configuration in akonadi-next

[Daniel Vrátil]

On Tuesday, December 16, 2014 10:52:28 PM Aaron J. Seigo wrote:
> 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, 

There are usecases when sysadmins want to pre-configure users' Akonadi on 
first login to have their email, corporate calendar etc. configured. This 
would be difficult with KAccounts (IMO). I'm much more in favor of following 
the current approach of each resource instance having it's own config file in 
~/.config/akonadi (wouldlaos  make migration much easier for us). Just my 
$0.02.

Dan

> 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
> :)

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
Software Engineer - KDE Desktop Team, Red Hat Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141218/f331e7f9/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/