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

[laurent Montel]

Le dimanche 4 août 2013 10:57:16 Kevin Krammer a écrit :
> 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.

It’s better to have separate docbook for me, as perhaps in the future other 
pim apps will use it.

> > 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.

Heu... No :)
Kmailcvt can import mail from outlook/pmail etc. From other computer from 
archive etc.
Importwizard can import data/settings/calendar/contact etc. From local 
computer (if we use it directly in computer).
So importwizard will never replace kmailcvt (it uses shared code but never 
replace it)

> > 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.

No it’s independant program. It’s never launch in kmail.

> 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

-- 
Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090