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

List:       kfm-devel
Subject:    Re: translations and KParts::Plugin
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2001-10-29 17:19:50
[Download RAW message or body]

On Mon, Oct 29, 2001 at 05:55:57PM +0100, David Faure wrote:
> > 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 !?

Looks like the kdelibs code has enough null pointer checks to make
it work ;-)
(but I can't think of anything that makes the existance of an instance 
object absolutely mandatory, code wise, for a plugin -- of course design 
wise I agree it makes sense to let every component have its instance)

> > 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 ?

Yes, it knows about it. But it can't call setInstance because setInstance
is protected ;-} , which in general makes sense to me as usually
noone from outside should change a components instance (except that
the current code in plugin.cpp that sets the instance to the part's
instance! grmbl.. (see mail on kde-devel) )

> > 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 ?

That's what I meant with 'breaks with the situation...' :) . It'd
require people to specify an instance name although it'd be unused
because they use their aboutData object (which already contains the
instance name) .

> > 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.

Ok, cool :)

> > 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.

Excellent.

Simon

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