[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: A KSelectAction dedicated to QTextCodec selection ?
From:       "Michel Hermier" <michel.hermier () gmail ! com>
Date:       2006-10-17 11:38:32
Message-ID: 2e631f490610170438qdcaff83w28487abeb76e7a9a () mail ! gmail ! com
[Download RAW message or body]

2006/10/17, David Faure <faure@kde.org>:
> On Tuesday 26 September 2006 00:25, Michel Hermier wrote:
> > Hi,
> > 
> > I just commited the code available here:
> > http://websvn.kde.org/trunk/KDE/kdenetwork/kopete/protocols/irc/ui/kcodecaction.cpp?rev=588417&view=auto
> >  http://websvn.kde.org/trunk/KDE/kdenetwork/kopete/protocols/irc/ui/kcodecaction.h?rev=588417&view=auto
> > 
> 
> Shouldn't the MIB stuff be removed? AFAIK it's gone from Qt4, it all works with \
> names now.

No it's there, and it seems way much more *stable* then the names in facts.

> Hmm. Honestly I don't see the value that this class has. It looks like it doesn't \
> do much, a KSelectAction initialized with availableEncodingNames() and a \
> codecForName() call in the application would do the same. I'm all for modularity of \
> course so writing a KCodecAction for it isn't a bad idea per se, but as one more \
> class to maintain in kdelibs I don't see the point of a class that has basically 3 \
> lines of logic (the rest is straightforward derived-class stuff).

Like all the subclass of KSelectAction, they all have small codes.
For now it's a small piece of code, but with time it can(should) grow
to have a configuration dialog to only show some off them.

> I guess it boils down to how many apps would use it, and I'm not sure the count \
> goes up to 5.

I know at least, konqueror, konsole, near all the kopete plugin (if
they some don't use it they really should in fact),
Not sur of them but I think should also use it, konversation, ksirc,
maybe koffice to import some files, maybe also ktorrent to select the
correct encoding of it's content ...
And maybe some that I don't think about.

Michel


[prev in list] [next in list] [prev in thread] [next in thread]