Von: "lode leroy"

I'm trying to get pygimp to work on gimp-2.3.1 for windows/autotools. For some reason, the pygimp plugin seems not to be initialized.

That's the same problem I have...

Could someone sketch the mechanism by which pygimp is supposed to be loaded?

It is a python module (actually two of them), but even if you make sure that python should find them (either by a .pth file in python's Lib/site-packages directory or by copying it there, it doesn't work.

It looks like the pygimp.interp file is actually read and used: it complained that
/c/python24/python did not exist: I changed those to c:/python24/python.exe
and the error is gone now.

We should make sure that there are no absolute paths in this file - and pythonw.exe might be a better option than python.exe, since this opens a console windows.

I added a print statement to plug-ins/pygimp/gimpmodule.c:initgimp() and that looks like it's not called...

Does anyone know who'se supposed to call that function... assuming that that is the entrypoint into the pygimp module of course...

If you build the module with Python's distutils package (basically an autotools replacement, but you need a custom "makefile"), it works. I can provide the build logs for this, the flags given to gcc and ld differ between the autotools and distutils build, maybe the truth is in there...

It would help if you could join the GIMP irc channel this evening, irc://irc.gimp.org/#gimp

I'm usually there each day, from 18:00 UTC to about 22:00 UTC

HTH, Michael

Von: "lode leroy"

I meant the following:
Gimp must somehow load the module pygimp, which loads libpython, which loads the python scripts.

pygimp is a python module. GIMP exectues the python plug-ins, which are run by python (remember the .interp file?).

You can even check the module without GIMP, just start python and try

import gimp

I suspect the that the module mechanism is not picking up the pygimp module.

Python's module mechanism doesn't recognize the dll files as a python module. Once you solve this (e.g. add or remove the compiler or linker flag that makes it work or break resp.), it should work.

Could you also verify that you are in fact running gimp-2.3.1 and that pygimp is actually compiled from the sources inside gimp-2.3.1...

I'm running GIMP HEAD (a lot more recent than 2.3.1) and gimp-2-2 (a bit more recent than 2.2.7).

HTH,
Michael

Von: "lode leroy"

Aha! So I edited the Makefile, to add the missing path. and now alt least I have a dll, although its called 'gimpmodule.dll'... suppose I can just rename that to gimp.dll...

Didn't get a pth file from autotools... So what am I supposed to do now?

Write one yourself. This is something that should be done by the gimp installer.

Do I simply put the dll in site-packages?

Hmm... that seems to have worked!

"make install" should be convinced to do this for me :-)

[or is this what the pth is about? do I need it to tell that gimp is in gimpmodule.dll?]

pth files include additional paths for python to look for modules. Copying the DLLs to site-packages is another way to do this.

Gimp now loads the .py files and now they complain about gimpfu module and no longer about the gimp module !!!

Ah, I needed to modify environ/pygimp.env

Good. Now it's the _gimpenums module... hmm... there is no dll for this one either...

The only difference I see is that Makefile.am seems to be missing $(no_undefined) for _gimpenumsmodule.

Maybe this was the problem...

Ah. got the dll now!
Same for gimpcolormodule...

damn. Now I get "undefined reference to `gimp_rgba_parse_css'" and it is missing from 'gimpcolor.def"

This is a problem in GIMP itself then, the function has to be added to the def file.

