Wow, didn't notice I was repeating Alexia. Sorry, Alexia :) Although that makes me think -- something like python's easy_install would be terribly handy for resources.. If you're not familiar with it, basic usage is : 'easy_install foo' installs the latest version of foo. This would require a centralized repository (the resources needn't be stored there, metadata would need to be.) Would be a nice backend for a DnD app. Also,.. On Wed, Mar 19, 2008 at 7:43 AM, David G. <allenskd@xxxxxxxxx> wrote: > Sorry but I don't agree with that. I think GIMP should be more of a 'out of > a box' term than just worrying about sizes and things that could be taken ?? worrying about sizes ?? Oh, you mean distribution size. This is undoubtedly an issue, it is less of a concern than simple cumbersomeness: the amount of files in the GIMP distribution is too much already.. for a sample, look at the plug-ins/common directory in a GIMP source tree. Approximately, each C file produces a plugin, there are a lot of plugins there.. (120+ IIRC); similarly I think we have too many gradients by default, too many palettes, and too many patterns. This is partly because there isn't a 'filtered/tagged' view, so that we only need to consider relevant resources. Also, GIMP developers are required to manage this multiplicity of resources, which becomes harder the more resources there are in the distribution. (there is infrastructure for tagging, and no UI or I/O for tagging, IIRC. I think it might take quite a bit of work to get the tagging UI right.) _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
