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

  -- Bill

Gimp-developer mailing list

Reply via email to