Color handling error in Python mode.

[tildebyte]

Mr. Feinberg was nice enough to allow designating hex colors like so when using the Processing Python mode[1]:

c1 = color(255, 0, 0, 100)
c2 = '#0000FF'
fill(lerpColor(c1, c2, .5))

Unfortunately, HYPE methods don't seem to like this:

rect1 = HRect(100)
rect1.fill('#FF6600')  # set fill color

yields

TypeError: fill(): 1st arg can't be coerced to int

I recognize that this might actually be uncovering a subtle bug or missing function in the Python mode, but I figured I'd try here first, as the error only occurs when using HYPE.

[1] '#' is the Python comment designator.

[tracerstar]

In Hype, HRect is an extension of HDrawable. Within HDrawable, the fill method accepts an int as it's color, or multiples of int i.e. (grey), (grey, alpha), (r, g, b), (r, g, b, alpha).

While you can pass a hex in there, I'm assuming Processing itself understands to convert that hex to an int at compilation. Passing the hex as a string currently doesn't work in Hype. The drawable class would need to be updated to have more fill methods that support a hex passed as a string.

Incidentally, fill('#0000FF'); does not work natively in Processing itself, again because fill wants a color (which is just an int), not a string.

If you wanted to make Hype work with Processing.py, I would think a separate port of Hype would be best as not to bloat the core with .py specific methods.

[hype]

Ben is correct... for example :

color c = color(#FF3300);
println(c);
returns an int - however you can also look into unhex()

String c = "#FF3300";

void setup() {
c = "FF" + c.substring(1);
fill( unhex(c) );
rect(10,10,100,100);
}

Joshua Davis

Joshua Davis Studios, Inc.
234 Jefferson Ave. Mineola, New York 11501
m. +1.516.417.3111
e. [email protected]

portfolio : http://www.joshuadavis.com

twitter : http://twitter.com/joshuadavis
flickr : http://www.flickr.com/photos/joshuadavis
facebook : http://www.facebook.com/JoshuaDavisStudios

On Mon, Jun 23, 2014 at 12:43 PM, tracerstar [email protected]
wrote:

In Hype, HRect is an extension of HDrawable. Within HDrawable, the fill
method accepts an int as it's color, or multiples of int i.e. (grey),
(grey, alpha), (r, g, b), (r, g, b, alpha).

While you can pass a hex in there, I'm assuming Processing itself
understands to convert that hex to an int at compilation. Passing the hex
as a string currently doesn't work in Hype. The drawable class would need
to be updated to have more fill methods that support a hex passed as a
string.

Incidentally, fill('#0000FF'); does not work natively in Processing
itself, again because fill wants a color (which is just an int), not a
string.

If you wanted to make Hype work with Processing.py, I would think a
separate port of Hype would be best as not to bloat the core with .py
specific methods.

—
Reply to this email directly or view it on GitHub
#68 (comment).

[tildebyte]

Incidentally, fill('#0000FF'); does not work natively in Processing itself

Right, exactly; the Python mode does the string->int conversion. It should be passing an int to HYPE; that's where I'm a little confused as to why this doesn't work.

RE: porting HYPE - The Python mode is really Java; the back end is jython. Looks like python, tastes like Python, but when you start to really scratch it hard, it's Python syntax for Processing. This is not a bad thing (e.g. most Java Processing libraries don't need any conversion at all - they Just Work). The .py-specific bloat is entirely contained within the Python mode - that's what it's there for.

[tildebyte]

::chuckles::
I might have it - it's possible that Jonathan is only looking for specific methods, e.g. background(). Since no HYPE methods are on the list...
This is sheer speculation; if you guys don't mind continuing to look into it on your end, I'll ping jdf about his end.

[tildebyte]

The workaround for hex-notation for colors is to use e.g. 0xFF2055FA - the required FF at the head is the alpha; FF is fully opaque.
This runs beautifully. Thanks for the hard work on a really cool library. If nothing else, being able to set and use an object's pivot point (vs. context/matrix... urk) is well worth the work it took me to get here.
I learned a great deal in working out how to do the callback for the onCreate() method. I was gobsmacked when it actually ran!
As I said, I'll follow up on this with Jonathan. Given the complexity of this second example, and the fact that I actually got it working, I think it's worthwhile to press on with testing HYPE in Python mode. I'd love to see HYPE as a "normal" Processing library (#67, hint, hint 😄).

[jdf]

Hi. I'm the author of Python Mode.

I don't want any library author to have to worry about the design of Python Mode, except when the library design makes it actually impossible to use (as when it depends on introspection of a method name). So I consider this bug to be entirely my problem. If you're interested in it, feel free to come and comment on https://github.com/jdf/processing.py/issues/97.