Should we "steal" some ideas from p5.js?

[villares]

I was having a look at the p5.js reference and examples and was reminded of the existence of some features and surprised by some others...

Some that I don't think are worth the trouble like angleMode(DEGREES) (but it could be just my bias)

And there are others that look so nice, like orbitControl() that reminds me of wonderful PeasyCam...

An educator called Peter Farrell (a.k.a. hackingmath, who wrote a book with Processing Python mode content back in the day, made a small class mimicking the p5.js slider interface, I took the idea and tried my own clumsy variations of it... maybe py5 could have built in sliders?

I confess that in the back of my mind I'm also thinking that having some p5.js features would make, in the future, the user experience if switching between a Java/Processing back-end and PyScript/p5.js back-end smoother.

One more p5.js inspired question... Processing's loadFont() can only deal with VLW data, and I use createFont() most of the time nowadays with my students with open licensed local fonts... Would it be a good idea to overload load_font() so that it can still load VLW files but also would do the create_font() work? Would it be hard? Would there be any downsides to that? (I would still keep a creaet_font() alias... for the Java old-timers benefit)

load_font(
    name: str,  # name of the .vlw font file to load
    /,
) -> Py5Font

load_font(
    name: str,  # name of the system font to load or .otf  / .ttf font file to dynamically convert
    size: float,  # point size of the font
    Optional(smooth: bool)  # true for an antialiased font, false for aliased
    Optional(charset: list[chr]),  # array containing characters to be generated
    /,
) -> Py5Font

[hx2A]

Thank you, this is an interesting discussion. Some of these, like angleMode(), I have thought about before, but others like orbitControl(), I did not know about.

Some of these features would be better implemented "upstream" in the Processing Java code. My previous thoughts on angleMode() were that it should be implemented in the Processing Java code, but after revisiting the idea, I am not so sure. What is a complete inventory of the methods that would be affected by angleMode()? I see:

• all of the trigonometry methods, such as sin(), asin(), etc
• rotation methods like rotate(), rotate_y(), etc
• arc()
• perspective()

The above methods exist in Sketch, Py5Graphics, and Py5Shape. There are also methods in Py5Vector, such as heading(), angle_between(), etc

Am I missing anything?

If the feature were to be implemented in Processing Java code, it would create a headache for me because py5's trigonometry methods use numpy, not Java, and Py5Vector is also separate from Java code. So that code would need to always check with the sketch to see what the current angle mode is. This is difficult because Py5Vector exists independent from any Sketch classes and has no way of checking. Unless if it was a static method on the Processing Java side. Still it would make everything slower.

If the feature is implemented in py5 with Python code, I'd make it a global, py5-wide setting. If you were coding in class mode and had multiple classes, you'd be setting it for all instances simultaneously. I doubt anybody would want multiple classes with different angle modes anyway, so this isn't a real problem.

If the feature is implemented in py5 with Python code and later was added to Processing Java code, I'd exclude the Java version of angleMode()from py5 because that would break the py5 implementation and I don't want to have the previously mentioned headaches.

So bottom line, I like the idea of adding a angle_mode() method to py5, and since it is feasible, let's add it to the queue for new features to add to py5.

[villares]

Cool! Maybe missing: https://py5coding.org/reference/sketch_spot_light.html & https://py5coding.org/reference/py5graphics_spot_light.html

[hx2A]

Right, the spot light! I thought that was a thing in py5 but couldn't find it.

[hx2A]

There's also shear_x(), and shear_y().

[hx2A]

orbitControl() is interesting. I didn't know about this one. I'd like to see how p5 implements it. They must be adding mouse event functions to the user's code. How else can that work? And what does it do if the user already has their own mouse event functions?

I question if this feature could be added to Processing. The Processing Java code would need to modify the user's sketch code to add functions to it. This might be possible with reflective coding but it would be non-trivial.

Such a feature could be implemented in py5 but I might want to make some changes to py5 internals to better facilitate how to handle what to do if the user has their own mouse event functions.

This is a good feature idea but might be much harder to implement.

[hx2A]

On the subject of sliders in py5, I've thought about this as well. I was thinking of perhaps adopting ControlP5 and adding it to py5. There's https://github.com/KrabCode/LazyGui, which is currently maintained. If I could get either to work with py5, it would add a lot of great functionality to py5. Either of these avenues is better than implementing it from scratch.

[hx2A]

I think what you described for loadFont() and createFont() is something that should be implemented in Processing Java code. Basically loadFont() would create the font and load it for you? That sounds simple enough for them to code.