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.
On Wed, Mar 19, 2008 at 7:43 AM, David G. <[EMAIL PROTECTED]> 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
Gimp-developer mailing list