You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add compatibility for keyboard events (keyCode constants) to data.js #26
We've in the past combined data with events; it may also be useful to relabel the add-on in the editor from "Data Structures" to "Data & Events." I think this combination still makes sense because it contains various usages where the 2.0 breaking changes have the goal of more consistency - but if others think it would be better to split them into data and events, for example, I am also happy to support (with the attendant editor updates)
This issue includes reinstating 1.x constants (LEFT_ARROW) and keyboard events that have been changed (reviewing hem first; keyIsPressed, keyTyped, keyReleased, keyPressed, keyIsDown).
@davepagurek does the above sound reasonable / anything I'm missing? I'm happy to take this on.
I was also thinking that longer-term, it could be really helpful for the CI on this repository to run 1.x tests on the bundle of p5.js 2.x + compatibility add-ons, but that seems potentially quite challenging, or is there a way to do this (even manually, if not in a workflow)?
I think that makes sense keeping it as one. We'll probably also have to override the internal key event handlers to use the old event.keyCode instead of the new .key and .code properties.
I was also thinking that longer-term, it could be really helpful for the CI on this repository to run 1.x tests on the bundle of p5.js 2.x + compatibility add-ons, but that seems potentially quite challenging, or is there a way to do this (even manually, if not in a workflow)?
We could maybe do a CI action where we clone the main p5 repository (similar to what the website repo does), and then patches the code before running tests. It's definitely more complicated than running normal tests, but seems possible if anyone's interested in taking that work on.
We've in the past combined data with events; it may also be useful to relabel the add-on in the editor from "Data Structures" to "Data & Events." I think this combination still makes sense because it contains various usages where the 2.0 breaking changes have the goal of more consistency - but if others think it would be better to split them into data and events, for example, I am also happy to support (with the attendant editor updates)
Yes, I believe it would be a good idea to relabel the add-on in the editor from "Data Structures" to "Data & Events." It makes sense and would help reduce confusion for users. If you’d like, I’d be happy to open a PR to implement this change relabeling stuff and it could be merged once the work on the current PR is complete.
hey @ksen0 would love to give this issue a try, I will start digging further and raise a PR at the earliest. Please let me know if someone else is working on it or anything else which is needed.
@Deepak-cell311 yes I'm working on it, I was busy exploring and solving various other issues and features in the processing foundation, I will raise a PR within this week. Feel free to explore other issues for now.
Hi @kunstewi just checking in! Can you give an update sometime in the next 7 days? @Deepak-cell311 if you're still interested in working on this AND @kunstewi doesn't respond in a week, please feel free to take this on as the next person in the queue!
Thank you both.
Please excuse me @ksen0 for being idle. I've been going through a rough patch lately, juggling between multiple part time jobs to get by in college. Give me a day or two I'd raise a PR.
Hey @ksen0 could you please point me to any useful resource where I can find the changed keyboard constants from 1.x to 2.0. I've tried looking at the change logs but was unable to find the specific release where these were changed.
The keyCode constants have changed between 1.x and 2.x. The data.js add-on would provide the old 1.x style values for keyCode, because this is the recommended add-on for events&data backwards compatibility
here is the list of all system variables: https://p5js.org/reference/p5/keyCode/ try printing them out, eg with console.log(LEFT_ARROW), in the different versions (1.11.x and 2.2.x) to observe different
You are correct that this is a very confusing change. Any ideas you have on making this more understandable - here, or in the main reference docs - are very welcome. The reason for the change is so that p5.js more closely matches what modern browsers support. The previously-common keyCode is deprecated on the web, so it is important that p5.js 2.x stops recommending its usage. The goal of this compatibility library, though, is to allow users to keep their older code working as long as possible.
(If I am ever slow to respond here please don't hesitate to @ me on the p5.js Discord in the #contribute-to-p5 channel, I am happy to help but sometimes I miss the notifications!)
Activity
ksen0 commentedon Jun 6, 2025
@davepagurek does the above sound reasonable / anything I'm missing? I'm happy to take this on.
I was also thinking that longer-term, it could be really helpful for the CI on this repository to run 1.x tests on the bundle of p5.js 2.x + compatibility add-ons, but that seems potentially quite challenging, or is there a way to do this (even manually, if not in a workflow)?
davepagurek commentedon Jun 6, 2025
I think that makes sense keeping it as one. We'll probably also have to override the internal key event handlers to use the old
event.keyCodeinstead of the new.keyand.codeproperties.We could maybe do a CI action where we clone the main p5 repository (similar to what the website repo does), and then patches the code before running tests. It's definitely more complicated than running normal tests, but seems possible if anyone's interested in taking that work on.
perminder-17 commentedon Jun 12, 2025
Yes, I believe it would be a good idea to relabel the add-on in the editor from "Data Structures" to "Data & Events." It makes sense and would help reduce confusion for users. If you’d like, I’d be happy to open a PR to implement this change relabeling stuff and it could be merged once the work on the current PR is complete.
Rename 1.x Compatibility Add-on Library to Data & Events
kunstewi commentedon Dec 7, 2025
hey @ksen0 would love to give this issue a try, I will start digging further and raise a PR at the earliest. Please let me know if someone else is working on it or anything else which is needed.
ksen0 commentedon Dec 8, 2025
HI @kunstewi thanks for volunteering! Yes that would be great, assigning you. Please let me know here (or on Discord) if you have any questions!
Deepak-cell311 commentedon Dec 25, 2025
Hi @kunstewi, are you still working on this issue? If not, I’d be happy to take the initiative to work on resolving it @ksen0 .
kunstewi commentedon Dec 25, 2025
@Deepak-cell311 yes I'm working on it, I was busy exploring and solving various other issues and features in the processing foundation, I will raise a PR within this week. Feel free to explore other issues for now.
ksen0 commentedon Feb 11, 2026
Hi @kunstewi just checking in! Can you give an update sometime in the next 7 days?
@Deepak-cell311 if you're still interested in working on this AND @kunstewi doesn't respond in a week, please feel free to take this on as the next person in the queue!
Thank you both.
kunstewi commentedon Feb 11, 2026
Please excuse me @ksen0 for being idle. I've been going through a rough patch lately, juggling between multiple part time jobs to get by in college. Give me a day or two I'd raise a PR.
kunstewi commentedon Feb 19, 2026
Hey @ksen0 could you please point me to any useful resource where I can find the changed keyboard constants from 1.x to 2.0. I've tried looking at the change logs but was unable to find the specific release where these were changed.
Any help would be highly appreciated.
ksen0 commentedon Feb 19, 2026
Hi @kunstewi I hope you're doing well, and managing the different stressful things in your life! Thanks for working on this.
console.log(LEFT_ARROW), in the different versions (1.11.x and 2.2.x) to observe differentYou are correct that this is a very confusing change. Any ideas you have on making this more understandable - here, or in the main reference docs - are very welcome. The reason for the change is so that p5.js more closely matches what modern browsers support. The previously-common keyCode is deprecated on the web, so it is important that p5.js 2.x stops recommending its usage. The goal of this compatibility library, though, is to allow users to keep their older code working as long as possible.
(If I am ever slow to respond here please don't hesitate to @ me on the p5.js Discord in the #contribute-to-p5 channel, I am happy to help but sometimes I miss the notifications!)