My First Script-Fu Script 5

 
I'm getting to the point where I need
a Script-Fu template that I can understand
and modify. Here's a guy named Simon who
has come to my rescue:

Simon Budigs

He has written a Script-Fu template
which he keeps here:

Script-Fu Template

I've looked at this script
and it is 116 lines long.
The call to script-fu-menu-register
comes last. In my version
of the script, this function
call is spread across lines
115 and 116.

Apparently there is something
here I do not fully understand.
I thought it was 2nd argument
to script-fu-register that
determines where the the script
is hung in a menu.

From reading the code, I can see
that this is clearly not the case
in this script. It appears, in
this script that the second argument
to script-fu-register provides
a description of the menu item but
does not hang the menu item in place.

Line 104 in my version of this script
says "Rectangle..." which is
a pretty good description of what
the menu item does. Line 104 is
the second argument to script-fu-register.

So, I'd say that my orginal assumptions
are not correct if a call to
script-fu-menu-register is present.

Seems that script-fu-menu-register plays
the role of menu-item-hanger and the 2nd argument
to script-fu-register plays the
role of menu-item-descriptor. At least, that's
the appearance.

Let me try the script again . . .

OK. I'm back. My new assumptions turn out
to be correct. Argument number 2 to
script-fu-register is the descriptor
for the menu item. Not only that, but
argument 3 to script-fu-register is
the tool tip. This makes total sense.

OK. Now I now, script-fu-menu-register
is for menu hanging only. That is to say, the
only purpose of this function is placement of
the script in a specific menu.

OK. I totally understand now. The second
argument to script-fu-register has
what is called in Unix a dirname and
a basename.

The basename is the final part of the path,
typically a file name. The dirname is
everything leading up to the basename,
typically a diretory path to a filename.

In Unix, basename and dirname
are actual commands used at the shell command
line.

Now I understand the second argument to
script-fu-register completely. It
is a dirname/basename approach. The dirname
is the location of the menu item in
the menu system. The basename is the
descriptor of the menu item in
the menu system.

Here's a concrete example:

"/Xtns/Script-Fu/_ATG/Strawberries"

Everthing up to the word Strawberries
is a menu path. Once the menu item is hung
in the proper location, Strawberries
is the label for the menu item.

Where does script-fu-menu-register
come to play in all this? It is an alternative
menu hanger. If you want, you make the
second argument to script-fu-register a
menu-item label only. If you do things this
way, it is then left up to script-fu-menu-register
to provide a path to the menu item.

Confused? Here's an even simpler way to look
at it. You need to do two things to make your
script appear as a menu item:

1. Provide a menu path to the menu
   item
2. Provide a label for the menu item

You can either have script-fu-register
do both of these things or you can have
script-fu-register do one and have
script-fu-menu-register do the other.

The lesson here? Like all things in life,
software is subject to revision. I suspect
that script-fu-menu-register was
introduced at some point as a software revision
of some kind.

If this were the case, script-fu-register
would still continue to function the way it
always did so as to preserve backwards compatibility.

All of this is pure speculation on my part. Why
two functions are capable of providing the same
specific functionality is uncertain.

Ed Abbott

My First Script-Fu Script 4,Registering a Function

 
This morning I'm trying to
figure out the script-fu-register
function. Since this function is so
very fundamental to Script-Fu, I thought
I should know something about it.

I'm using this web page as my reference
as I try to figure out script-fu-register
and the arguments to script-fu-register:

3.4.5. Registering The Function

You'll have to scroll down the page a bit to see
Section 3.4.5. This is the section that
describes the script-fu-register function.

From what I read, I gather that the parameters
to script-fu-register are divided into
two categories:

1. The first 7 (required) parameters
2. The parameters (optional) that are
   passed into the script-fu script itself

In other words, the first 7 parameters are
required. The 8th parameter, if there is
one, would be the first argument to the
Script-Fu script itself.

For those familiar with C Language, I'm going
to assume something here. It is my assumption
that parameter number 8 and beyond are
functionally equivalent to the arguments
to the C Language main() function.

Clearly you do not need anything but the
first 7 parameters if you are writing an
interactive Script-Fu script. That's my
assumption. I assume that you only use
parameters number 8 and beyond if you are
doing some kind of command line call.

In other words, I'm assuming that parameters
number 8 and beyond become valuable when
you go to a higher level of automation.
For example, you might want to use Script-Fu
to batch process a series of 100 images. To
do this, having the ability to pass arguments
in via the command line is very valuable.

My assumption is that arguments number 8 and
beyond become valuable when you go to a higher
level of automation, such as processing multiple
images serially with no user interaction whatsoever.

OK. Back to the required arguments to
script-fu-register. The first 7
required arguments appear to me to be
more than sufficient if all you are going
to do is process the current image interactively.
That is to say, you are planning to interact
with the current image yourself inside of the
Gimp user interface.

The Gimp user interface is where you normally
do things to images. For the normal Gimp user,
the normal Gimp user interface is the normal place
to be. The first 7 arguments to script-fu-register
will suffice for the normal Gimp user interacting
with the normal Gimp user interface.

Here are the 7 arguments given in the order in
which they appear:

