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
