If you'd like to upload plug-ins, please create an account below. Otherwise (e.g. for download or commenting) you do not need one! Enjoy :-)
User login
Syndicate
Gimp Progress Bar in Python
August 19, 2008 - 18:24 — kvrijt
All,
I'm having some trouble with progress bars in Python.
When I initialize a progress bar in a separate window for a plugin in TinyScheme as follows it works like a dream.
> (gimp-progress-init "Processing" -1)
(#t)
When I try to do the same in Python however I get the following error.
>>> pdb.gimp_progress_init ("Processing...",-1)
Traceback (most recent call last):
File "", line 1, in
TypeError: wrong parameter type
>>>
Does anyone know what's going on here?
- Log in or create a user account to post comments
Maybe this will help
I found this by mistake, initializing a display that does not exist (-1) does not work, instead: just use it :
def pogress( disp, lay ):
... for i in xrange(0,101):
... ... pdb.gimp_layer_set_opacity(lay, i)
... ... pdb.gimp_progress_update(i*0.01)
... pdb.gimp_progress_end()
...
takes a display and a layer to change the opacity of and shows the progress.
yeah, real efficcient - i know ;)
if you want it to be in the display, you should use the progress-init.
You can even deside wether you want the progress to be shown or not:
def pogress(lay, disp = None):
... if disp != None :
... ... pdb.gimp_progress_init("processing", disp)
... for i in xrange(0,101):
... ... pdb.gimp_layer_set_opacity(lay, i)
... ... pdb.gimp_progress_update(i*0.01)
... pdb.gimp_progress_end()
...
calling pogress(layer) will change the opacity, but not show it in the display, rather a seperate window,
calling pogress(layer,display) will show the progress bar in the display "display"
Tested with:
Gimp 2.4.6 Python Console
Python 2.5.2 (r252:60911, Nov 23 2008, 17:36:17)
[GCC 4.1.2 (Gentoo 4.1.2)]
P.S.
Yes i know it is spelled "progress" let's just say it was to avoid name confusion ;)
Doesn't that function only
Doesn't that function only take one parameter? See:
http://developer.gimp.org/api/2.0/libgimp/libgimp-gimpprogress.html#gimp...
Me, I'm getting the same error message on another function, I'm wondering who is doing the type checking, I'm guessing it the python module for gimp, by querying the pdb for types of parameters.
plashless, off banks of noon
Values like -1 do usually
Values like -1 do usually indicate 'undefined' (on purpose, that is) values. Python has got 'None' for this purpose.
extra parameters in Python vs Scheme scripts calling Gimp
The gimp function is defined with one formal parameter.
If you call it with two actual parameters in Scheme, I think that the extra parameter (in this case -1) would not be evaluated, and you would not get an error message saying that the actual parameter count is more than the formal parameter count. Scheme uses lazy evaluation, it doesn't evaluate (execute or parse, loosely) until required. Since the function definition doesn't refer to a second parameter, any actual second parameter never gets evaluated.)
Python also has a mechanism for passing a varying number of parameters, and often you might pass None for a parameter you are not using. (Or I think you can just omit the extra parameters that are a suffix of the parameters. This is from memory, please check me.) But it is moot in this case since the gimp function is not defined to allow a varying count of parameters, only one in this case of gimp_progress().
In this case I think it is not Gimp or the Python interpreter that is comparing the formal to actual parameters, it is the PyGimp module. The PyGimp module is checking the type and count of actual parameters in a call to a gimp pdb function against the formal parameters defined in the pdb (the database that holds a copy of the definitions of gimp functions.) It is the PyGimp module that is raising the error when you pass a parameter that is not defined. The PyGimp module and the pdb form a layer between a script and the Gimp core.
Personally, I prefer Python exactly for the reason that it does more error checking (a typed language.) Among other reasons.
But the switch to Python may entail some fixes to plugins. The resynthesizer plugin defines its seventh parameter loosely as a GINT but more precisely it is a GLAYER. PyGimp objects if you pass a GLAYER so until the plugin is fixed, you can't call it from Python passing it a GLAYER (unless there is some workaround.)
plashless, off banks of noon