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

List:       kde-devel
Subject:    Re: KComponentData, KCmdLineArgs and i18n
From:       Parker Coates <parker.coates () gmail ! com>
Date:       2009-02-14 13:34:51
Message-ID: 85d347350902140534h6bfe85bj1721e7d5f119ffda () mail ! gmail ! com
[Download RAW message or body]

On Sat, Feb 14, 2009 at 03:03, Andreas Pakulat wrote:
> On 13.02.09 22:25:06, Parker Coates wrote:
>> On Fri, Feb 13, 2009 at 22:17, Parker Coates wrote:
>> > Hello folks,
>> >
>> > I recently created a patch for KPat to add a new command line switch.
>> > [1] The tricky thing is that in order to make the change i18n
>> > friendly, I needed to use some translated strings to created the
>> > "--help" text. (KLocalizedString wouldn't cut it in this case.) This
>> > lead to trouble, because i18n() can only be called after the
>> > KApplication has been created, but KCmdLineArgs must be set up before
>> > the KApplication. It seemed I was stuck.
>> >
>> > After explaining my predicament on #kde-i18n, Chusslove suggested
>> > creating a temporary KComponentData, after which I could use i18n().
>> > This resulted in a main.cpp laid our like this:
>>
>> Sorry, sent prematurely due to an accidental keyboard shortcut. Well,
>> that's embarrassing. Continuing on...
>>
>> This resulted in a main.cpp laid our like this:
>>
>> - Create KAboutData
>> - Create a temporary KComponentData
>> - Do the slightly tricky translation stuff
>> - Setup KCmdLineArgs
>> - Create KApplication
>> - Continue on normally
>>
>> This seems to work perfectly, but it seems a bit like black magic. Is
>> there any harm in creating a KComponentData just to get to access i18n
>> earlier?
>
> I don't think so, you can actually create any number of component
> data's, as long as you don't set one as the main component it doesn't
> really matter (except for translation stuff and kcm's).

Okay, that's good to know. It still seems wasteful though, as creating
a KComponent data doesn't seem to cheap as it involves parsing
configuration files and looking for plugins. Ideally, I was hoping for
a KApplication constructor that would accept an existing
KComponentData, instead of creating its own and thought I had found
one until I noticed is was protected for use by subclasses only. Of
course this stuff is way over my head, so if at any point I'm talking
foolishly, let me know.

>> Is this going to blow up on me in some not yet seen
>> situation? Is there a better and cleaner way to do this?
>
> I wonder though why you can't use ki18n() to translate the game-name or
> why you're translating at all.

Sorry, I guess the link to ReviewBoard [1] got lost at the bottom of
the first, broken email. The short explanation is that I need to
compile a list of translated game names to insert into the description
of the new command line option. Of course, if anyone can see an
alternate means of providing similar functionality, I'm all ears.

Parker

[1] http://reviewboard.kde.org/r/50/
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]