On Mon, 29 Jan 2007 16:05:26 +0200, Alexander Rabtchevich wrote:

Many 3-rd side script-fu scripts, working in 2.3.12, refused to work in 2.3.14 on Windows. One of them even kills Gimp at program start.

Where can I read what has changed in script-fu specifications to adapt scripts? Or has the API changed?

As you can read in the NEWS file, the Scheme interpreter for Script-Fu has been replaced in 2.3.13. The old one (SIOD) was replaced by a better one (TinyScheme). TinyScheme offers a better support for the Scheme standard and for foreign languages: the old Script-Fu based on SIOD did not work well with UTF-8 strings.

The old interpreter tolerated some poor programming constructs that are not tolerated anymore by the new one. The main difference is that all variables have to be declared before being used. The old interpreter allowed you to do a (set! ...) on a variable without declaring it first and without giving it an appropriate scope in a (let ...) or (let* ...).

Besides encouraging bad programming style ("global variables"), this resulted in some namespace pollution and even in some bugs due to undetected spelling errors in variable names. The new interpreter does not accept these errors anymore, so if you have a script that was abusing set!, then you should fix the bugs in your script and ensure that all variables are given an appropriate scope using let.

Maybe we should retroactively change the NEWS file and add another line to the 2.3.13 entry saying something like "all variables in script-fu should be declared before being used"?

-Raphaël

Hi,

On Mon, 2007-01-29 at 16:13 +0100, Raphaël Quinet wrote:

Maybe we should retroactively change the NEWS file and add another line to the 2.3.13 entry saying something like "all variables in script-fu should be declared before being used"?

I don't think that the NEWS file is the right place for this. Someone should set up a detailed description of the changes with instructions on how to fix scripts that stop working after the update. We should then refer to this document from the 2.3 release notes (and of course also from the 2.4 release notes when they are written).

Sven

Hi,

On Tue, 2007-01-30 at 09:11 +0200, Alexander Rabtchevich wrote:

