More options for userscript matches (not only URLs)

[WorldLanguages]

Let's say a userscript only works on user profiles. The current match would currently be https://scratch.mit.edu/users/*/, why not just userprofile? And other potential filters for common use.

[WorldLanguages]

I believe it's too late to implement this. It's not a big deal, either. Closing

[Hans5958]

too late

[TheColaber]

I believe this one is worth reopening. Once we implement #390, addons that work on the editor/project page would also need to work on turbowarp's editor/project page. If we simply said for the match URL to be project, then we could have the match URL patterns for both turbowarp and scratch to link to htpps://scratch.mit.edu/projects/* and https://turbowarp.org/* (excluding the https://turbowarp.org/privacy.html page). And, if we end up supporting addons on another site, then it would be useful there too. This would also help with #646. And I think it's just easier if all the user needed to add in their addon, was just search or user

[RedGuy12]

And phosphorous

[WorldLanguages]

I believe this one is worth reopening. Once we implement #390, addons that work on the editor/project page would also need to work on turbowarp's editor/project page. If we simply said for the match URL to be project, then we could have the match URL patterns for both turbowarp and scratch to link to htpps://scratch.mit.edu/projects/* and https://turbowarp.org/* (excluding the https://turbowarp.org/privacy.html page). And, if we end up supporting addons on another site, then it would be useful there too. This would also help with #646. And I think it's just easier if all the user needed to add in their addon, was just search or user

I honestly doubt userscript made for the Scratch editor could work "as-is" on TurboWarp, so it wouldn't make sense to merge both origins into one permission - an addon might only work on the Scratch editor

[RedGuy12]

Well maybe userstyles Paul Reid

…

________________________________ From: World_Languages <notifications@github.com> Sent: Friday, January 1, 2021 3:15:04 PM To: ScratchAddons/ScratchAddons <ScratchAddons@noreply.github.com> Cc: Paul Reid <paul@reid-family.org>; Comment <comment@noreply.github.com> Subject: Re: [ScratchAddons/ScratchAddons] More options for userscript matches (not only URLs) (#23) I believe this one is worth reopening. Once we implement #390<#390>, addons that work on the editor/project page would also need to work on turbowarp's editor/project page. If we simply said for the match URL to be project, then we could have the match URL patterns for both turbowarp and scratch to link to htpps://scratch.mit.edu/projects/* and https://turbowarp.org/* (excluding the https://turbowarp.org/privacy.html page). And, if we end up supporting addons on another site, then it would be useful there too. This would also help with #646<#646>. And I think it's just easier if all the user needed to add in their addon, was just search or user I honestly doubt userscript made for the Scratch editor could work "as-is" on TurboWarp, so it wouldn't make sense to merge both origins into one permission - an addon might only work on the Scratch editor — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#23 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOT5DESCRGJABLPA6US4W6TSXY3NRANCNFSM4PL5ILKA>.

[TheColaber]

I honestly doubt userscript made for the Scratch editor could work "as-is" on TurboWarp, so it wouldn't make sense to merge both origins into one permission - an addon might only work on the Scratch editor

I'm sure that most do, and some (like project-notes-tabs) could easily be fixed by adding an if statement to not run at all.

[TheColaber]

I honestly doubt userscript made for the Scratch editor could work "as-is" on TurboWarp, so it wouldn't make sense to merge both origins into one permission - an addon might only work on the Scratch editor

How bout now hehe. But even so, this should 100% be implemented... for future mods.

[TheColaber]

wl has recondered. pr soon.

[TheColaber]

@mxmou

One reason is that there are addons that don't set their match to the forums but are closely related to them (discuss button)

In this case, the addon can manually add the tag.

There are also addons that have forum matches to implement forum-specific functionality but aren't otherwise forum addons (infinite scrolling).

I argue that infinite scrolling and other addons like that should have the forums tag, even if their effect on it is very little. Alternatively, we can check if the userscripts/userstyles have the settingMatch property. Then it will ignore its matches.

Another reason is that if we add subcategories, editor addons will need to set them explicitly anyway. Why would website addons work differently?

The editor is not different pages, whereas the forums and the profiles are.

[mxmou]

One reason is that there are addons that don't set their match to the forums but are closely related to them (discuss button)

In this case, the addon can manually add the tag.

There are also addons that have forum matches to implement forum-specific functionality but aren't otherwise forum addons (infinite scrolling).

I argue that infinite scrolling and other addons like that should have the forums tag, even if their effect on it is very little. Alternatively, we can check if the userscripts/userstyles have the settingMatch property. Then it will ignore its matches.

This would cause similar issues as the theme tag did. I don't think we should add more features that affect both functionality and categorization like that.

The forums tag should be only for addons users want to see when choosing "forums" in a menu. Maybe infinite scrolling should be one of them, but what about website dark mode?

[mxmou]

The editor is not different pages, whereas the forums and the profiles are.

It still doesn't make sense for editor addons to behave differently than website addons in any way.