>> At the level of programming, the only relatively difficult thing is to
>> create the GimpDataChooser widget. Even this is simple in principle,
>> although complicated in practice because it involves a lot of rather
>> complex Gimp code. I have been experimenting with writing a Chooser,
>> and I believe I have gotten through the hardest part, although there
>> is quite a bit of refinement needed.
>Why bind it into gimp? This tool could be totally independent of GIMP runtime
>wise. All that would be need on gimp side is support for using gimp-remote to
>trigger reloading of resources. All other management could happen outside
>GIMP. Functions needed to read and write gimp conf should be easily portable
>from gimp code.
That's true in principle, but building a separate executable that uses
a major part of the Gimp object system would be a much larger
change. I don't think that proceeding the way I have suggested
would make it any harder to separate the functionality in the
future -- and in any case it must easily be available from inside
By the way, the functions needed to *show* resources are not
easily portable from the Gimp code -- this requires creating
a GimpDataFactoryView, which brings a major part of the
internal Gimp object system into play.
Gimp-developer mailing list