For most of the last 24 hours I have been struggling to find two bugs, which occurred in each of 3 scripts. I finally tumbled to something I found quite unusual. The GIMPs version of Python changes it's mind about what is true or false, depending on how a plugin is called!

If, for example, You have a plugin which takes a PF_BOOL input, and You activate by clicking on it's menu button, then the parameters are passed to it as actual boolean values. But if it is called from within another script, the parameters arrive as integers (1 and 0).

The same is true for PF_TOGGLE. PF_INT, and it's kin, can only pass numeric data, but if You use an int as a parameter for a call to a plugin requiring a bool, it is silently accepted.

Now most languages use integers for booleans in some way or another, but the problem here is the values don't always work! It took me many hours to realize that my code wasn't flawed, my parameters were not being interperated in a consistent manner.

My communication skills suck unless You want a boring three hour paper on this, so here is a sample instead. The attached plugin contains 7 very simple scripts. 1 and 2 use booleans only, A and B use values only, and the final three are proof of concepts for a work around I found that solves the problem.
The scripts install to a new menu on ypour main menu bar, called Demo. For cases 1,2,A, and B the first of the two options works as expected, but the second fails to work right. For the final three, the working one is the bottom option, the other two work because of a "hack" in the code.
Dang! Just remembered, the buttons for the color switch are all reversed! (Expected after almost 24 hours at this though I guess.)

So to all of the True Gimp Gods, and Python Deities around here I ask this. I assume something this major is a known issue. But I cannot seem to find a bug report for it anywhere. Perhaps one of You can find one? And if not please let me know and I'll fire one off.

Jazzon,
you wrote: " For cases 1,2,A, and B the first of the two options works as expected, but the second fails to work right"
In effects, I tried your script #1 and something failed.
Then, because I'm simple-minded, I rewrote your #1 in my own simple python style.
Here it is:



it seems to work both with Yes and No.
Did I miss something from your comments?

also:
created a version 2 which passes 1 or 0 instead of True and False.
It works the same.

It is not a GIMP bug. It is a "feature" of the Python programming language.

That part I understand. In most Python code I have written True or 1 and False, 0, or -1 work as expected. But unless I am way off base here, all 7 of the scripts I originally attached should get the same results. The calls are identical, but the results are not. The only difference is one is called interactively, and one non-interactivly. (I only coded one example variant for each, not all of the possibilities.)

So why then does this fail?
That is what started me digging into this.


dinasset Simple Minded? HA! I've seen Your work! I'll never believe that.

No You are hitting the nail on the head actually. The point I am trying to illustrate is the fact that unless I am seriously off in my understanding of something, all 7 of my scripts SHOULD WORK SYSTEM AGNOSTICALLY, but on my machine 1, A, and Work all work flawlessly. But on Yours 1 failed. Why? To my knowledge I have nothing installed which alters Python's or The GIMP's handling of it's parameters, or considering of Truth.

Python is from standard repositories for Linux Mint (granted that means a binary build and I do not know of modifications with out a lot of research on the issue), and ditto for The GIMP. No scripts or plugins that alter anything as far as I know. So why do they work on my end and not yours? That very question is the heart of what I was getting at ... There is no consistant handling of Truth and parameters AT RUN TIME.

Unless I am missing something, all 7 of these should succeed, but when I run it on my machine I get the following results:

Script 1: Changes to black or white;
Script 2: Changes from white to black, but will not under any circumstances change it to white.
Script A: Changes to black or white;
Script B: Again can change to black, but not to white.
Script Works: Changes to black or top white
Script int: Changes to black or to white
Script bool: Changes to black or to white.

But all 7 scripts are valid and should achieve the same successful results. Bu they do not. Something different between our machines altered Your results as compared to mine (or mine compared to Yours, same thing really).

Slightly off topic:
As for the difference in code (Yours to mine), I simply used PyGimps class interface to the drawable, while You are using PyGimp's pdb interface. They both do the same thing, just different means of accessing them (great thing about Python). Some time ago (well over a year since I found the article was I think for The GIMP 2.4 or maybe 2.6) I read that the class interface methods ran quicker. The same article also posted some stats on the run times. The differences exist, but if I recall, are not huge. Anyway, I try to use the class interface because of what I read. They are both the same thing.

I am not trying to criticise here, or in any of my other posts, Your code is great! Just style differences between You and I, and most people don't like my style anyway. ( I tend to try to super simplify things, and in the end result I often over complicate matters. If that makes any sense.)

I'm still having problems in reading your source (because of the interrelated definitions/registrations), hence my simple question:
- is your problem that when "called" the function doesn't work properly neither with True/False nor with 1/0? (while used directly work)
If so: did you try my simpler derived versions? They both "call" the function (even if the function is defined internally as an ancillary function, and not as a registerd one), one is using True/False the other one 1/0. Do they work properly in your system?

dinasset: Look at the sample code I posted as a response to saulgoode. All it does it create a pdb method. The second simply calls the first one, passing the values in as they were received. The second one fails, and it shouldn't.

Sorry about the crappy code. I had been up for almost 40 hours when I wrote it, and it was after hours of testing that concept various ways. The code I posted to saulgoode should have been my first example.

The function accepts one paramater True or false, and uses gimp_message to display the result. That function works. A second function takes one parameter, True or False. It then calls the first function using the same unmodified parameter. It fails. It interprets True as False. ( at least on my machine ... I need others to test it so I can find out if I have a problem, gimp does, or python does, or Linux Mint maintainers do ...)

Since (like Dinasset) I am unable to replicate your successes, here is the short version of the solution:

Wow, I must have really been unclear. The problem isn't how to code this. The problem is it's broken.

