GNOME Bugzilla – Bug 784788
Inconsistency in the numeric type of a PF_SPINNER parameter
Last modified: 2018-05-24 18:14:39 UTC
Created attachment 355319 [details] Sample python script See attached test-types script. When called interactively (with the auto-generated parameter dialog), the script is called with "float" values (which is expected since the step can be fractional). However, the plugin browser documents the PF_SPINNER parameters as being of type INT32, and when the plugin is called by some other code via the PDB, "float" parameters are truncated and cast to the "int" type. Calling the script in the UI: Fractional spinner: 1.50 (<type 'float'>), Integer spinner: 3.00 (<type 'float'>) Using `pdb.python_fu_test_type(1.8,2.2)` Fractional spinner: 1.00 (<type 'int'>), Integer spinner: 2.00 (<type 'int'>)
Can you provide a patch for this? The fact that you can write a python script proves that you know more than I do :)
In plug-ins/pygimp/gimpfu.py there is a `_obj_mapping` dictionary that maps parameters types to Python types. The mapping for `PF_SPINNER` is `int`. This mapping is used in non-interactive mode (`_run` method). On the other hand, as far as I understand it, in interactive mode, gimpfu.py builds and displays the dialog, obtains the values for all widgets using their get_value() method and directly uses this to call the function that implements the plugin (function _interact, inner function response() that calls another inner function run_script()). And the gtk.Spinbutton returns a float. I'm pretty sure that in 2.6 times, the PF_SPINNER passed an int value to the plugin (I had to fix a bunch of scripts). But `git log` doesn't show any changes for this in gimpfu.py, so we would have to ascribe this to some change in the pygtk library (possibly related to the change from Python 2.6 to 2.7 between Gimp 2.6 and 2.8). But when I retrieve thr pygtk docs from the Wayback Machine, the vlaue seems to have always been a float... Now, the 64K question, should we fix to make PF_SPINNER to use integers (and break interactive use of recent scripts) or make it use floats (and break old scripts that call python plugins). IMHO the first solution is best...
Sorry; I meant the "float" option is best...
Ofnuts, would this really break stuff? Doesn't python promote stuff to float automatically? I admit i have no clue.
There is an automatic promotion but it also depends on how the code is written. For instance you can have a script that has: length=100/unaltered_value_from_PF_SPINNER If the spinner returns a float value of 3., the result is 33.333333.. while if the value is an int value of 3, the result is 33 (integer division assumed)(*). A second problem is that the PF_SPINNER now accepts fractional begin/end/step values (which may be why it returns float values). Going back to int would also be a functional regression. The only thing in favor of int is that some of the few Python scripts written for Gimp 2.6 would keep running unmodified in 2.8. But the int->float change in 2.8 broke a lot of scripts, so if they have not been updated yet they have very little use, and the fix is trivial. While the arguments in favor of float are: * plugins are mostly used interactively, so we can assume that the recently developed/maintained ones work OK with floats in interactive mode, and would also do if they are used as an API. While going back to int could break some in nasty ways. * some plugins could be using fractional values in PF_SPINNER and if we remove that this is a regression. (*) Note that in Python3 this changes and both would return 33.33333... integer division is no longer implicit and there is a specific operator for it (but Gimp 2.x uses Python 2.7).
OMG, whatever :) Can you provide a patch that turns things consistently into float? I was not aware we broke anything with 2.8, but if we did then it's done and we should go through with the int -> float change.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1151.