Bryce Harrington a écrit :
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 http://brisgeek.com.
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.
Thanks again, Bryce
This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I just encountered today a problem with the new autopackage : tells protocol error.
cedric