[kde-doc-english] [Kde-pim] New docbooks in kdepim

[Kevin Krammer]

Hi Burkhard,

thank you for bringing this up for discussion.
Also thanks a lot to Scarlett for putting all that work into the PIM docs 
making this discussion viable in the first place :)

On Friday, 2013-08-02, Burkhard Lück wrote:
> Hallo,
> 
> there are some new docbooks in kdepim with not much content, but content
> for that topic in kmail handbook:
> 
> 1)
> akonadi_archivemail_agent
> akonadi_folderarchive_agent
> akonadi_sendlater_agent
> No standalone apps, afaik only useful for KMail, actions + settings
> launched via KMail. and documented in KMail Handbook

Given that they are Akonadi agents they are almost certainly stand-alone at 
least in the sense of not belonging directly to any end user applications.
I.e. I would expect them to work independent of KMail.

> Suggestion: Thans to Scarlett's work, these issues are better documented in
> the KMail handbook, so remove these docbooks, adjust X-DocPath in their
> desktop files and improve the documentation for these apps as part of KMail
> Handbook.
> 
> 2)
> kmailcvt
> importwizard
> Standalone apps, but can also be launched via KMail, afaik only useful for
> KMail, and documented in KMail Handbook (importwizard up to date, kmailcvt
> not up to date so far)

I think the general idea of those two is that importwizard succeeds kmailcvt.

> Suggestion: remove these docbooks, adjust X-DocPath in their desktop files
> and improve the documentation for these apps as part of KMail Handbook.
> 
> 3)
> headerthemeeditor
> pimsettingexporter
> 
> Suggestion: Update/improve these infos in separate docbook, because these
> apps can not be launched via KMail and there is no content in the KMail
> handbook. Add Info/links to these handbooks to the KMail docbook.

Hmm. I would have expected that the theme editor is KMail specific and could 
be launched throught the program's configuration interface.
Not sure about the other, sounds a bit like it should be in category (2).

Hmm, I am a bit torn regarding the suggestions. I think they make sense given 
the currently available PIM applications and, well, coming from someone with 
waaaay more experience in documentation matters than me :)

However, one of the possibilities opened by moving to Akonadi as the data 
access layer is to allow different end user programs to operate on the same 
data.
In the case of mail that would mean allowing other interfaces than KMail, e.g. 
something very simple for users with low end mail usage patterns.

Some of the features listed above in (1) and (2) would then be applicable to 
more of those interfaces.
Their respective docs would probably want to refer to this shared 
functionality in some way that doesn't require duplication.

Of course mostly hypothetical right now, so I just wanted to bring that up in 
case some of the suggestions layed out by Burkhard would make this more 
difficult in the future when it might be needed.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-doc-english/attachments/20130804/66d89bbe/attachment.sig>