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

List:       kfm-devel
Subject:    Re: translations and KParts::Plugin
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-10-29 16:55:57
[Download RAW message or body]

On Lundi 29 Octobre 2001 17:10, Simon Hausmann wrote:
> Having the insertCatalogue in setInstance means that
> insertCatalogue is called each time a new part/plugin is created,
> while actually it's only necessary once, when the factory is
> created. 

Yes, but IIRC it was said that this doesn't matter much,
KLocale does a quick lookup and sees the catalogue is already
inserted (didn't check, I hope this is true ;)

> In addition the whole automatic call-insertCatalogue-trick
> doesn't help anyhting if people forget the setInstance call (and
> none of the konq plugins in kdenonbeta called setInstance ;-) .

Ah. Shouldn't it be mandatory to call setInstance ?
I'm surprised that a plugin can work with no instance being set !?

> Hmm... why can't we call insertCatalogue in the factory? Ahh! Then
> it's too late (the constructor finished with its i18n() calls) . Hm.

But why not call it before creating the object ? Ah, we don't know the
name yet, hehe. Well, that's why we do it in setInstance: it's
"as soon as we know the name". Can't make it sooner ;)

Ok, so setInstance should be called, and always first.
Feel free to copy the docu from Part::setInstance, when doing the
same in Plugin ;)

   * Call this *first* in the inherited class constructor,
   * because it loads the i18n catalogues.
:)

> There's one thing we can do though, in KGF:
> KGF knows about the instance, in fact it controls its lifetime. Most
> important, it knows the instance name, what we pass to
> insertCatalogue. However we can't call insertCatalogue from the
> factory ctor because that'd require us to create the KInstance from
> the KGF ctor, which we can't do because then the whole point about
> createInstance being virtual becomes void (at that time the vtbl for
> a derived class re-implementing that isn't updated, yet) . So we
> neeed to do that at some point later. Ah, let's just do it only once 
> the first time create() gets called. That should fix all cases:
> 
> People using setInstance will be happy (and insertCatalogue will be
> called twice, but who cares. KLocale should be made clever enough
> for that ;) . 
Hehe, this was your first concern in this mail ;)

> People forgetting this setInstance magic will be
> happy, too, because insertCatalog will be called by the template,
> right at the beginning of create() .

Hmm, now I'm confused. If KGF knows the instance, why doesn't
it call setInstance itself ? Is that possible ?

> What's left now is that people could forget passing the instance
> name to the KGF constructor (the signature is const char
> *instanceName = 0) . But those we just can't help ;) , because it
> breaks with the situation where people want to provide aboutData and
> therefore aren't interested in passing an instance name to KGF.

Such people should be shot in the head ;-)
Although, maybe we can prevent this from happening by removing the = 0 ;)
Is that doable ?

> Oh, to come back to your original question ;)
;)
> Yes, if people don't kill me for making koffice depend on a recent kdelibs then I
> could go through the koffice filters and make them use KGF. 
I just made KOffice use KDataTool, so this is done anyway.

> Should simplify the filter code and fix i18n issues, if there are any ;)
> OTOH that proposed change means that insertCatalogue will be called
> even for components that do not contain translations (do filters
> usually contain translatable strings?) . Much overhead with
> unnecessary insertCat calls?

Most filters have translatable strings (for error messages at least,
for complete dialogs for some). Those which don't... well, I don't think
this is a big overhead.

David.

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