$ for f in /target/lib/gimp/2.0/python/*module.dll; do cp $f ${f/module/}; done

Ah, now it starts up, and the "Python-fu" is there... yippee!

Did I get this right - Python is picky about the name of the module files?

And now lets hope some autotools-wizard can deduce from this mail what needs
to change...

Some -o adjustements, adding the no-undefined ...

The detection of python on msys is not too good: $ python -c 'import sys; print sys.exec_prefix' c:\Python24

which needs to be
c:/Python24

I have these in my CPPFLAGS and LDFLAGS, so the headers etc... get found

Great work! Seems like we will finally have pygimp 2.4 for GIMP 2.4 on each of the officially supported platforms. Hm, how about letting Script-Fu/Tiny-Fu die in favor of it? ;)

Michael

On Fri, 24 Jun 2005, Michael Schumacher wrote:

Great work! Seems like we will finally have pygimp 2.4 for GIMP 2.4 on each of the officially supported platforms. Hm, how about letting Script-Fu/Tiny-Fu die in favor of it? ;)

The best thing about Script-Fu has been knowing it would be available and included in the 'default install'. Many existing scripts are written in Script-Fu and as you know we still regularly get users asking how to get and old script to work with the current version.

From a technical standpoint it is great that Python and Perl subsystems

are well achitectured and entirely seperable but the failure of distributors to include them in the 'default install' or even bother to build them has dicouraged people from using them. Making it possible to leave things out is different from it being a good idea to leave things out and I do not think users are given the best impression of the GIMP because to the ordinary user if it is not installed it may as well not exists.

My point is Script-Fu remains useful despite it's flaws and I am concerned by the potential side-effects of killing it off.

Better go and improve my python skills...

- Alan H.

On 6/24/05, Alan Horkan wrote:

On Fri, 24 Jun 2005, Michael Schumacher wrote:

Great work! Seems like we will finally have pygimp 2.4 for GIMP 2.4 on each of the officially supported platforms. Hm, how about letting Script-Fu/Tiny-Fu die in favor of it? ;)

The best thing about Script-Fu has been knowing it would be available and included in the 'default install'. Many existing scripts are written in Script-Fu and as you know we still regularly get users asking how to get and old script to work with the current version.

From a technical standpoint it is great that Python and Perl subsystems

are well achitectured and entirely seperable but the failure of distributors to include them in the 'default install' or even bother to build them has dicouraged people from using them. Making it possible to leave things out is different from it being a good idea to leave things out and I do not think users are given the best impression of the GIMP because to the ordinary user if it is not installed it may as well not exists.

My point is Script-Fu remains useful despite it's flaws and I am concerned by the potential side-effects of killing it off.

Agreed! There is great value in having a scripting interface that is guaranteed to be present in any gimp installation. Regardless of how hard we implore, people are quite simply not going to universally include script-fu in their gimp packages if we package it separately ourselves. That is human nature. While I think it would be great to replace script-fu with tiny-fu, it would be a big mistake to ship a gimp tarball that doesn't include either.

Rockwalrus

lode leroy wrote:

Ah, now it starts up, and the "Python-fu" is there... yippee!

It should do so now out of the box, at least in current CVS... maybe except for the interp file, but we should be able to fix this today.

And now lets hope some autotools-wizard can deduce from this mail what needs to change...

This has been done yesterday by yosh and me. I have to say that I'm surprised that it did work for you, as we had to change the gimpinterpreterdb.c file in order to make it work...

Nevertheless, your mail provided some important hints that helped to finally get pygimp part of the regular win32 build of GIMP. So starting with GIMP 2.4, we will have Python as an additional scripting language - one that can probably considered to be more "standard" than Scheme.

Thanks again for your input!

If you want to continue to work on scripting, and get even more scripting languages to GIMP on the windows plattform, there is gimp-perl, some java classes, a ruby binding and iirc even something for Tcl... :)

Michael

On Sunday 26 June 2005 11:19, Michael Schumacher wrote:

lode leroy wrote:

Ah, now it starts up, and the "Python-fu" is there... yippee!

It should do so now out of the box, at least in current CVS... maybe except for the interp file, but we should be able to fix this today.

Hooooooooooooorrrrrraaaaaaaaaayyyyyy!!! :-)

(...)
Thanks again for your input!

If you want to continue to work on scripting, and get even more scripting languages to GIMP on the windows plattform, there is gimp-perl, some java classes, a ruby binding and iirc even something for Tcl... :)

And there was the guy asking for a Lua interpreter, and I rememeber someone was working on GIMP-C#

Michael

Joao S. O. Bueno Calligaris wrote:

On Sunday 26 June 2005 11:19, Michael Schumacher wrote:

If you want to continue to work on scripting, and get even more scripting languages to GIMP on the windows plattform, there is gimp-perl, some java classes, a ruby binding and iirc even something for Tcl... :)

And there was the guy asking for a Lua interpreter, and I rememeber someone was working on GIMP-C#

Gimp# is actively maintained: http://sourceforge.net/projects/gimp-sharp/

The Lua interpreter is handled in this bug report: http://bugzilla.gnome.org/show_bug.cgi?id=171831 Apparently, there is already some code, see comment #12 - yes, I know that's my comment, but I don't have the code.

HTH, Michael