[Kde-pim] configuration in akonadi-next

[Aaron J. Seigo]

On Wednesday, December 17, 2014 23.56:08 Ingo Klöcker wrote:
> I agree with Laurent that power users need to be able to tweak their
> configuration to their liking. (I also have multiple IMAP accounts, but I
> use a single SMTP account for everything. Unless I want to use a second
> SMTP account. ;-) )

Obviously IMAP is a valid 'account' on its own. SMTP is as well. So there 
shouldn't be problems.

If the question is "how do I set up identities", those (obviously) are also 
part of an "account": they exist in correlation to sending/receiving methods, 
and send/receive accounts can surely have multiple identities (if we wish to 
take it that far). This is one of the things Thunderbird got reasonably 
correct imo.

With identities in hand, the user can then select which identity to use.

With SMTP servers in hand, the user can select which to use for sending.

For the average user all that will be hidden in the default UI just as it is 
now, but again: that's usage, not configuration. I don't know of any use case 
where configuration must be difficult or require one to know how email servers 
work in detail to make work.

... and with competent servers like Kolab (which now supports server-side 
configuration defaults), configuration can be entirely automated once the user 
puts in their email and password.

> * The end user applications (Kontact, what else?, should KMail stay user
> visible or should we hide it from the end user?) provide only end user
> friendly configuration dialogs.

Those are unrelated things imho. If KMail remains visible as a separate 
application, configuration can still be harmonized.

> * The power user configuration is "hidden" in akonadiconsole or some other
> power user tool.

There should be no need for a power user configuration. Just as there is no 
such thing as a unicorn saddle.

> So, all we have to do is: Replace the account configuration dialogs in
> Kontact/KMail (which are essentially the Akonadi resource configuration
> dialogs) with end user friendly configuration dialogs.

Exactly :) Where I may wish to take it even further is that there should be no 
need for non-user-friendly configuration dialogs. Anywhere.

What is the use case?

-- 
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/20141218/ce208952/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/