Hi, > > 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
