On 23 Feb, Sven Neumann wrote:

> Huh? Daniel, stop spreading FUD and read the code. The parser in
> gimprc is actually pretty flexible.

 No, it isn't. It supposes a fixed order and fixer number of arguments
 (except the pdbargs of course), that anything but flexible.
 A tag based system on let's say XML would be a lot more flexible 
 and allow us to save some bytes in the pluginrc.

> Well, I have no problem to discuss the arguments, I just had the
> impression that you simply ignored them...

 No, I wouldn't ever do that.

> A PDB call is actually no harm. IMO libgimp should not fiddle with
> configuration files at all. Since the localisation of the menuentries
> is a problem in the core and not one of each and every plugin, putting
> the functionality into libgimp is actually bad style.

 But simple. I have no problem with a more complex solution as long as
 is seems reasonable and maintainable in a "frozen" tree. 

> I am proposing exactly the same solution, with a little difference: 
> Instead of doing the work in libgimp which is not suited to work 
> with configuration files, make the libgimp call be a PDB wrapper 
> and let the application handle the dirty work. 

> The advantage I see is that we will not need another configuration
> file and we have the information about a plugins gettext-domain
> in the plugin structure where it belongs and where it is automatically
> kept in sync with the list of installed plug-ins.

 Let's sync our ideas. We add two optional entries after the PDB args
 in pluginrc which get's parsed by the normal parser and inserted in a
 list and then my code does the rest.



Reply via email to