Raphaël, could you please explain me (I'm new to scheme) in a few words, why the global variables are poor style coding?

They are simply not allowed in Scheme.

From my POV, they
can only introduce memory consumption in common case (but not in the case of GIMP script-fu) and maybe some redefinitions in a large program (this doesn't concern Gimp also).

It does concern GIMP as all scripts live in the same namespace. A global variable defined in one script affects all other scripts.

But the inability to use global
variables along with scheme syntaxes leads to a good deal of parentheses which could be a problem to a programmer.

I don't see how this introduces the need for more parentheses.

Sven

Hi,

On Tue, 2007-01-30 at 09:40 +0200, Alexander Rabtchevich wrote:

Is the namespace cleared after script has finished its execution? And are there any scripts considered to run simultaneously?

The scripts are loaded when the Script-Fu extension is started. Of course the namespace isn't cleared or you couldn't run the script again. And there's only one interpreter process (currently) so there can only ever be a single script running.

Sven

Hi,

On Tue, 2007-01-30 at 09:55 +0200, Alexander Rabtchevich wrote:

So if the scripts were loaded dynamically on demand:

If I understood Kevin correctly the long-term goal for Tiny-Fu is to start the interpreter on demand for each script that is executed. So at some point scripts will behave more like plug-ins.

Sven

On Tue, 30 Jan 2007 08:24:40 +0100, Sven Neumann wrote:

On Tue, 2007-01-30 at 09:11 +0200, Alexander Rabtchevich wrote:

But the inability to use global
variables along with scheme syntaxes leads to a good deal of parentheses which could be a problem to a programmer.

I don't see how this introduces the need for more parentheses.

Just to prove that point, a couple of weeks ago I fixed a bug in a script that looked like this:

(define (some-function ...) (begin
(set! undeclared-var some-value) (... more code ...)
))

Fixing this problem was easy and made the code shorter:

(define (some-function ...) (let ((declared-var some-value)) (... more code ...)
))

-Raphaël

On Tue, 30 Jan 2007 16:06:00 +0200, Alexander Rabtchevich wrote:

Some more thoughts on local variables in scheme from a newbie POV.

Due to a parenthesis syntaxes of variable declaration area, if variable x is declared before variable y and y is declared before x is dropped, x remains active at least until y is dropped.

[...]

So what? Keep in mind that premature optimization is the worst ennemy of the developer. Script-Fu was never designed to be especially efficient: it was designed to get the job done with a minimum amount of developer effort.

Also, does it make sense to worry about leaving a variable and its context in memory for a little while when this variable only takes a few bytes and the data that you are manipulating is several orders of magnitude larger? Keeping an integer and its context on the stack means almost nothing in comparison with the megabytes of image data that the script is processing.

-Raphaël

Alexander Rabtchevich (alexander.v.rabtchevich@iaph.bas-net.by) wrote:

Raphaël, this IS exactly my point! Why should the global variables be prohibited if there is no difference in memory consumption with local ones, only additional efforts to a programmer to track all parenthesis.

Because global variables are not allowed in scheme and global variables are bad programming practice anyway (in basically all programming languages). And misuse can do great harm - we've seen that.

Bye, Simon

Hi,

On Tue, 2007-01-30 at 08:22 +0100, Sven Neumann wrote:

I don't think that the NEWS file is the right place for this. Someone should set up a detailed description of the changes with instructions on how to fix scripts that stop working after the update. We should then refer to this document from the 2.3 release notes (and of course also from the 2.4 release notes when they are written).

Any volunteer for this?

Sven

Sven Neumann writes:

On Tue, 2007-01-30 at 08:22 +0100, Sven Neumann wrote:

I don't think that the NEWS file is the right place for this. Someone should set up a detailed description of the changes with instructions on how to fix scripts that stop working after the update. We should then refer to this document from the 2.3 release notes (and of course also from the 2.4 release notes when they are written).

Any volunteer for this?

Doesn't that require someone with a good knowledge of what all the changes are?

If someone can make a quick comprehensive list, I'd be happy to help with getting it into a more readable form, if that's the issue. I don't know enough about the changes to make the list myself: I know what I've done to convert a few small scripts, but we need someone with more general knowledge than that.

Date: Tue, 30 Jan 2007 17:24:59 +0200 From: Alexander Rabtchevich

Raphaël, this IS exactly my point! Why should the global variables be prohibited if there is no difference in memory consumption with local ones, only additional efforts to a programmer to track all parenthesis. The common namespace is the other problem - it is due the luck of interpreter usage or implementation, not the language itself.

> Also, does it make sense to worry about leaving a variable and > its context in memory for a little while when this variable only > takes a few bytes and the data that you are manipulating is > several orders of magnitude larger? Keeping an integer and its > context on the stack means almost nothing in comparison with the > megabytes of image data that the script is processing.

Raphael is quite correct. Global variables are serious bad juju in this situation.

The basic problem here is that script-fu runs all scripts in the same environment. It isn't invoked separately for each plugin. This means that any plugin that uses a global variable without setting it first (basically, an unitialized variable) is at the mercy of any other plugin that may have set that variable. That means that if the programmer isn't careful the results obtained will depend upon what happened to be run previously -- in other words, plugins may give different results depending upon what happened before.

If you're going to initialize all global variables each time you run a script (which is the only safe thing to do, for the above reason), you might as well just not use them, since they're effectively going to be local, anyway. The first time you have to track down a bug caused by cross-script global variable pollution will cost you more time than *all* of the time you spend tracking parentheses on every script you write in your lifetime, practically guaranteed.

I remember one bug that took me something like 12 hours to find, in 6.001 (the intro programming class at MIT -- taught in Scheme, at least when I was there). It was due to a variable in the project code that was named "exp" that I was somehow picking up (I've long since forgoten the details -- I fired off an angry and frustrated email to Sussman and Abelson, and received a prompt apology). A few of those will change one's outlook in a hurry.

I won't go so far as to say that global variables should *never* be used -- just like all good rules, there are exceptions. A shared environment that's running many programs without any namespace separation is one place where there really should *never* be global variables that the individual programs can use read/write (as opposed to global read-only variables exported by the environment, which are safe). Statically scoped variables would be safe enough; I don't recall that Scheme supports them (as I recall, everything in Scheme is supposed to be lexically scoped).

Hi,

On Tue, 2007-01-30 at 12:53 -0800, Akkana Peck wrote:

If someone can make a quick comprehensive list, I'd be happy to help with getting it into a more readable form, if that's the issue. I don't know enough about the changes to make the list myself: I know what I've done to convert a few small scripts, but we need someone with more general knowledge than that.

Kevin should be able to answer all your questions on this. He is probably the only one who knows about all the changes in detail.

Sven

I have a rough draft of some of the differences between SIOD-fu. It is not yet comprehensive but perhaps it might be useful as a starting point.

http://flashingtwelve.brickfilms.com/GIMP/Scripts/Script-fu-2/Reference/SIODdifferences-0.1.txt

On Tue, 2007-01-30 at 12:53 -0800, Akkana Peck wrote:

If someone can make a quick comprehensive list, I'd be happy to help with getting it into a more readable form, if that's the issue. I don't know enough about the changes to make the list myself: I know what I've done to convert a few small scripts, but we need someone with more general knowledge than that.

--------
"It is amazing what you can accomplish if you do not care who gets the credit." -- Harry S. Truman

Alexander Rabtchevich wrote:

Many 3-rd side script-fu scripts, working in 2.3.12, refused to work in 2.3.14 on Windows. One of them even kills Gimp at program start.

If you have a script that crashes GIMP, you should post it somewhere so it can be examined. No script should be able to kill GIMP. Scripts can crash plug-ins since some plug-ins don't check the passed parameters properly but that is a different issue.

Where can I read what has changed in script-fu specifications to adapt scripts? Or has the API changed?

I have some notes on my web page in the information about Tiny-Fu but I haven't gotten around to turning the information in to any formal documentation about the differences.

PS. I would have replied sooner but it seems I haven't been checking my gimp-devel mail folder very closely over the last couple of weeks.

Alexander Rabtchevich wrote:

Raphaël, could you please explain me (I'm new to scheme) in a few words, why the global variables are poor style coding?

Global variables can lead to bugs if not used carefully. The use of global variables in Script-Fu is particularly bad since all scripts are read in to a single namespace. A global variable defined in one file can be altered by code in another file without the need to use a Scheme equivalent of a C extern declaration. Everything will seem ok until you add another script file from somewhere that happens to use a global variable with the same name as a global defined in another file.

Problems can also arise when two files have global functions with the same name but different behaviour. This sort of problem has been seen even amongst the scripts shipped with GIMP. It is why you now see the use of locally defined functions rather than global ones in most scripts. For an example, look at the alien-glow-arrow.scm file.

But the inability to use global
variables along with scheme syntaxes leads to a good deal of parentheses which could be a problem to a programmer.

When you understand the syntax of the language, the use of local variables instead of global doesn't have any significant impact on the number of parentheses in a script.

If someone is afraid of the parentheses they shouldn't be trying to use Scheme. :-) More likely the fear of parentheses is caused by badly formatting the Scheme code (ie. lack of whitespace). Always putting the closing brackets for statements at the end of a single line leads to wasting a lot of time counting brackets.

Sven Neumann wrote:

If I understood Kevin correctly the long-term goal for Tiny-Fu is to start the interpreter on demand for each script that is executed. So at some point scripts will behave more like plug-ins.

That is one of the goals I have in mind for the Script-Fu plug-in.

Alexander Rabtchevich wrote:

I've managed to make my old script working. The problem I got was a misunderstanding of scheme syntaxes as it wasn't expressively shown.

You should look at the Scheme code in the Script-Fu scripts which ship with the SVN version of GIMP. Most of them are formatted in a way that makes it much easier to see the syntax of the language without the need for bracket counting. You may also find the Scheme standard document (R5RS) worth reading. You can find a copy of it at:

http://www.schemers.org/Documents/Standards/R5RS/r5rs.pdf

Not everything in that document is supported in the updated version of Script-Fu but much of it is.

On Fri, 16 Feb 2007 06:33:20 +0100, Kevin Cozens wrote:

Sven Neumann wrote:

If I understood Kevin correctly the long-term goal for Tiny-Fu is to start the interpreter on demand for each script that is executed. So at some point scripts will behave more like plug-ins.

That is one of the goals I have in mind for the Script-Fu plug-in.

First of all thanks for your efforts , you seem to have been working on all this for a long time now.

One thing that concerns me with Gimp development in general and of which these changes are a good example is lack of concern for backwards compatability.

A lot of people have contributed in one way or another to gimp over time but that does not mean they will always be here or be able to provide never ending support for things , like a plugin, they have contributed. There was a powerful suite of plugins written by a German maths doctor that got dropped a long time back. It seemed, having done the job once , he did not have the time to redo it when gimp decided to change the interface.

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 . 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. (If there's a way around this please correct me, and please do not take this as an attempt to reopen the heated arguements this issue invovled. The issue is that of continuity vs breakage).

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.

Since this is one of your goals anyway , wouldn't it save a lot of effort all round and preserve a number of plugins that may not get ported across, if this could be brought forward?

You seem to have a lot of skill and familiarity with this area , is this an enormous undertaking ?

thx.

On Fri, 2007-02-16 at 09:33 +0100, gg@catking.net wrote:

One thing that concerns me with Gimp development in general and of which these changes are a good example is lack of concern for backwards compatability.

A lot of people have contributed in one way or another to gimp over time but that does not mean they will always be here or be able to provide never ending support for things , like a plugin, they have contributed. There was a powerful suite of plugins written by a German maths doctor that got dropped a long time back. It seemed, having done the job once , he did not have the time to redo it when gimp decided to change the interface.

What interface change do you mean? The plug-in API and ABI are supposed to be backward-compatible. Any incompatibility you find is a bug that will be fixed.

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 . 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. (If there's a way around this please correct me, and please do not take this as an attempt to reopen the heated arguements this issue invovled. The issue is that of continuity vs breakage).

What keeps you from using the gutenprint gimp plug-in? All stable gimp versions have a working print plug-in. The developer version being broken in some areas is something you just have to live with.

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.

The script-fu incompatibility issues you raise are due to the fact that we switched from the totally antique and unmaintained SIOD to something sane. I hope you don't want to get back to SIOD and re-introduce all its shortcomings.

Since this is one of your goals anyway , wouldn't it save a lot of effort all round and preserve a number of plugins that may not get ported across, if this could be brought forward?

Are you talking about plug-ins or script-fu scripts?

ciao, --mitch

On Friday, February 16, 2007, 10:36:14, Michael Natterer wrote:

What interface change do you mean? The plug-in API and ABI are supposed to be backward-compatible. Any incompatibility you find is a bug that will be fixed.

I'm guessing 1.2 -> 2.0.

Date: Fri, 16 Feb 2007 09:33:40 +0100 From: gg@catking.net

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.

On Fri, 16 Feb 2007 13:01:16 +0100, Robert L Krawitz wrote:

Date: Fri, 16 Feb 2007 09:33:40 +0100 From: gg@catking.net

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 compatability.

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 all possible.

Thx.

[off] 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. [/off]

Hi,

On Fri, 2007-02-16 at 14:23 +0100, gg@catking.net wrote:

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 has always been guaranteed. The plug-in and PDB API is stable and will be for the foreseeable future. I think we have always made this very clear.

Sven

On Fri, 16 Feb 2007 13:01:16 +0100, Robert L Krawitz wrote:

Date: Fri, 16 Feb 2007 09:33:40 +0100 From: gg@catking.net
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.

Hi,

I only just noticed this comment at the top of your reply.

The problem is that my distro , Gentoo, has a dependancy block on gimp-print>4.2.7 with gimp-2.2

Now from what you say this may be an error or a misunderstanding of old issues. I recall quite some time ago I put in a bug report at bugs.gentoo.org and got this was an "upstream" issue and the block would remain until that was resolved.

If you can help me fix this issue , which may be infact a non-issue, you may help clear this up for all Gentoo users as well.

It seems the crux of the issue is version checking done by gimp precompilation checks.

http://bugs.gentoo.org/show_bug.cgi?id=75918#c8

According to configure.in:

m4_define([gimpprint_required_version], [4.2.0]) m4_define([gimpprint_suggested_version], [4.2.6]) m4_define([gimpprint_toonew_version], [4.3.0])

Therefore, if you use >=4.2.*, gimp maintainers don't support it.

The ebuilds will stay how they are until the maintainers say that its okay to use a later ( probably non-beta ) version of gimp-print.

Thanks for reporting!

Is the conclusion from this that the src tarball for gimp 2.2.x needs these checks to be changed because gimp-print-5.x does now work with it?

TIA.

Date: Tue, 20 Feb 2007 10:35:59 +0100 From: gg@catking.net

On Fri, 16 Feb 2007 13:01:16 +0100, Robert L Krawitz wrote:

> Date: Fri, 16 Feb 2007 09:33:40 +0100 > From: gg@catking.net
> 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.

I only just noticed this comment at the top of your reply.

The problem is that my distro , Gentoo, has a dependancy block on gimp-print>4.2.7 with gimp-2.2

Now from what you say this may be an error or a misunderstanding of old issues. I recall quite some time ago I put in a bug report at bugs.gentoo.org and got this was an "upstream" issue and the block would remain until that was resolved.

This problem's a bit more complicated. GIMP 2.2 does have a dependency on Gimp-Print 4.2; the Print plugin in GIMP 2.2 requires the Gimp-Print 4.2 library, and Gutenprint 5.0 has an incompatible API. However, we've already thought of that; it's possible to have both Gimp-Print 4.2 and Gutenprint 5.0 installed concurrently.

Is the conclusion from this that the src tarball for gimp 2.2.x needs these checks to be changed because gimp-print-5.x does now work with it?

Well, the actual story is that Gutenprint 5.0 includes its own Print plugin for the GIMP that replaces the one in GIMP 2.2. The best thing to do is to configure the GIMP with

configure --disable-print (or --without-print, I don't remember which)

and then to install Gutenprint on top of it.

On Tuesday 20 February 2007 03:32, Robert L Krawitz wrote:

Date: Tue, 20 Feb 2007 10:35:59 +0100 From: gg@catking.net

snip

Well, the actual story is that Gutenprint 5.0 includes its own Print plugin for the GIMP that replaces the one in GIMP 2.2. The best thing to do is to configure the GIMP with

configure --disable-print (or --without-print, I don't remember which)

and then to install Gutenprint on top of it.

On gentoo this mean that you need set use="-print" for when you emerge gimp (IE. set this in /etc/portage/package.use) and then emerge gimp-print with the correct keywords set to get gutenprint 5.0 which is currently marked ~ for all architectures. I have been doing this for sometime now without any problems and if I remember correctly this is what the Gentoo devs recommended in a bug report about this. Setting use="-print" is no longer needed for versions of gimp >=2.3.x but you do have to emerge gimp and gimp-print in the correct order to end up with the gutenprint 5 plugin in gimp.

Hal

On Tue, 20 Feb 2007 19:26:30 +0100, Hal V. Engel wrote:

On Tuesday 20 February 2007 03:32, Robert L Krawitz wrote:

Date: Tue, 20 Feb 2007 10:35:59 +0100 From: gg@catking.net

snip

Well, the actual story is that Gutenprint 5.0 includes its own Print plugin for the GIMP that replaces the one in GIMP 2.2. The best thing to do is to configure the GIMP with

configure --disable-print (or --without-print, I don't remember which)

and then to install Gutenprint on top of it.

On gentoo this mean that you need set use="-print" for when you emerge gimp
(IE. set this in /etc/portage/package.use) and then emerge gimp-print with
the correct keywords set to get gutenprint 5.0 which is currently marked ~
for all architectures. I have been doing this for sometime now without any
problems and if I remember correctly this is what the Gentoo devs recommended
in a bug report about this. Setting use="-print" is no longer needed for versions of gimp >=2.3.x but you do have to emerge gimp and gimp-print in the
correct order to end up with the gutenprint 5 plugin in gimp.

Hal

Hi,

On Fri, 2007-02-02 at 03:56 -0800, Saul Goode wrote:

I have a rough draft of some of the differences between SIOD-fu. It is not yet comprehensive but perhaps it might be useful as a starting point.

http://flashingtwelve.brickfilms.com/GIMP/Scripts/Script-fu-2/Reference/SIODdifferences-0.1.txt

I get an error "403 Forbidden" when trying to reach this address? Did you take the document down or is there just a permission problem? Is there a newer version I should try?

Sven