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.
Okay.
> 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.
--
Servus,
Daniel
