Gimp Python in Win32
re...@news.group
I downloaded <http://gimp-setup-20000416.zip> (v 1.1.19) from
the Win32 subdirectory on the gimp.org site. Then I got the gimp
python binaries from Hans Breuer's site at
<http://hans.breuer.org/ports/pygimp-2000-04-04.zip> and
<http://hans.breuer.org/ports/pygtk-2000-04-04.zip>. I unzipped them
and placed the files in the Python and Gimp directories according to
the instructions in the readme.win32.
Here's the point. I followed the instructions, including
adding the PATHEXT environment variable, and Python-fu still does not
show up in my Gimp Extensions menu. Can anyone help me over this last
step so I can write Gimp extensions in Python?
Thanks,
Bill
Piet van Oostrum
B> Hello all,
B> I downloaded <http://gimp-setup-20000416.zip> (v 1.1.19) from
B> the Win32 subdirectory on the gimp.org site. Then I got the gimp
B> python binaries from Hans Breuer's site at
B> <http://hans.breuer.org/ports/pygimp-2000-04-04.zip> and
B> <http://hans.breuer.org/ports/pygtk-2000-04-04.zip>. I unzipped them
B> and placed the files in the Python and Gimp directories according to
B> the instructions in the readme.win32.
B> Here's the point. I followed the instructions, including
B> adding the PATHEXT environment variable, and Python-fu still does not
B> show up in my Gimp Extensions menu. Can anyone help me over this last
B> step so I can write Gimp extensions in Python?
I did this also and it worked after rebooting. Worked meaning I got the
python-fu menu entries.
There were a few problems, however:
1. At startup the python console comes up, and it hangs the Gimp until you
close the console, after which the Gimp continues loading the plugins.
It displays this message in the Command prompt window:
** WARNING **: wire_read: unexpected EOF (plug-in crashed?)
I think the console shoulnd't become active at load time, only when it is
requested.
2. The scripts seem to have some problems. For example, the sphere script
gives this message in the Command prompt window:
Traceback (innermost last):
File "C:\APPS\PYTHON\GTK\gimpfu.py", line 410, in _run
res = apply(func, params)
File "C:\APPS\GIMP\plug-ins\sphere.py", line 47, in python_sphere
pdb.gimp_edit_fill(drawable)
TypeError: wrong number of parameters
--
Piet van Oostrum <pi...@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van....@hccnet.nl
pi...@cs.uu.nl
PvO> There were a few problems, however:
PvO> 1. At startup the python console comes up, and it hangs the Gimp until you
PvO> close the console, after which the Gimp continues loading the plugins.
I found out that this was caused by gtkcons.py being in the plug-ins
directory. This is where it is unpacked, but you have to move it to the
Python lib directory.
PvO> It displays this message in the Command prompt window:
PvO> ** WARNING **: wire_read: unexpected EOF (plug-in crashed?)
I think this is caused by another script (clothify.py?).
PvO> 2. The scripts seem to have some problems. For example, the sphere script
PvO> gives this message in the Command prompt window:
PvO> Traceback (innermost last):
PvO> File "C:\APPS\PYTHON\GTK\gimpfu.py", line 410, in _run
PvO> res = apply(func, params)
PvO> File "C:\APPS\GIMP\plug-ins\sphere.py", line 47, in python_sphere
PvO> pdb.gimp_edit_fill(drawable)
PvO> TypeError: wrong number of parameters
There are a few calls to gimp.edit_fill in the scripts that need an
additional parameter (BG_IMAGE_FILL).
However, the script then still do not produce any pixels. For example the
sphere script produces an empty image with some empty layers.
pi...@cs.uu.nl
PvO> However, the script then still do not produce any pixels. For example the
PvO> sphere script produces an empty image with some empty layers.
This was at my home system (Windows 95). However, on my work system
(Windows NT) it does work. As far as I know I have the same versions of
Python and GIMP on both systems, but I'll do soe more checks.
re...@news.group
Piet,
Could you be more specific on how you made it work? I don't
even get python-fu to show up in the extensions menu. What versions
are you running (Gimp, Python, and pygimp)? Where did you download
from? What files did you copy and where did you place them? Did you
modify any files, like rc files?
On the broader topic, I see that script-fu has an executable
in the plug-in directory. Should there be a Python-fu executable
there also?
Still dreaming,
Bill
>I did this also and it worked after rebooting. Worked meaning I got the
>python-fu menu entries.
>
>There were a few problems, however:
>1. At startup the python console comes up, and it hangs the Gimp until you
> close the console, after which the Gimp continues loading the plugins.
> It displays this message in the Command prompt window:
>** WARNING **: wire_read: unexpected EOF (plug-in crashed?)
> I think the console shoulnd't become active at load time, only when it is
> requested.
>
>2. The scripts seem to have some problems. For example, the sphere script
> gives this message in the Command prompt window:
>
>Traceback (innermost last):
> File "C:\APPS\PYTHON\GTK\gimpfu.py", line 410, in _run
> res = apply(func, params)
> File "C:\APPS\GIMP\plug-ins\sphere.py", line 47, in python_sphere
> pdb.gimp_edit_fill(drawable)
>TypeError: wrong number of parameters
>
>
pi...@cs.uu.nl
R> Piet,
R> Could you be more specific on how you made it work? I don't
R> even get python-fu to show up in the extensions menu. What versions
R> are you running (Gimp, Python, and pygimp)? Where did you download
R> from? What files did you copy and where did you place them? Did you
R> modify any files, like rc files?
I have the standard 1.5.2 distribution of Python (with the install .exe).
On Windows 95 I added this line to autoexec.bat:
SET PATHEXT=.py;.pyw
You have to reboot to make this effective.
On Windows NT I already had these in the PATHEXT environment variable (set
by My Computer->Properties->Environment).
I didn't like to add the gtk files to the Python\LIB directory so
I added a subdirectory GTK to my Python directory, and added a file GTP.pth
in the Python directory, containg the text GTK. This effectively adds the
GTK subdirectory to python's search path.
I downloaded these files:
http://hans.breuer.org/ports/pygimp-2000-04-04.zip> and
http://hans.breuer.org/ports/pygtk-2000-04-04.zip>.
I unzipped them in a temp directory, then moved the *.py and .pyd files from
pygtk-2000-04-04.zip to the GTK subdir.
Also the gtkcons.py from pygimp-2000-04-04.zip in the plug-ins directory I
moved to GTK. The rest of the plug-ins directory from that zip file I moved
to the GIMP plug-ins directory.
Finally I changed all the gimp.edit_fill calls in the plug-ins\*.py file by
adding an additional parameter BG_IMAGE_FILL.
I could also add that I changed the extensions of the plug-ins\*.py files
to .pyw to get rid of the command prompt window that pops up. This also
means, however, that you don't see any stack traces in case of an error.
I think the gimpfu.py file should add a try/except and display the
tracebach in a separate window to make it nicer.
R> On the broader topic, I see that script-fu has an executable
R> in the plug-in directory. Should there be a Python-fu executable
R> there also?
No. With script-fu there is one exectutable, that loads the scripts.
Therefore the scripts are in a separate directory, and the script-fu.exe is
in plug-ins.
With python-fu, the .py files are in the plug-ins directory so they are
considered as executables by the Gimp. The .py entry in PATHEXT is
necessary, however, for the Gimp to recognoze them as executables. And
somewhere in the registry the association of .py->python.exe (and
.pyw->pythonw.exe if you use .pyw files) has to be present. This is done by
the standard python installation procedure, and is also used to start
python/pythonw when you double-click on a .py file.
re...@news.group
>I unzipped them in a temp directory, then moved the *.py and .pyd files from
>pygtk-2000-04-04.zip to the GTK subdir.
>Also the gtkcons.py from pygimp-2000-04-04.zip in the plug-ins directory I
>moved to GTK. The rest of the plug-ins directory from that zip file I moved
>to the GIMP plug-ins directory.
>
>Finally I changed all the gimp.edit_fill calls in the plug-ins\*.py file by
>adding an additional parameter BG_IMAGE_FILL.
>
>I could also add that I changed the extensions of the plug-ins\*.py files
>to .pyw to get rid of the command prompt window that pops up. This also
>means, however, that you don't see any stack traces in case of an error.
>I think the gimpfu.py file should add a try/except and display the
>tracebach in a separate window to make it nicer.
Thanks, Piet, Python-fu is working fine now. My biggest problem turned
out to be the installation directories for Gimp and Python. While
regular .py files handled Win32 paths, apparently one of the scripts
does not, and choked when I put Gimp and Python under the 'Program
Files' directory. Removing them and placing them in the root
directory solved my problem.
Bill
Piet van Oostrum
R> Thanks, Piet, Python-fu is working fine now. My biggest problem turned
R> out to be the installation directories for Gimp and Python. While
R> regular .py files handled Win32 paths, apparently one of the scripts
R> does not, and choked when I put Gimp and Python under the 'Program
R> Files' directory. Removing them and placing them in the root
R> directory solved my problem.
It's probably the space in the filename. Using a different directory (I put
boths Python and Gimp under c:\APPS) probably suffices.
By the way, do your scripts produce correct results on Windows 95?
Piet van Oostrum
Windows 95. The problems were:
1. The scripts didn't produce the correct results. For example the sphere
script produced an empty image, the clothify scripts generated something
that vaguely resembled a rotten cloth but nothing like the script-fu.
The foggify did nothing. Strangely enough they did work on my Windows NT
system at work.
It took a lot of debugging to find this one. It appeared that
gimp.edit_fill and gimp.bucket_fill didn't have any effect if the
parameters to the python_fu procedure were interactively specified.
Calling the function from the console, or repeating a filter with ALT-F
did produce correct results, however.
I finally found that the combination of "import gtk" in the function
_interact in gimpfu.py and the call _gtk.gtk_set_locale() in gtk.py is
the cause. Either commenting out _gtk.gtk_set_locale() or moving the
"import gtk" to the module level solved the problem. I don't know what
the real cause is, but apparently calling the _gtk.gtk_set_locale() in
the middle of the _interact function puts the gimp in a strange state.
2. The Extension menu items (Toolbox) sometimes were greyed out. This is
caused by the image type entries in the register calls containing
something other than an empty string. In this case the items most of the
time get greyed when the last image is removed (e.g. after startup
create a sphere and then delete it) and the get back when you load an
image. The solution is to always specify this parameter for <Toolbox>
menus as "", no "RGB*" or "*" or similar. In fact I think this parameter
should be ignored for toolbox items.
And by the way, it would be nice if gimpfu.py would put a try/except around
the apply(func, params) call to intercept exceptions and show them in a
dialog box.
Nick Lamb
> It took a lot of debugging to find this one. It appeared that
> gimp.edit_fill and gimp.bucket_fill didn't have any effect if the
> parameters to the python_fu procedure were interactively specified.
> Calling the function from the console, or repeating a filter with ALT-F
> did produce correct results, however.
> I finally found that the combination of "import gtk" in the function
> _interact in gimpfu.py and the call _gtk.gtk_set_locale() in gtk.py is
> the cause. Either commenting out _gtk.gtk_set_locale() or moving the
> "import gtk" to the module level solved the problem. I don't know what
> the real cause is, but apparently calling the _gtk.gtk_set_locale() in
> the middle of the _interact function puts the gimp in a strange state.
gtk_set_locale() completely screws up Gimp's wire protocol with regard
to floating point numbers if your system is set up for e.g. German or
other European behaviour (like 1,5L instead of American 1.5L)
Your plugin says set value to "34,76" and the Gimp expects "34.76"
and so now the results are... interesting.
GTK+ should not be initialised in this way while talking to Gimp,
either do it earlier (before Gimp puts locale back) or not at all. The
author of this code should be contacted about this, he can mail me
directly or on the gimp-devel list if he needs more info.
Nick.
mathm...@my-deja.com
Following up on a previous posting, I am still trying to install GIMP
v1.1.24 with the perl plug-ins included. As previously mentioned, I
went to hell and back trying to compile the source - so now I am trying
the approach of installing an RPM instead.
So, I have located an RPM which contains the perl plug-ins (I downloaded
about three different GIMP v1.1.24 RPM packages, and I noted with
interest that they don't all have the same files - some are missing the
perl components).
However, I am still having problems (mainly it seems I am unable to
upgrade gtk and perl due to dependencies) and was wondering if I could
get some help to resolve this.
(1) When I attempted to install from this RPM (rpm -ivh
gimp-1.1.24-2.i686.rpm), I got the following errors :
"error: failed dependencies:
perl = 5.005_03 is needed by gimp-1.1.24-2
/usr/lib/perl5/site_perl/5.005/i686-pld-linux-thread is needed by
gimp-1.1.24-2
gtk+ >= 1.2.8 is needed by gimp-1.1.24-2
perl(Carp) is needed by gimp-1.1.24-2
perl(DynaLoader) is needed by gimp-1.1.24-2
perl(Exporter) is needed by gimp-1.1.24-2"
(etc.).....
(2) So, then I downloaded an RPM for gtk-1.2.8 and attempted to
upgrade as follows (rpm -Uvh gtk-1.2.8-24.i386.rpm), but got a long
string of errors similar to the following :
"file /usr/share/locale/ca/LC_MESSAGES/gtk+.mo from install of gtk-
1.2.8-24 conflicts with file from package gtk+-1.2.6-6mdk"
Note that I was unable to simply uninstall gtk-1.2.6 - when I did this
it gave me a long list of programs (dependencies) which required GTK.
(3) Finally, I downloaded a perl RPM package, and tried to upgrade it
(rpm -Uvh perl-5.005_03-172.i386.rpm), and got errors like the
following :
"package perl-5.00503-10mdk (which is newer then perl-5.005_03-172) is
already installed
file /usr/bin/perl from install of perl-5.005_03-172 conflicts with file
from package perl-base-5.00503-10mdk..."
If this is already installed why was I getting all of those perl-related
dependency errors when installing GIMP ?
Thanks in advance,
Andrew J Fortune
Sent via Deja.com http://www.deja.com/
Before you buy.
and...@mathman.org
Patricia Hawkins
2) Looks like you're missing some perl modules. Use cpan to get them
(type cpan at the command line, assuming your machine is connected to
the internet. Type help.) Also see www.cpan.org
--
Patricia J. Hawkins
Hawkins Internet Applications, LLC