Emoticonslib moved to kdereview

Carlo brandon.ml at gmail.com
Wed May 14 00:00:55 BST 2008


On Wed, May 14, 2008 at 12:08 AM, Olivier Goffart <ogoffart at kde.org> wrote:
> Le jeudi 1 mai 2008, Carlo a écrit :
>
>
> > Hi,
>  > I've moved emoticonslib from playground to kdereview, it's a simple
>  > library that can be used to parse emoticons in a text, choose and
>  > modify themes etc..
>  > Since there are many kind of emoticons theme it uses plugin to manage
>  > each type of file
>  >
>  > I've made this library because every application have written their
>  > own implementation to handle emoticons and there isn't a global config
>  > file like for icons or style, if you have any feature requests please
>  > ask before the feature freeze
>
>  Hi.
>  Pushing emoticons libs into kdelibs has always been one of my wish.
>
>  Here is my review:
>
>  - The code contains lots of code from Kopete, please keep the copyright
>  header, (and mention where the code come from so it can be looked in the svn
>  history)
Ok I'll add that
>  - Lots of the internals structure should be hidden. For exemple, all thoses
>  protected: should be private:  And some data structure (such as QMap) should
>  not be exposed in public API.
I've changed protected to private in kemoticonstheme.h, I forgot to do
that because kemoticonstheme and kemoticonsprovider was one class
before and I've used a shared d pointer
>  - Consider using QHash instead of QMap
>
>  - The only purpose of the KEmoticons object is the signal that could be moved
>  to KGlobalSettings or something similair.  All the other method are static,
>  and could be placed as static members in the KEmoticonTheme.
it's not just a signal, there are other things like a cache for the
emoticons theme already loaded
>  - the Token struct should just contains the token type, the text, and the path
>  to the emoticon.  'emoticonPath' is maybe a better name.
>  The HTML should not be part of the token itself. because if html is used, then
>  the parse function can be used.
I've copied that straight from kopete :P
>  - Performence!!!  The original Kopete code did maintain an index of emoticons
>  by the first character of it.   Looking thought each emoticon on each
>  character of the message doesn't give acceptable performences. (noticable
>  when you have a big emoticon set, and you have a big text to parse (eg.
>  browsing the history)
I tought that this wasn't really useful, I'll readd it
>  - SkipHTML is meant only for tokenize function. It means that the input string
>  is in Html.  The parseEmoticon function should only accept html (and it
>  should be documented), and should ensure that skipHTML flag is in use.
I don't understand this problem
>  - What is the use case of the exclude parameter?
for example in linklocator in kdepimlibs that's used by kmail, they
want to exclude "(c)" "(C)" and some other strings
>  - The Kopete code had some unit tests for emoticon parsing.  It is very
>  important that this code is tested. Maybe you could use QTestLib for that.
>  Also check that uses case that are in the kopete test still pass. I fear that
>  some stuff may be broken (choose the largest emoticon, ...)
ok I'll copy them
>  - In which kde library do you plan to move those class?
>  It make few sens to have them as a stand alone library? (Or does it?)
>  It can't be moved into kdeui because it uses kio.
>  Maybe in kio or kdeutils?
inside kdelibs as standalone like knewstuff/phonon etc.. I can't think
of any other solutions
>  --
>  Olivier
>




More information about the kde-core-devel mailing list