[Kde-pim] Killing kpimutils framework

[Ingo Klöcker]

On Monday 29 September 2014 13:42:17 Daniel Vratil wrote:
> Hi,
> 
> during Akademy we came to conclusion that we want to kill the
> kpimutils "framework" in kdepimlibs, before we start splitting the
> frameworks into repositories. Right now it's an dumping ground for
> random classes, so we want to get rid of it of course :)
> 
> I tried to split it and move the classes to other existing frameworks,
> but run into problems with dependencies. Let me know what do you
> think about this, or if you have better ideas how to split the
> framework :)
> 
> Email - should be renamed to EmailAddress and could be moved to
> KCodecs - it's a generic email address parser/validation tool that
> could be useful in many cases outside PIM. The reason for moving it
> to KCodecs instead of KCoreAddons is that it depends on
> KMime::{encode,decode}RFC2047String() methods and there's already
> decodeRFC2047String() available in KCodecs, so if we add
> encodeRFC2047String() to KCodecs (which IMO makes sense), we could
> move it there. Maybe we could move the "more robust" encode/decode
> implementation from KMime into KCodecs too when at it.

Sounds like a good plan.


> EmailValidator - a simple QValidator subclass that uses the
> above-mentioned Email class to validate email addresses. Because of
> that, it would have to go to KCodecs too, and KCodecs would have to
> depend on QtGui - if that's possible/reasonable.

Hmm. During Akademy I have prepared a patch (and then left it rot on my 
laptop) where I made EmailValidator self-contained. EmailValidator uses 
one function of email.cpp (validateSimpleEmailAddress, or similar) which 
does not depend on anything except Qt. In my patch I moved 
validateSimpleEmailAddress() to EmailValidator to make it self-
contained. Then EmailValidator could be moved to any framework. I will 
submit a review request.


> KFileIO - methods for reading and writing files that will do all
> possible and impossible error handling for you. Not sure if it makes
> sense to have this around - error messages from QFile should be
> already localized from lib. Could either be removed, or could be
> moved to KCoreAddons - I'd just port it away from KMessageBox and let
> applications to show the error on their own.

IIRC this was invented for KMail's index files for which very thorough 
error handling was essential. I think it can go the same way as KMail's 
index files, i.e. to /dev/null.


> LinkLocator - probably another adept for KCodecs or KCoreAddons -
> given a text, it can extract all email addresses from it (not using
> the Email class above), convert text into HTML (stuff like */_ markup
> and links are converted into HTML entities)  - it also supports
> converting smileys into inline images using KEmoticons - which again
> makes it problematic to put it into a Tier 1 framework - we could
> only remove the smileys support to get rid of that dependency,
> otherwise I don't know what other framework would be a good home for
> this class.

Hmm. This class only makes sense in combination with a message viewer.

Outside of kdepim* it seems to be used only in two places (of which one 
seems to be dead):
* /extragear/libs/libkfbapi/libkfbapi/eventinfo.cpp

I didn't have a look, so I have no idea what to do here and which of its 
many features are actually used.


* /playground/base/plasma-lionmail/*

I think lionmail is dead. The last real activity seems to have happened 
3.5 years ago.
https://projects.kde.org/projects/playground/base/plasma-lionmail/repository/revisions/master/revisions?per_page=100


>From your description the LinkLocator class appears to do at least four 
different things (linkify email addresses, linkify URLs, do */_ markup, 
handle emoticons). In my book this means that this class does at least 
three things too much. It should probably be split into 4 (or more) 
separate classes. Those could then be moved to appropriate places, e.g. 
the emoticon handling clearly seems to belong into KEmoticons.


Regards,
Ingo
-------------- 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/20140929/61f3fc43/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/