On Fri, 16 Feb 2007 13:01:16 +0100, Robert L Krawitz <[EMAIL PROTECTED]>
> Date: Fri, 16 Feb 2007 09:33:40 +0100
> From: [EMAIL PROTECTED]
> There is also problems with the way changes broke the interface
> with gimp=print, amongst other things. Gimp 2.3 is still seriously
> unfinished as far as the print dlg goes yet it seems I still cannot
> use gutenprint with 2.2.
> What problem are you having using Gutenprint with GIMP 2.2? It should
> work fine, and I'd like to help you fix it.
> Net result I can't use my printer with
> gimp. As I understood that rather contentious exchanges between
> Sven and the gp lead dev this was because there were incompatible
> changes in the API.
> That's not the issue. The GIMP folks are quite innocent here. The
> primary problem was that on the Gutenprint side (I'm the project lead
> for Gutenprint) we were taking excessively long to release our stable
> version (5.0). I was hoping that we could hand over maintenance of
> the Gutenprint-based plugin to the GIMP team, but since our release
> was long-delayed we weren't able to make the releases line up. The
> Gutenprint delay was, in my opinion, for the better -- we resolved
> some important API issues late in the release cycle -- but it
> prevented us from handing off the plugin in time for 2.2.
> There were also issues with the Gutenprint-based plugin's user
> interface -- it's admittedly no work of art.
> Sven and I did have a disagreement over exactly which versions of the
> GIMP and GTK to target compatibility at -- Sven urged us to drop
> support for GIMP versions earlier than 2.2 to take advantage of newer
> features, while I wanted to maintain compatibility back to 2.0. But
> that was a subsidiary issue. Obviously, had we been able to hand over
> the plugin to the GIMP team this would have been a non-issue.
> There are quite obvious issues with running everything in the same
> name space. Surely the best way to address this issue would be to
> run a separate instance of the interpreter rather than put new
> conditions on the scripts that breaks a number of the ones in the
> registry and very likely at lot that are not. This would seem to be
> a work around for a flaw in the way gimp handles this.
> I'm a firm believer in maintaining back compatibility myself, but in
> this case I think the tiny-fu approach is much better than trying to
> maintain bug-for-bug compatibility. Any act of separating the
> namespaces is sure to cause some breakage because some script or other
> is going to implicitly rely on previous state, resulting in very
> tricky problems to debug. Better to take this hit once -- and most of
> the hit is on poorly-written scripts that will inevitably be hard to
> maintain -- than to be dealing with a broken architecture forever.
Thanks very much for clarifying all that and your comments on
Compat is desirable in general but obviously should not be taken to the
exclusion of all progress . It's a balance. Like you say better to take
this in one hit. If this can clear the road for the future in a definitive
way that's great. Breakage between 1.2 and 2.x , fine, we do want
progress. My concern was not to see breakage 2.0 to to 2.2 , 2.2 to 2.4 ,
2.4 to 2.6 etc.
This was just an example, apologies to gimp devs if this was off target.
Not sure if you comment was a call for doing the separte name space at the
same time as swapping interpreter. But if that is likely to cause further
breakage it would seem desirable to get this all done in one hit, if at
my Canon i965 seems to work well with guten-print in terms of quality but
changing dpi does not seem to work and results in larger smaller output.
Presumably a small tweek if you get a chance.
Gimp-developer mailing list