[Kde-pim] Killing kpimutils framework

[Daniel Vratil]

On Monday 29 of September 2014 21:20:20 Ingo Klöcker wrote:
> 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 :)
> > 
> 
> > 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.

Awesome! In that case KGuiAddons is probably the right place?

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

Hmm interesting :-) It got spread to couple more places in KMail, KNode and 
Akregator over the time, but everything can probably be replaced by simpler if 
(!QFile::open()) { error! }. 

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

Well, the class makes sense in other cases too, like for instance in the 
LibKFBAPI where it makes links clickable and replaces smileys in Facebook 
Events description. The linkification and highlighting IMO is very useful 
everywhere where you are dealing with larger blocks of plain text that comes 
from "external sources" (event description, contact details, emails of course, 
etc.)

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

linkify emails + linkify URLs is pretty much the same thing. Converting */_ 
markup to <b><i><u> is another thing - but both have the same result: HTML 
code. So I don't think it's *that much* unrelated. Also it would mean that 
getting a formatted HTML code from plain text would require running it through 
4 different classes - which is not good both API- and performance-wise.

If we instead rename the class to TextToHTMLConverter, we would have a class 
that takes text and spits out HTML-formatted text with emails, URL linkified 
and converted highlighting - each configurable through flags (that's what 
LinkLocator already does).

> Those could then be moved to appropriate places, e.g.
> the emoticon handling clearly seems to belong into KEmoticons.

Having similar method in in KEmoticons to only handle emoticons makes IMO 
sense. Or it could just internally call the above method + additionally 
process the smileys (KEmoticons::convertToHTML()).



> Regards,
> Ingo

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140930/0d8d8a63/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/