On 22 Feb, Sven Neumann wrote:

> IMHO adding lines into the pluginrc is much easier than to add
> code to parse another file.

 Well, my code is there, now you'll have the chance to prove that
 this assertion is true, I don't think so BTW after thouroughly 
 studying the code.

> Which just means adding another token to the parser code. You can't do
> much wrong here.

 The pluginrc Parser is something I touched once and then never again.
 The parser GIMP relies on is rather complicated.Passing arguments needs
 the introduction of new structures for which  special code has to be
 written. Maybe I just haven't found a simple way  but IMHO this would
 need at least 200 lines of fresh and buggy code.

>>  - need to check the domainlist for duplicated entries on
>>    every addition of a new domain otherwise we'd have possibly 
>>    hundreds of gettext calls for a translation lookup.
> Which you will have to do in any case.

 Yes, but at the moment I do this at registering time thus avoiding
 duplicated entries in the localerc file.

> Actually I don't see hundreds
> of internationalized plugins in addition to the ones that come with
> gimp

 But even those will have their own entry. One entry per plugin. 
 Considering the amount of plugins we ship with GIMP nowadays this
 would alone lead above hundred entries.

> and even if there were hundreds, iterating through a list of
> strings and comparing them is pretty fast.

 But it's additional code.
> If that's not enough, we could always a hash...

 Yes, but all I wanted was a small and simple solution for a stupid
 problem with gettext not a full featured framework. I'm really sure
 we'll get away from gettext in 1.3 so this will get obsolete sooner 
 or later.
>>  - need to add parsing functionality to libgimp to write the entries
>>    to pluginrc.
> Eeek, no! Libgimp doesn't have to know much about this at all.

 Where would you like to add this call then?

> The plugin would just call a second special gimp_install_domain()
> procedure if it needs to register a domain. Of course this means 
> adding a new type to the gimpprotocol, but I see no substantial
> problem in doing so.

 IMHO changing the wire protocol and doing all this with PDB is no
 great idea. It's complicated, a lot of work and unnecessary.

> Your additional libgimp function introduces the same incompatibility. 

 No, it doesn't. Apply the patch and run GIMP. Everything will work
 fine just by compiling this five files and relinking the GIMP
 of course your ~/gimp-1.1/localerc should contain:
 gimp-std-plugins /usr/local/share/locale

 No need to change or compile anything else. Of course adding the line
 gimp_domain_add (gimp-std-plugins) to at least one of the running plugins
 would circumvent the need to add those 2 lines manually. I could even think
 of registering gimp-std-plugins in source to avoid having to add the line
 to any of the standard plugins.

> There's no way to avoid this.

 There is a way, my way.

> I just do not see your point in keeping this very plug-in-specific
> info out of pluginrc where it belongs. app/plug_in.c contains all 
> the code you need to parse and write the pluginrc. Additionally 
> there's code to keep the plugin info in sync with the actually 
> installed binaries. Your solution is very weak when it comes to 
> that point and I see some substantial problems in that weakness.

 And I see bigger problems in changing all the parse and wireprotocol
 code to add such a small "feature" (it's more a bugfix).



Reply via email to