[Kde-pim] configuration in akonadi-next

[Martin Klapetek]

On Tue, Dec 16, 2014 at 8:30 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
>
> Hi,
>
> Working through design concepts and code a bit more with Christian today, I
> started thinking about configuration. There are two parts to this: storage
> and
> user interface.
>
> Currently in Kontact there is a standard UI for configuring each component
> (KMail, KOrganizer, ....). To make this more usable, there is the accounts
> wizard which guides the user through an easy setup of even complex
> configurations.
>
> In future, I would like to see configuration go entirely the way of the
> account setup wizard: the user sets up resources, not individual
> SMTP/POP/etc
> accounts. Yes, the user will be able to set up an SMTP server on its own,
> but
> this will be done as a resource, no different from the process they
> configure
> a Kolab account with.
>
> This will vastly, vastly simplify the user experience IMHO and also put
> configuration right where it belongs: in the resources.
>
> In the Akonadi Next design, clients load Resource plugins to provide a
> facade
> for data in storage that gives the client domain objects. Since the client
> already has this plugin available, it makes sense to also add configuration
> here as well imho.
>
> The end result should be that the account setup wizard disappears in its
> current form with the various setup UIs it currently has going straight
> into
> Resource plugins. Configuration would no longer be "per client" as it
> currently is, which is really a hold-over from the pre-Kontact days, but
> per-
> resource. Configuring your resources would be done from a single, unified
> dialog focused on, well, resources. Clients could filter the shown
> resources
> based on the resource types it is interested in (so KMail wouldn't need to
> show e.g. newsfeeds ;) ...
>

That is moreless how KAccounts works these days.

Basically there is a unified UI in which you can add the various accounts.
Each account than has a list of services which the user can enable/disable.
So eg. you add a Facebook account and then you can enable chat, events,
posts and so on. Then there's a daemon watching for those changes and acting
on them. For example adding an account with Chat service creates an account
in Telepathy. In the Facebook case, it also creates the Akonadi resource
for the
rest and configures it right away via dbus.

Adding new account types is just a matter of providing a provider file,
which can
also have the default settings and a service file, which has the particular
service
you can enable/disable.

The daemon supports plugins so if there's a resource with special need, a
special
plugin can be shipped. KAccounts also support UI plugins so that you can
have
more specialized interfaces for some account types, although it's quite
limited now,
but easily extendable.

KAccounts is also now the only way how to set up Telepathy accounts in KDE.
It would
be really awesome if we could reuse this for Akoandi too, there's really no
need
to have two UIs doing the same thing.


> Then there is the question of how these are stored on disk. IMHO it would
> make
> the most sense to keep each resource's configuration together, even if that
> resource provides email, calendar, notes, contacts, stmp, ...,  as Kolab
> does.
>
> Again, all of this would remain encapsulated in the Resources themselves.
>
> Finally, a way to migrate existing configuration to whatever the new looks
> like will be required.
>
> Ok, so that's my thinking on the matter and the akonadi-next design is well
> suited to pull this off. But perhaps I'm smoking crack here. :)
>
> Input and ideas from the sages of KDE PIM are most welcome.
>
> Also: if someone would like to tackle this part of akonadi-next, I'd be
> happy
> to collaborate/guide/mentor(-if-needed) ... if people think the above is a
> good idea but nobody steps up to take it on as a project, I may end up
> doing a
> requirements document for it and try to recruit a new developer via my blog
> with it.
>

I'm currently the KAccounts developer, I'd be happy to make it work with
new Akonadi.

Cheers
-- 
Martin Klapetek | KDE Developer
_______________________________________________
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/