Take this example:
A plugin takes only one parameter, a boolean value.
It uses pdb.gimp_message to display "recienved XXX" (Where xxx is a string true or false)
call the plugin from the menu.
supply true
plugin prints out "Received True"
supply False
plugin prints out "Received False"

Second plugin is written
It takes one parameter, a boolean true or false
this plugin calls the first one and hands over the unmodified parameter
first plugin prints result

run second plugin from it's menu
Supply False
Plugin prints "Recieved False"
Supply True
Plugin prints out "Received False" Even when both plugins are using the python keywords "True" and "False"

This reproducible at a 100% frequency on my machine, using the code I posted as a reply to saulgoode. The parameter passed by plugin 2, to plug in 1 is never even looked at by plugin 2. How was it changed? The code (uses the python keywords "True" and "False", nothing else.

A plugin ()exactly as I just described) is attached. The code minus registration bits, is this:

Jazzon,
to check whether the problem has to do with your system, please unzip the attached folder and set it visible to your gimp plug-in (preferences).
These 2 filters have been written following your indication:
- idiosync is the "doer", id est: it prints and executes the received order, both if called directly from the menu as well as if called by the second one below
- idiosync_call simply calls the above idiosync passing the parameters as received

They work on my PC.

The plugin prints out "Received True" because that is what your print statement tells it to print. I submit that the value that is actually received is an integer "1".

dinasset
You hit the nail on the head, but I'm not sure if You caught it.

Aside from syntactic sugar, the only difference between Your code and the Code I posted is the equality test.



In Python "True" and "False" are identities. The identity comparison operators are "is" and "is not", not "==".

This is a guarantee of the python programming language, and all implementations of Python are (as far as I can recall) required to utilize it. This is also reiterated in the Python PEP documents.

The test which I uploaded in post 9 is identical to Yours in 10 except for the "is" vs "==".

This is where the problem comes in. Coders coming into gimp who are fluent in Python know to use "is" in their boolean comparisons, and the ending result is code will fail. In fact, since the coding skill level of each author of a plugin cannot be known by the end user of the plugin, many will assume the plugins are just broke, or don't work as advertised, or do I as I did last night and spend many hours trying to figure out why my calling routine was failing. My syntax was correct, the result was not. Now that I know The GIMPS internal Python is not up to the standards of Python.org, I can code around it, but has this bug been reported? Is it known?

saulgoode
You posted as I was writing that last one. The code I uploaded printed out "Recieved True" on Your machine? If that is the case something is wonky with My python or Yours, or my understanding of identity tests ...

I concur, it received an int type, but it was sent a bool type. Therein lies the issue. SOmehow the type is being changed between caller and receiver, thus standard truth tests (like: x is True) can fail.

The code I uploaded in post 9 fails 100% of every input of "True" to the second plugin on my machine.

I modified the code slightly and ran gimp in command line as

the following is a copy paste of my terminal window:

first are three runs of dinassets code
second are three runs of my first plugin
then five from my second plugin

I used three in case the issue was actually the script being called by error with a "use last values" setting.
Only a few things can be happening here:
1. PyGimp isn't working right
2. gimpfu is altering something on the fly
3. My Python is fouled up
4. My GIMP is fouled up.
5. (In which case it is not a bug) Gimp is using a different instance of python for each script for some reason.

Further modifying the code (attached and posted below), Another run with the same command line parameters:


As You can see, the sent values are true boolean values, but the values received are not, when the plugin is called from another plugin.
This indicates that either gimpfu or pygimp has an issue. (Or GIMP is using separate instances of pygimp for each script)

Post of the source code minus the registration part:


Since I have included both sources in one file, I (not posted here) also tried calling the code directly as a function, it works as it shoult that way.

Once more modifying the code (final runs) I got this in the terminal for two tests of plugin one, and two tests of plugin two.(notice final entry) (I added some spacing for clarity):

This is by design. There is no <type bool> in the PDB interface -- all Python True/False identities need to be supplied as values that the PDB understands (namely INT32). This mapping from True to "1" and False to "0" should be performed automatically by Pygimp.

saulgoode That makes perfect sense. It's an issue between the interface to GIMP and Python. C Doesn't have a natural boolean type.

To All of You Thank You all for bearing with my idiosyncrasies and poor communication skills, and helping me to understand this. I know I can be difficult to understand, and sometimes to dense to get what others feel is an obvious point. Your persistence truly is appreciated.


-- Jazzon

True/False are Python concepts. The PDB has to deal with every possible implementation of your callee: script-fu, perl-fu, C plugins... When you call a Python script through the PDB, your booleans become integers.

Despite all the Python code I have written for Gimp, this has never bothered me:) To dodge the problem I would use either:

(if inSwitch is anything but false or 0, bool(inSwitch) will be true, which as an array index is 1. Otherwise it is False, which is index 0).

Or the even more pythonic way is to use the ternary operator:

ofnuts
I know that now. I think the only reason I even stumbled on this is because the ide I use for python coding has the ability to auto adjust things in the code as You write it. I have it set up to "notice" == True and ==False, and auto replace them with is True and is False. When I was working on the wiremap scripts, I copy pasted pieces of dinasset's code which included these lines (I looked at His originals and He used the == form, but now they show the is form) and it corrected the code when I pasted it. Thus when I wrote the auto-collapsing variants, certain features got "broke". Which got reported to me as bugs. I simply have to shut that feature off, and use the less exact comparator of ==.

On a side note, check Your PMs. I've been trying to email You for days now, and keep getting the same error.

The right thing to do is to use neither "==" nor "is". Just use the boolean:

and to check the opposite:

remember that in Python, many things are equivalent (but not equal) to True/False in tests: empty lists, empty strings, None...

ofnuts: I guess I would have to agree with the "no comparator" solution. Im just gonna have to unlearn some old habits now that I understand this issue.