Hi @claudine ,
while working on the eyedropper injection script, I’m targeting the canvas using getElementById('defaultCanvas0') with a fallback to querySelector('canvas'). I wanted to check - is defaultCanvas0 stable enough to rely on as a primary selector, or are there sketch patterns where the canvas ends up named differently? Just wanted to make sure the script handles edge cases correctly before building further on top of it.
1 Like
Hey @claudine, while working on the eyedropper color debugging tool, I was considering edge cases and had a question about mobile and touch devices. Since hover is not available, should the eyedropper tool degrade on such devices, or is there an alternative interaction we should support? would love your guidance on this.
1 Like
Hi @Geeta112
Even I’m working on the eyedropper tool. One idea I had was to let users drag their finger across the canvas and show a magnified view of the pixel under their finger.
2 Likes
Hii @NishthaJain , That’s a great idea. Just to clarify, are you suggesting showing both the magnified pixel view and the RGBA values of the pixel under their finger on touch devices?
1 Like
I’m showing the RGBA values in the preview frame header for bigger screens. Thank you for pointing that out, the smaller screens do not have preview frame header when a sketch is running. Would like to know if u have any ideas
2 Likes
That’s a really thoughtful point @NishthaJain, and great that this was brought up. The drag-to-sample idea is genuinely interesting.
Since I’m also working on the eyedropper tool, one thing I’ve been thinking about is that the core use case seems to be shader debugging with p5.strands, which tends to be a desktop workflow - so I was wondering if graceful degradation on touch devices might be a reasonable starting point, and if people find themselves wanting touch support down the line, that could always be built on top.
Would love to hear what @claudine thinks about this.
2 Likes
@claudine @diyaayay I’m researching further into the “Full texture support for .mtl file” and in the Project Ideas list it is mentioned that we would need to design a new data structure of sorts to accomodate the values parsed from .mtl file.
I’m thinking that designing a new class “p5.Materials” would be the right approach to this issue, but then I looked into the parameters passed to the model() function and it seems like it’ll be a huge breaking change because currently the model() function accepts “p5.Geometry” class.
Instead I could propose to add a property inside “p5.Geometry” to store sub-geometries (e.g: geometry.materialGroups). Or maybe even make a new class “p5.Group” that extends or wraps “p5.Geometry”.
Please let me know what are your thoughts on this matter.
Thanks 
Hi @Divyansh013, thanks for the correction on #1174 — you’re right, the tracker flagged it correctly since the translation files are genuinely missing. I misread that as a false positive.
On the assignment point — I understand your concern about building something translation-specific when the friction exists across all repos. My thinking was that a /claim command would reduce the back-and-forth in comments where contributors ask “can I take this?” and stewards have to manually redirect them. But if stewards are already notifying specific language maintainers via cc, maybe the real gap is just visibility — knowing which issues are actively being worked on without reading every comment thread.
Would something simpler help, like the bot automatically adding a “in progress” label when a contributor comments they’re starting work, and removing it if no PR is linked within a set timeframe? Or is the manual routing actually working well enough that this isn’t a priority
1 Like
completely agree with what @KhushiMishra pointed out, Since the primary use case is shader debugging with p5.strands which is mostly a desktop workflow, graceful degradation on touch devices seems like the most practical starting point. Touch support could always be added as a future enhancement once the core feature is stable. Looking forward to hearing @claudine’s thoughts too
1 Like
Thank you for bringing this up @KhushiMishra, Really helpful perspective.
Hi @Aaditya it’s not strictly mandatory to use only mongodb-memory-server for E2E testing. It’s currently being used mainly for model/unit tests since it’s lightweight and easy to spin up.
For E2E testing, using a Docker-based MongoDB instance is also a valid option. Since the project already supports running MongoDB locally as well as via Docker, both approaches seem reasonable depending on the use case.
For local testing:
-
mongodb-memory-serverworks well for faster, isolated tests -
Docker MongoDB provides a more realistic end-to-end environment
Similarly, for GitHub Actions workflows (test.yml),you can either continue with mongodb-memory-server for simplicity or use a Docker-based MongoDB service for better consistency with a production-like setup.
1 Like
Thank you @Geeta112 , glad it was helpful. And you and @NishthaJain actually got me thinking about it more carefully too - I hadn’t really considered the touch angle until you brought it up.
1 Like
Thanks for the clarification! @rahulchaudhary
2 Likes
Hey everyone, I have uploaded my last year’s gsoc proposal here. Please treat this proposal as just reference on how I personally approached the project. I would really appreciate if you all think in a new direction or an enhanched extension.
4 Likes
Hi @claudine! I have submitted my proposal draft for individual feedback. Looking forward to your feedback!
1 Like
Hi @kit and @claudine, I have submitted the feedback form for my GSoC 2026 proposal. Could you please confirm if it has been received?
1 Like
Hi @kit and @claudine I have submitted the feedback form for my GSoC 2026 proposal. Could you please confirm if it has been received? my email is rahulchaudharyji2@gmail.com
1 Like
Hi @kit and @claudine I too have submitted the feedback form for my GSoC 2026 proposal. Could you please confirm if it has been received? my email is krishnageethprojects@gmail.com. Thank you
1 Like
Hi,
I’m a prospect intern interested in participating in Processing Foundation’s Summer of Code. I have experience with Java up to AP CSA and some basic GitHub knowledge. Is there anything I should know before I commit to a proposal?
Great to see all the questions and sharing of ideas on this thread!
@KhushiMishra @Geeta112 I wish I could answer your question, but I’m actually a Processing person, not p5.js 
You’ll have to wait for a p5 mentor to respond.
In the meantime, for anything that you are not positively sure of regarding your proposal, this is ok - think through the possibilities and how you’d approach the problem in each scenario, and put this into your proposal. What is very helpful for us, and for your application, is to share with us how you reason through things. This is a perfect opportunity to show us how you think.
4 Likes