Consolidation of duplicate PRs

[Brackets-Coder]

I'm going to try to consolidate some of the duplicate extension pull requests. This is a non-conclusive list and is subject to change.
Some of these extensions will be harder to consolidate than others as they are either well-developed or both have benefits over the other.
Some of these we may not even want to consolidate yet, and others are part of a bigger issue (like sensing+ or "secure" storage).

• Create: Advanced Data Structure Extension #1354 and Object extension #1066
• Enhanced extension: Complexify!.js #2113 and Complex Numbers Extension #1861
• Mobile events #1617, New extension: Multi Touch #1432, and New extension: Touches #1608
• Controls+ #1183 and More Control: Add More Control extension #1176
• Create firebasedb.js #2087 and IndexedDB extension (omg this is like my 3rd try lol) #1341
• Adding my "Audio Recording" extension #1040 and Add my Microphone Recording Extension Mr. Muffin Man #1060
• more mouse controls #2104 and New extension: Wheel Scroll #1122

[CubesterYT]

I think a very big issue with "consolidating duplicate extensions" is that each dev has their own ideas and want to have their stake in the extension gallery. By taking down duplicates, you fuel the fire of "one extension is better than the other, so the lesser ones must be closed". If there's duplicate extensions, and none have been merged yet, I rather wait to see which one ACTUALLY gets merged before we close duplicates. It's nice to give people chances considering this repository is slow and having a chance against devs who are already on the gallery are tight.

[CubesterYT]

There was fights over this over a year ago with this same issue.

[SharkPool-SP]

That's not really fair. Older ones came first can should have a higher priority.

Newer ones show up higher in the list. People might not realize there's a duplicate lower.

[SharkPool-SP]

If the older ones were merged, we wouldn't be having duplicates in the first place

[Brackets-Coder]

I think a very big issue with "consolidating duplicate extensions" is that each dev has their own ideas and want to have their stake in the extension gallery. By taking down duplicates, you fuel the fire of "one extension is better than the other, so the lesser ones must be closed". If there's duplicate extensions, and none have been merged yet, I rather wait to see which one ACTUALLY gets merged before we close duplicates. It's nice to give people chances considering this repository is slow and having a chance against devs who are already on the gallery are tight.

See the initial comment, this issue isn't meant to rapidly close any duplicates without any care or concern.
I aim to:

1. Prioritize the interests and unique ideas of each developer
2. Not be hasty in my decisions
3. Not cause any dissension in the community

I want to be very clear that "Consolidation" ≠ "forget this PR, let's close it because there's a better one"

The whole point of this issue is to critically think about how to consolidate these extensions into something better than they would've been independently, not blindly close PRs for the sake of organization

The only duplicates that I might close hastily are those that are poorly written or purposeless, but such instances are rare. I'm trying to go about things carefully, but if you guys have other suggestions I'd be open to them.

I'm not trying to fuel any fire or cause problems, I'm attempting to do my best to encourage constructive collaboration. I apologize for any confusion that might have been caused.

[Brackets-Coder]

It's clear that this issue is a necessary one to address, but should be done so carefully as it's a sensitive topic.
I'm going to attempt to proceed with caution and with the assistance of anyone who's willing to provide feedback or help

[SharkPool-SP]

I think it's fine to have collaboration. But in the case neither developer wants to collaborate, the better-written/older pr should take priority

[Brackets-Coder]

I think it's fine to have collaboration. But in the case neither developer wants to collaborate, the better-written/older pr should take priority

That was my intention all along.
For example, see #1040. Although it was older and technically had more priority, your extension had the same features and more. See the note I added upon closing for extra context if necessary

[Brackets-Coder]

I think it's fine to have collaboration. But in the case neither developer wants to collaborate, the better-written/older pr should take priority

That was my intention all along. For example, see #1040. Although it was older and technically had more priority, your extension had the same features and more. See the note I added upon closing for extra context if necessary

this is untopical, but @SharkPool-SP I do think you should add a base64 option to the "save as" block of your recording extension as it's present in the other one but not yours.

[SharkPool-SP]

I think it's fine to have collaboration. But in the case neither developer wants to collaborate, the better-written/older pr should take priority

That was my intention all along. For example, see #1040. Although it was older and technically had more priority, your extension had the same features and more. See the note I added upon closing for extra context if necessary

this is untopical, but @SharkPool-SP I do think you should add a base64 option to the "save as" block of your recording extension as it's present in the other one but not yours.

Not sure of the use in that. Plus base 64 is just the data uri without the start

[Brackets-Coder]

Not sure of the use in that. Plus base 64 is just the data uri without the start

Base64, would, for example, allow users to plug into the "download data URL" block of the Files extension so they can record something in their project and download as they please at runtime

just a thought

Edit: forgot about your extension having the "download audio as" block, but still, there are a few vague uses I guess...