thanks.I have installed the Guido,and it can work in JAVA mode.there is no error in python mode ,you can paste the code to the processing and run it .I thought python mode run on jython , it should work well just as on java
For some java libraries I believe that it is an interface issue – libraries that modify fields ( and some forms of callbacks and reflection, I think?) aren’t correctly exposed from jython to the mode due to the architecture. See the FAQ for some discussion.
Some libraries such as Ani require you to specify a variable name for animation. Unfortunately they cannot access Python variables directly (and Java’s built in classes are immutable). To solve this problem we instead create a mutable PrimitiveFloat object. This object has a field .value , which you can use for these purposes. GitHub - jdf/processing.py: Write Processing sketches in Python
and the wiki
Some libraries–those that depend on certain functions being defined in your sketch–will not work. As we become aware of those, we will try to work with the authors of those libraries to make the design compatible with Python Mode, or at least to provide workarounds. GitHub - jdf/processing.py: Write Processing sketches in Python
For such libraries, see whether they offer an alternative way to pass a custom callback (generally an instance of some functional interface provided by the library) besides those callbacks directly defined in the PApplet sketch.
I checked the Guido GitHub repo. It includes some python-mode examples, but these don’t seem to work either.
If you’re simply looking for a GUI library with decent Processing.py support, you may want to try ControlP5. If you’re interested, I’ve written a tutorial on using ControlP5.
Looking at the commit dates, an issue might be that Guido (and the examples) are for PDE 2.x and/or an earlier version of Python mode. So one thing you could try is running Guido and those examples with a Python mode release from 2014…
After some gander at Guido repo, seems like all of its Python examples and workarounds had never been released nor tagged for years!
All the Python Mode examples linked by @tabreturn:
Relies on an Interactive.make() overloaded signature w/ 2 args: Interactive.make(this, True):
However, that overloaded static method version exists on ‘master’ only, nowhere else!
So even today, only the Interactive.make() w/ 1 parameter is available.
However, w/o it, we have to close Python Mode completely before each re-run!
But fret not! Now that Python Mode allows directly access to any Java member, regardless its access permission, we can simply assign None to Interactive.manager before calling Interactive.make():
It forces Interactive.make() to always instantiate a newInteractive rather than reusing an existing 1, which is unfortunately buggy on Python Mode.
There are more problems when using Guido on Python Mode though. Interactive.add() doesn’t work on Python classes.
Instead, we need to create a class which inherits from ActiveElement:
# ActiveElement inheritance replaces Interactive.add(Object):
class SimpleButton(ActiveElement):
W8! There’s 1 more bug! Which was fixed on ‘master’, but it’s unavailable for us:
Callback ActiveElement::mousePressed() is invoked 2 times!
1st as signature ActiveElement::mousePressed() w/ no parameters.
2nd as signature ActiveElement::mousePressed(float, float), which receives mouse’s current coordinates.
As you can see, all empty callbacks were commented on ‘master’ version.
But they’re very active on the distributed version we use currently.
Java, due to its native overloading dispatch, can pick which 1 to use.
But in Python, we’ve gotta def a callback which accepts all overloaded signatures coming at it!
# *args for both signatures ActiveElement::mousePressed() &
# ActiveElement::mousePressed(float, float):
def mousePressed(self, *args):
And b/c it’s called back twice, we need to check which version it was, so we don’t toggle self.on twice as well:
# Only toggles when overloaded callback signature isn't
# ActiveElement::mousePressed():
if args: self.on ^= True
print args, self.on
I believe that’s all for now. As you can see, I’ve fixed the button example, not the slider 1, b/c that’s the 1 I was studying while trying to peruse the Guido source:
"""
Simple Button (Guido)
ported from Java to Python by fjenett (2014-May-25)
fix & mod for old Guido by GoToLoop (2019-Mar-30)
Discourse.Processing.org/t/guido-cannot-work-in-python-mode/9501/10
GitHub.com/fjenett/Guido/blob/master/examples/mode-python/button/button.pyde
"""
add_library('Guido')
def setup():
size(400, 400)
# Workaround for missing overloaded Interactive.make(PApplet, boolean):
print Interactive.manager
Interactive.manager = None
Interactive.make(this)
dim = SimpleButton.DIM
d = (width - dim) / dim
dd = d << 1
for y in range(dim, height - d, dd):
for x in range(dim, width - d, dd):
SimpleButton(x, y, d, d)
def draw(): clear()
# ActiveElement inheritance replaces Interactive.add(Object):
class SimpleButton(ActiveElement):
DIM, ON, OFF, OUTLINE = 20, 200, 100, -1
def __init__(self, x, y, w, h):
super(SimpleButton, self).__init__(x, y, w, h)
self.on = False
# Variant param *args for both sigs ActiveElement::mousePressed() &
# ActiveElement::mousePressed(float, float):
def mousePressed(self, *args):
# Only toggles when overloaded callback signature isn't
# ActiveElement::mousePressed():
if args: self.on ^= True
print args, self.on
def draw(self):
stroke(self.OUTLINE) if self.hover else noStroke()
fill(self.ON if self.on else self.OFF)
rect(self.x, self.y, self.width, self.height)
