> I want to suggest that we implement this by moving most of the
> GimpConfig functionality from the core to libgimpbase or, alternatively,
> to a new library, maybe called libgimpconfig.
[ . . . ]
> There are a few things that we will need to decide upon, like in which
> library this should live, what namespace it should use (is GimpConfig
> a good name?), and how much of the core GimpConfig we actually want to
> expose to plug-ins and modules. There are a couple of features like
> the ability to nest objects that would perhaps better be kept for the
> core only as they add quite a bit of complexity.
Looking at the code, it seemed to me that these would be good things
to do, and not all that hard. There is plenty of space in libgimpbase,
and the name GimpConfig seems perfectly fine. The code in app/config
is nice and clean, and separates easily into things that can be moved
without too much trouble, and things that ought to stay there. It
also seemed to me that the best way to do it was in a single burst
of furious energy, because it would be quite difficult to do it
gradually and have GIMP continue to build during the process. And
then a fit of insanity came over me . . .
When I came back to consciousness about six hours later, somehow in
my personal tree all these files had migrated over into libgimpbase:
And somehow the includes had been fixed in about 200 files scattered
through the core code so that app would actually build. There is
some significant ugliness involved -- in particular, I have
config/config-types.h included in a lot of places where it shouldn't
be -- but the point is that it builds, and things like that can be
fixed one file at a time without breaking the build.
So now I have this mass of code that is going to bitrot at a furious
rate unless something is done with it, and I am wondering if I can
______________ ______________ ______________ ______________
Sent via the CNPRC Email system at primate.ucdavis.edu
Gimp-developer mailing list