Replies: 4 comments 5 replies
-
I thought it was due to how Scratch only renders the visible areas of a list, with the calculations assuming a fixed row height? |
Beta Was this translation helpful? Give feedback.
-
The idea sounds interesting, it would be specially useful to distinguish addons that support touchscreen usage vs those that don't. |
Beta Was this translation helpful? Give feedback.
-
If we can't implement a feature in the Chrome version of our extension, then it probably shouldn't be implemented for any other browser either. In general, I think we should prefer releasing features to all browsers and platforms at the same time. But if a suite of features proves to be incompatible with a different type of device or operating system, that's when it makes more sense to leave something out. |
Beta Was this translation helpful? Give feedback.
-
The only thing being copy-pasted is addon IDs. Scripts generate the rest of the addon files. Having this metadata live in TurboWarp is much more convenient for everyone. The settings pages have very different technical requirements (eg. vue vs react, browser extension vs web, webpack, etc.) and the designs don't need to match (in some cases deviation is quite intentional). I don't see a reason to merge them. |
Beta Was this translation helpful? Give feedback.
-
How would we handle addons and features that only work in certain browsers/platforms? I can think of the following scenarios:
TurboWarp uses a selection of compatible addons. This requires manual copy-paste work with every update, plus design inconsistencies between Scratch Addons' and TurboWarp's settings page.How this would be implemented:
Beta Was this translation helpful? Give feedback.
All reactions