On Sun, 18 Jul 2004, Mike Hearn wrote:
> On Sat, 17 Jul 2004 18:28:56 -0700, Bryce Harrington wrote:
> > Excellent! What I've heard from people who have used this has been
> > positive. I know from my own experience that it can sometimes fail, but
> > I've not heard any complaints either.
> 0.6 fixed a bunch of bugs with unusually set up systems, hopefully you'll
> have more luck with this release.
Cool, I'll plan on inflicting it on the folks at work again, and take
notes as to how it goes.
> > *Grin* I love that autopackage was able to use inkscape for that. :-)
> > Befriend Brisgeek; he is the best icon author I know.
> Where can I find Brisgeek? I'm sure he can do a better job than that :)
He's the creator of the etiquette icon set (see
http://themes.freshmeat.net/projects/etiquetteicons/) He's occasionally
on our jabber channel. His email address is andrew at fitzsimon.com.au
You can check out his site at http://andy.fitzsimon.com.au and at
> > Sounds like something worth looking at. Note though that long term we
> > intend to implement a more sophistictated plugin extension system, with
> > the intent of providing a systematic way of handling things like
> > gtkspell. So hopefully we won't need this...
> That works too, though obviously not so well for new symbols in
> pre-existing libs like the new GTK file picker.
*Nod* Yup, quite true.
> > By the way, Mike, one request we have for autopackage, that we'd like to
> > see implemented by the time we release 0.40 is a way for us to hook to
> > the autopackage files without having to include them in our source trie.
> > In other words, we'd like to be able to link to a libautopackage that
> > includes prefix.cpp and such, rather than have prefix.cpp inside our
> > codebase. I think this would benefit us by making it a little more
> > straightforward to coordinate changes between our projects. What do you
> > think?
> Well, we discussed this when first implementing binreloc and decided that
> given how different varying codebases were and how small the code was, it
> made sense to simply copy & paste for now. In future we're hoping to get
> this functionality into glib (and maybe Qt as well) so it'll be available
> from there.
That sounds okay for the time being, although we will keep lobbying for
it for the future. I think the motivation is less about the code size
so much as the fact that it is low level code that is being shared by
multiple projects. As well, copy-and-paste codebases tend to work best
when the code is static (for instance the ecma code we imported into the
inkscape codebase is not likely to change); having it be a separate lib
(or part of glib) would enable the autopackage project to update and
make changes to the code without having to coordinate with each project
that uses it. Incorporating it into glib would provide a similar
solution, although note that that may be less flexible than if
autopackage maintained a separate lib (for users with old glib's or
wishing to use it on *nix's that don't use glib).
Anyway, I'm sure you've gone over all these types of considerations
already, but it may be worth thinking some more about. As autopackage's
popularity scales up, the copy-and-paste approach for the shared code
may make things more challenging for you in future deployments.