Track Processing API coverage in libprocessing/mewnala #153

Activity

1. SableRaf

   pinned this issue on Apr 28, 2026
2. catilac

   added

   c-pyo3

   on May 21, 2026
3. Gmin2 commented on May 29, 2026

   

   Gmin2

   on May 29, 2026

   More actions

   hey @SableRaf , i was just experimenting with this and managed to get the math ones working (map, constrain, lerp, norm, dist, mag, radians, degrees, plus random and noise ported from processing so the output matches). should i just open the pr for those and then move on to color reading next (red, green, blue, alpha, brightness, lerp_color)?

   one small thing i wanted to flag, the list here uses the java camelCase names but mewnala already uses snake_case (stroke_weight, no_fill etc), so im matching behaviour with pythonic names rather than the exact names. shout if youd rather i do it differently.

   cc @catilac @tychedelia
4. catilac commented on Jun 4, 2026

   

   catilac

   on Jun 4, 2026

   Contributor

   More actions

   @Gmin2 hi! i think for python we should do what is pythonic. there is also a discussion to be had around processing APIs potentially getting in the way of what is best practice in python.
5. antiboredom commented on Jun 4, 2026

   

   antiboredom

   on Jun 4, 2026

   Last edited by antiboredom

   Member

   More actions

   Hi all, I've been playing around with mewnala and it's really great! So excited to see this happening.

   To echo @catilac's comment, I was thinking this might be a good opportunity to have a conversation about how "pythony" to make the library and the example sketches. One thing that I noticed in the examples, that I think should be changed, is the use of the star import (from mewnala import *). I realize this makes things feel easier for beginners because it makes calling methods less verbose, but it's considered a bad practice in python.

   The second issue I'm seeing in the examples is the use of the global keyword, another pattern that's generally frowned upon. This is a bit trickier to deal with. There would in my mind be 2 alternative patterns to look into.

   Option 1: store sketch state in a top level object. This would work with the existing codebase, but I still don't think is ideal or very ergonomic:

   import mewnala as m
   
   # could also be a class, just use a dict here for convenience
   state = {"x": 0}
   
   def setup():
       m.size(300, 300)
   
   def draw():
       m.background(255, 255, 255)
       m.ellipse(x, 150, 10, 10)
       state['x'] += 1
   
   m.run()

   Option 2: remove setup and draw. Put setupy stuff at the top level, and replace the draw function with a while loop. I think this is the strongest option, and the most "pythony". It's also closer to how other similar libraries like pygame work.

   import mewnala as m
   
   x = 0
   
   m.size(300, 300)
   
   while m.draw():
       m.background(255, 255, 255)
       m.ellipse(x, 150, 10, 10)
       x += 1

   These are just my initial thoughts after playing around a bit. I'm very curious to hear what other people think!

   ❤️React with ❤️3Reacted by Moon, Raphaël de Courville and Xin Xin
6. catilac

   modified the milestones: Documentation, Full Processing API Coverage on Jun 30, 2026
7. catilac commented on Jun 30, 2026

   

   catilac

   on Jun 30, 2026

   Contributor

   More actions

   Hi @antiboredom thanks so much for your input here! These are really great ideas. The departure from setup() and draw() is something i definitely haven't considered. It also feels like a really clean approach that would cut out a lot of tricky engineering.
   I also think this would make our lives easier in jupyter notebook and google collab because we'd be very "pythony"

   Since we would just be writing regular python, someone could always go and write the fancy thing on top to create the setup() and draw() stuff if they really wanted.

   ❤️React with ❤️1Reacted by Sam Lavigne
8. catilac commented on Jun 30, 2026

   

   catilac

   on Jun 30, 2026

   Contributor

   More actions

   @SableRaf I would like to turn this page into a bunch of issues for the Full Processing API Coverage Milestone could we discuss this?

   👍React with 👍1Reacted by Raphaël de Courville
9. hx2A commented on Jul 1, 2026

   

   hx2A

   on Jul 1, 2026

   More actions

   I'm also opposed to writing import * in Python, I think it is a bad practice. There are other ways to go about this though. For py5 I did create a custom Jupyter Notebook kernel that provides the same import * experience. This is also available to users in Thonny using what we call "imported mode". Educators who use py5 like this as it is better for beginners and reduces cognitive load and visual clutter. Maybe mewnala could explore other options besides import * that provide a similar result?

   I also don't like global statements but they are necessary in py5 because of the dependence on setup() and draw() functions.

   Option 2: remove setup and draw. Put setupy stuff at the top level, and replace the draw function with a while loop. I think this is the strongest option, and the most "pythony". It's also closer to how other similar libraries like pygame work.

   import mewnala as m
   
   x = 0
   
   m.size(300, 300)
   
   while m.draw():
       m.background(255, 255, 255)
       m.ellipse(x, 150, 10, 10)
       x += 1

   This is an intriguing idea! I see how m.draw() could set the pace of the rendering frame rate and there would be no need for global statements. I'd really like using it this way. My only question is what would drive the animation thread? In Processing the animation thread is driven by Java code, or in the case of the OpenGL renderers, it is driven by the JOGL code (at least I think they are, that part of the code is opaque to me). Anyhow, the above while loop suggests Python is controlling the animation thread. But libprocessing is a Rust library, and some folks might want to code with it in pure Rust with Rust driving the animation. I suppose things could be engineered such that both are possible, but that might add unwanted complexity. I know from py5 that having multiple ways of using it is great but it also makes things harder to maintain. But if it can be done cleanly, I think providing options like this are great idea.
10. SableRaf commented on Jul 2, 2026

    

    SableRaf

    on Jul 2, 2026

    ContributorAuthor

    More actions

    @SableRaf I would like to turn this page into a bunch of issues for the Full Processing API Coverage Milestone could we discuss this?

    Yes, let's chat. I DM'd you.

    We could re-use the same script I used to generate the task-tracker sub-issues in the processing-examples-mewnala repo.

    Also this is important to consider when looking at the todos above:

    The list is based on the official Processing reference. This is NOT an exhaustive list of every class, method, or keyword in Processing. Parts of the API are undocumented or listed in individual class pages, see the Methods section of PVector or PImage for example. For a more complete API overview, see the Processing 4 Javadoc.
11. catilac

    added this to libprocessing Roadmapon Jul 2, 2026
12. github-project-automation

    moved this to Todo in libprocessing Roadmapon Jul 2, 2026