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

Why should they have an entry? The current solution for the plugins
distributed with The GIMP works reasonably good. I don't see why we 
should ditch the hardcoded path in favor of a config file the user 
will be able to mess with. I thought your proposal would only be a 
hook for additional plugins?!

> > There's no way to avoid this.
>  There is a way, my way.

I was speaking about the fact that whatever solution we come up
with will not be backward compatible. It should however be robust
and shouldn't keep old plugins from running.

I will have to look through the code in app/plug_in.c a little more,
but I think I was wrong in my last mail and there's no need to change
the wire protocol at all. 
> > 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).

The amount of code-changes is IMHO more or less equal. The small 
feature you want to add should be well-thought and I don't see 
why you simply wipe away the arguments have I put up against your 
solution. Don't tell me that you have spent days to create your patch 
and don't want your hard work to be discarded. 

Salut, Sven

Reply via email to