On 14/06/14 17:54, SeldomNeedy wrote:

Debugging register function for registration of a python plugin under Windows XP

Hey, all.

I've started writing plugins in Python for GIMP but have so far only been able to successfully register a plugin via the following form:

# in C:\Program Files\GIMP 2_8\lib\gimp\2.0\plug-ins # synch-current-frame.py

def synch_current_frame(*args): # code
return

register("synch_current_frame", N_("Adjust layers to the current animation-frame."), howTo,
"Needthistool",
"Needthistool",
"June 2014",
N_("_Synchronize Layers to Current Frame"), "",
[],
[],
synchronize_to_frame,
menu="/Layer/Stack",
domain=("gimp20-python", gimp.locale_directory) )
main()

Changing the leading category from "" to "" or "" seems to immediately break something and cause GIMP to skip over the script, as does adding tuples to describe parameters to the first list.

I'm aware that Linux users can see what errors are raised by register during startup but I'm not aware of how to do this with Windows. The Error Console and builtin Python shell seem only to display errors from plugins that are able to first load in correctly and show no record of what GIMP did while it was loading. After I'm past that, things are straight-forward, but at present I have no idea what I'm doing right or wrong as I register a function and currently have to "pass" parameters to plugins in some awkward ways, unable to achieve gimpfu registration with parameters. To avoid this, I need to debug the register function's registration, which happens at startup, where errors are hidden.

How do I avoid flying blind on Windows (XP) with GIMP 2.8.8?

Thanks, - Seldom

traceback (most recent call last): File "/home/me/.gimp-2.8/plug-ins/badone.py", line 7, in register("synch_current_frame", NameError: name 'register' is not defined

In practice you are missing "from gimpfu import *" at the beginning of the file.

Additionally, is deprecated (since at least Gimp 2.6). you should be putting your menu entry in "" (the window displaying the current image), or in "" (the right-click menu in the layers list), but the latter requires your plug-in to take image and drawable parameters.

Debugging Python plugins under Windows isn't too easy. I just made a small write-up on the subject:

http://gimpforums.com/thread-debugging-your-python-scripts-using-the-python-fu-console

On 15/06/14 23:45, SeldomNeedy wrote:

Obviously, normal fault-hunting can be done via gimp.pdb.message(someMessage) once a plugin is successfully registered. Windows/Dockable dialogs/Error console is obviously very helpful once an extension is up-and-running, HOWEVER I found registration fairly trying and had a number of problems getting this to work with basically no feedback about what I might be doing wrong. Ideally, getting started should be the easiest part of the process, not the hardest. Thanks for posting the guide. I'll definitely consider using that approach in future. I came across an alternative which you may consider adding (though I haven't compared the techniques for getting error-output so I don't know which one is better).

Anyways, for the reference of other users developing GIMP Pythonfu plugins under Windows, I'll repeat some information which I found very helpful when I was searching. At the very top of the .py file, it's can be useful to do something like:

import sys
sys.stderr = open("C:\\tmp\\errs.txt",'a')

This will cause the python environment to show some otherwise-hidden startup and register-registration errors by outputting / printing them to the specified location. The example I saw used mode 'a' to append errors, rather than overwrite. Doing this allowed me to spot a mistake I was making.

In addition, one can also do

import sys sys.stout = open("C:\\"tmp\\msgs.txt",'a')

if it's more convenient to receive output this way.

Additionally, Toolbox-prefix category is deprecated (since at least Gimp 2.6).

you

should be putting your menu entry in Image-prefix category (the window

displaying

the current image), or in Layers-prefix category (the right-click menu in the layers list), but the latter requires your plug-in to take image and drawable parameters.

Can you link to where this deprecation is publicly documented? The information available on GIMP Python-fu is often out-of-date and extremely disparate, I've found. Even http://www.gimp.org/docs/python/ is out of date in some respects, at least comparing it stylistically to some examples I've seen here and elsewhere. It would be helpful to know what calls are deprecated or now broken between versions so users will have some idea of whether they're looking at an outdated (and possibly broken or unreliable) way of doing things.

Your response also makes me wonder what of the other plugin-categories are (the ones that get specified in angle brackets) still work, and what their requirements are. An (outdated?) list of them I wrote down at some point went: "Toolbox", "Image", "Layers", "Channels", "Vectors", "Colormap", "Load", "Save", "Brushes", "Gradients", "Palettes", "Patterns" or "Buffers".

Thanks!

IIRC in 2.6 you got a "Location deprecated" message in the startup messages (but of course you see this on Linux only :)). Anything you put in actually went to . In 2.8 you don't get the message at all and the registration seems ignored.

Expect for (and, I think, and ) all others correspond the menu of the dockable dialog of the same name.

When the object is specific to an image (Layer/Channel/Path) the registered function should take an image as the first parameter, and the relevant object type as a second one. They are automatically filled with the image and the object on which you right-clicked). Other menus don't require any specific parameters.

On 15/06/14 23:45, SeldomNeedy wrote:

import sys
sys.stderr = open("C:\\tmp\\errs.txt",'a')

This will cause the python environment to show some otherwise-hidden startup and register-registration errors by outputting / printing them to the specified location. The example I saw used mode 'a' to append errors, rather than overwrite. Doing this allowed me to spot a mistake I was making.

In addition, one can also do

import sys sys.stout = open("C:\\"tmp\\msgs.txt",'a')

if it's more convenient to receive output this way.

Actually you can have both outputs to the same file:

|sys.stderr = open('C:/temp/python-fu-output.txt','a') sys.stdout=sys.stderr

And of course, when done you can keep the print instructions if you reroute everything to the bit-bucket: |
|import os
sys.stderr = open(os.path.devnull,'a')|