[PATCH] RFC: Changing the language of individual KDE programs

[Aaron J. Seigo]

On Monday 21 May 2007, David Jarvie wrote:
> On Sunday 20 May 2007 20:49:01 Aaron J. Seigo wrote:
> > On Saturday 19 May 2007, David Jarvie wrote:
> > > On Tuesday 15 May 2007 09:05:29 Thomas Diehl wrote:
> > > > I just received the following update on this more than 6 year old
> > > > wishlist item with now 328 votes
> > > > (http://bugs.kde.org/show_bug.cgi?id=24348). If this is true we won't
> > > > see the requested feature in KDE 4.0 either:
> > > >
> > > > Well, the bug was essentially closed by Krzysztof Lichota (SVN commit
> > > > 644712
> > > > http://websvn.kde.org/branches/KDE/3.5/kdelibs/?pathrev=647712) but
> > > > his contribution was reverted for no new feature is allowed to the
> > > > stable branch before it is implemented in trunk... and there seems to
> > > > be nobody who'd will to be that... (see also some discussion in BR
> > > > 103467 http://bugs.kde.org/show_bug.cgi?id=103467 )
> > >
> > > Attached is a patch to implement this function in trunk. Also required
> > > is to move klanguagebutton.{h,cpp} back from
> > > kdebase/runtime/kcontrol/locale/ into kdelibs/kdeui/widgets/.
> >
> > if that is going to happen, can we please have someone look at the API of
> > that class. it's particularly horrible. there is nothing language
> > specific in that class at all; it essentially a button that pops up a
> > drop down with columnar data. the API seems to say otherwise in places,
> > but it's really not true. it needs to be generalized to avoid being the
> > red headed step child of kde libs.
>
> I assume you're talking about KLanguageButton class. Are you complaining
> about the fact that it looks more like some sort of general combo box class
> rather than one designed to contain language name strings? In fact, most of

well, it -is- a general combo box class with a few language specific bits 
tacked on that really have little to nothing to do with what the class 
actually does. in fact, the insertLanguage method isn't overly language 
specific either from what i can see.

> the methods actually are language specific, but this fact is hidden by the
> apidox comments which don't make clear that the 'id' parameter which many
> of them take is actually a language code. 

well, it's only a language code because a language code is provided by the 
apps using it. looking at the actual implementation, there's no reason one 
couldn't use just about anything there.

can you point me to the language specific code?

> If the apidox comments are 
> improved, do you have any other objection to this class being moved to
> kdelibs?

well, yes. it's not the documentation, it's the fact that it's not language 
specific, though it's billed as being language specific. the insertLanguage 
method is completely superfluous as it doesn't load an icon even (that is 
commented out as being wrong).

imho, what really ought to happen is one of two things:

- the class is actually languageified and made into a truly language specific 
widget
- the class is generified, including its name and documentation, and used for 
language use cases as one of its possible uses.

i'd very much like to see the latter happen as other apps have need for such 
multi-column popups attached to a button.

further small details include cleaning up the class with things like moving 
the private data members into the dptr, but that holds either way.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070521/eb493d49/attachment.sig>