Yes, I will submit a proper patch. I'm new but I can figure it out.
I mainly wanted to get feedback whether it was desirable. I'm not clear
when a discussion of an enhancement should move to Bugzilla.
More testing reveals other issues and test cases:
First, most plugins have unguarded calls to register(), so importing
some plugins from a plugin ends up reregistering a plugin, with a
warning to stderr from the Gimp PDB but apparently harmlessly. I'm
still exploring, eg whether the order in which plugins are loaded
matters, whether the warning is only for local plugins, whether Gimp
supports multiple registrations of different plugins from the same
Python source, etc.
Second, what paths to plugins are set when a plugin is invoked?
Apparently only to local plugins, and not to plugins distributed with
Gimp. So to import a distributed plugin from any plugin requires the
importing plugin to extend the path. Not difficult but annoying.
On Tue, 2010-03-02 at 08:49 +0100, Sven Neumann wrote:
> On Sun, 2010-02-28 at 17:18 +0000, Omari Stephens wrote:
> > On 02/28/2010 02:43 PM, lloyd konneker wrote:
> > ::snip? SNIP!::
> > > Here is proposed addition for plug-ins/gimpmodule.c in pygimp_main()
> > > that I have lightly tested. Note it raises a warning (Python prints
> > > warning on stderr once, on the second call), not an exception. Note it
> > > compiles with a C90 warning about mixing declarations and code.
> > Just move the variable declaration to the top of the function. We
> > should strive to make the codebase compile with as few meaningful
> > warnings as possible.
> > Also, is that proper code style?
> No, it isn't. First of all, a gboolean should be used instead of an int
> and the code should use the macros TRUE and FALSE. And of course it
> should follow the GIMP coding style guidelines. We can certainly adjust
> the few lines ourselves. But it would make our life easier if you could
> submit a proper patch.
Gimp-developer mailing list