1. The name of the entry function.
   All functions are called from this
   master function.
2. The menu location for
   the script
3. A description that documents
   the script
4. Your name as author of
   the script
5. Your copyright notice for
   your script
6. The date you created your
   script
7. The image type the script
   works on. If no image type is
   applicable, it appears to me that
   a double asterisk will suffice

OK. Those are the 7 parameters to
register-script-fu. These parameters
are so important that it would seem that
they are required for every single
Script-Fu script that you will
ever write.

This is my assumption. Later, I may
have to go back and correct any false
assumptions I've made in this post.

This post is written by a Script-Fu
newbie. I'm learning Script-Fu as I
go.

Ed Abbott

My First Script-Fu Script 3

 
Tonight I've been looking at a
Script-Fu script. I've been
trying to formulate some guidelines
for reading such a script.

For me, the key to understanding
a Script-Fu script is to look for
the following function in the
script:

script-fu-register

The first two arguments to this
function tell you two important
things:

1. The name of the Script-Fu
   script
2. The menu that the Script-Fu
   script hangs off of

These two pieces of information
go a long way to help you to
figure out a script.

The lesson? Start at the beginning.
The beginning is a very good place
to start.

In many ways, a Script-Fu script
begins with the script-fu-register
function.

Ed Abbott

My First Script-Fu Script 2

 
I'm still working on creating
my first Script-Fu script. I
created one years ago but it
has been so long now that I've
forgotten how to do it.

OK. I just found a Script-Fu
script that I wrote in October
of 2004. Looks like I can take
this script and modify it.

First thing I'll do is see if this
script works as is. I'll copy it
to this directory:

~/.gimp-2.4/scripts

Let's see how it goes.

OK. I'm back. It seems that I've run
into this error on this old script:

Error: set!: unbound variable: image_list 

I find that this error is in fact the most
common error of all when migrating old
Script-Fu to new Script-Fu. The error
comes up because my script is now running
under something called the TinyScheme
interpreter. The problem is described
here:

Script-Fu in Gimp 2.4

Indeed my version of Gimp is Gimp 2.4.

Let's see if I can fix the problem. The
recommended solution seems to be to use
a let* and use local variables rather
than global variables.

OK. I'll leave off here. Apparently this
is a difference between the old interpreter
(SIOD) and the new interpreter (TinyScheme).
The old interpreter lets you set variables
without declaring them but the new interpreter
does not.

I'm learning as I go here. However, this seems
to be the case.

The let * got me beyond the above error.
Seems that let * is the answer to this
problem.

The lesson? Things change. When a change comes
up, you have to adjust.

Ed Abbott

My First Script-Fu Script

 
I'm exploring how to write a Script-Fu
script. Actually, I wrote one years ago.
However, it has been so long since then
that I've forgotten most of what I learned.

Time to update my skills.

Here's a Script-Fu tutorial that I like:

A Script-Fu Tutorial

The first thing the tutorial does is give
you a little knowledge of the Scheme programming
language. Script-Fu scripts are written in
Scheme.

I've been trying to review Scheme and have even
created a blog for doing so. My first Scheme blog
post is here:

Learn to Program in
Scheme 1, Getting Started

The overall Scheme blog that this post comes from
is here:

Learn to Program in Scheme

OK. Back to the tutorial. The tutorial makes
three simple points about Scheme:

1. Statements are surrounded by parentheses
2. The first item inside the parentheses is
   the operator
3. Since functions are basically operations that
   you write yourself, functions also come first
   inside the parentheses

In some ways, it would seem that Scheme is a
simplified programming language. All you have
is operators and arguments to operators. The
operator and its arguments are surrounded by
parentheses. It's that simple.

OK. That's a too brief summary of Scheme on
my part. However, since I'm learning this stuff
myself as I write, I want to keep moving.

I'll try some of the console stuff first. To
get to the console, fire up Gimp and go through
the following menus:

Xtns > Script-Fu > Script-Fu Console

A cautionary note about the second menu.
It seems that on my version of Gimp, there
are 2 menus labeled Script-Fu. That
is to say, the Xtns menu has two items
with the same name. Why that is I'll probably
never know.

In any case, it is the first Script-Fu
menu that is of interest. This is the one that
has the Script-Fu Console menu underneath
it.

As the tutorial suggests, I enter the following
in the bottom of the console window:

(+ 3 5)

I get this back as output:

> (+ 3 5)
8

OK. This is kind of fun. I assume
that the number 8 comes back and
prints because Scheme operations
always return an argument of some
kind. That's my, as of now, vague
understanding of Scheme.

Wow! Just noticed the console has a
save button. Does this mean
you can save things that you try out?
Perhaps. I have not tried this feature
yet.

I'll leave off here. The next blog
post will cover the let operator.
Perhaps I should call it the let
statement. In any case, let will
be the subject of my next post as this
seems to be the next topic in the tutorial.

One lesson I've learned from this tutorial
is that you have to do the work. To get
results and to learn, you have to do what
the tutorial author suggests for homework.

My tendency is to want to read a tuturial
and absorb the whole thing in one single
reading. Sometimes that's not possible.
Sometimes it's important to do your homework.

Ed Abbott