>> 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. > >--Alexia 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 Gimp. 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 Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
