Diskuse » Greasy Fork Feedback
Potential new feature: script compatibility
I have wanted that too! I would like it! :)
Yea this sounds like a great idea!
Up vote. Love this idea :3
+1 vote.
A little issue should be attentioned is that there are many kinds of browsers (especially in China) and script hosts.
If you provide some browsers / script host for author to choose, some of them may not listed.
But if user specify special browsers, it may be hard to filter scripts by this option.
(I vote only list mainstream browsers like Firefox, Chrome, Safari, and, Opera)
+1 vote.
A little issue should be attentioned is that there are many kinds of browsers (especially in China) and script hosts.
If you provide some browsers / script host for author to choose, some of them may not listed.
But if user specify special browsers, it may be hard to filter scripts by this option.
(I vote only list mainstream browsers like Firefox, Chrome, Safari, and, Opera)
Too many Chromium forks!
Dear Sirs,
Your script (Blocking Script Anti-AdBlock Plus) does not work here on site nulled.cc
Please help me.
Oleg
Dear Sirs,
Your script (Blocking Script Anti-AdBlock Plus) does not work here on site nulled.cc
Please help me.
Oleg
Please create a feed back directly to that script :3
Script page -> Feedback -> Create new discussion
Another issue with this feature is that the authors may not have a possibility or desire to test their scripts in all the listed browsers after each update, but this doesn't mean that the script cannot be used in those other browsers - most scripts don't use browser-specific tricks/hacks and the chances are that they're cross-browser compatible since nowadays the modern browsers try to conform to standards as much as possible.
If you provide some browsers / script host for author to choose, some of them may not listed.
We could list the common ones, and then "other". I also think it would be a good idea to allow a bit of optional text for each one, so for example you could mark "works in Greasemonkey" but specify "only for Greasemonkey 2.0+".
Another issue with this feature is that the authors may not have a possibility or desire to test their scripts in all the listed browsers
That's what "untested" is for, and I think it would be the default. The author could update it based on user feedback.
Do you think it's sufficient to list user script managers (Greasemonkey, Tampermonkey, etc.) and not browsers? User script manager would imply browser, and if there were any browser-specific issues with the same manager, that could be mentioned in the optional text.
Oh, with "untested" option it makes sense then, but then again, will such scripts be listed by default if I select specific browser compatibility or maybe there'll be a checkbox "[x] list untested too"?
Regarding the script managers: Google Chrome (and maybe all Chromium-based browsers) support installing userscripts directly by dragndropping the script file onto the Extensions tab, and those scripts that don't use Greasemonkey API will work even without a script manager. I don't know if this should be considered as a separate choice or should it be ignored.
Overall I'd go with the "browser (manager)" scheme. The question remains, though, should we list only the most known user manager or the alternative managers as well (Scriptish, NinjaKit, Scriptify, etc)
I imagine things that are "untested" in your manager of choice will still show up in a search.
It is hard to explain how the compatibility of script is. For example, I have a script which...
Works on some script host: Some of my scripts only works on Greasemonkey but will not work or broke webpage on Scriptish.
Functions for specify browser: The main function of that script supports both Firefox and Opera, but the contextmenu function only works on Firefox due to supports of <menu >.
Works on special version: I have a script which works well on Fx33 with GM2.2, and it will also work on Fx28 with GM1.15. But these days, many user came to ask me why their script is broken. And I found they are using it under Fx33 with GM1.15. (They claim that some other scripts only support GM1.x and so they keep that version of GM and won't update)
Conflict with other add-ons: My script use drag-drop to an div[contenteditable] in some functions. It works fine on a clean profile of Firefox, but will fail if user installed some add-ons like DragIt or 附加组件管理器 (Mozilla China). Also, another function will break with Thunder Extension.
I don't see this as a big problem. If you can enter values like <Browser><Browser-Version><Addon><Addon-Version> you can easily reflect most of the situations you discribed. The only thing which can not be shown is something like doesn't work with ... But with an additional text field for notes this should also be no problem. The important thing would be to provide the option for the user to filter and search through the entries and also to enable the auto synching from a thrid party source (eg. by providing these information as a csv or json ...). Otherwise everything can be updated by pushing a commit to a repository and after I've done this I have to go to greasy fork and enter these values manually.
This may be better as in-script metadata... I'd have to get some feedback from other interested parties.
+1 for metadata block : easier to maintain within and synchronised with the code itself.
+1 for ability to set both browser and extension used for the test : Opera only, Opera+Violentmonkey, Chrome+Tampermonkey, etc.
+1 for those three options (doesn’t/works/untested), like (just made up examples) : works in Opera 12 : works in Opera 12 with Violentmonkey : untested in Opera 15+ : doesn’t work in Chromium with Tampermonkey 1 : works in Chromium with Tambpermonkey 2 : works in Firefox with Greasemonkey : untested in Chrome
I don’t know if it will be easy to manage 15+ like version numbers though…
(sorry my post is quite abrupt, maybe)
Yeah, I think it becomes too cumbersome if you want every combo of browser, manager, and version. If it was just manager plus optional descriptive text, the same data could be something like:
@compatibility:op maybe Works in Opera 12, untested Opera 15 @compatibility:vi true @compatibility:tm true Works in Tampermonkey 2, doesn't work Tampermonkey 1 @compatibility:gm true @compatibility:ch maybe Untested
In cases where some versions are compatible, it could be up to authors whether to say "true" or "maybe" - perhaps a good suggestion would be to go based on the latest version.
I like the suggestion of @JasonBarnabe.
But please consider that there are some addons with the same name in different browsers. e.g. Tampermonkey in Chrome and Opera. It might be the case that there are scripts working in one browser and being broken in the other. So being able to have something like @compatibility:tm-op and @compatibility:tm-ch for Tampermonkey in Opera would be good.
I’m not sure those two letter codes are very human readable outside of greasyfork system… I’m not too fan of this particular syntax…… what about something like (it certainly has flaws I don’t see myself) :
@compatibility:opera 15+:false
@compatibility:Opera 12:true
@compatibility:violent-monkey:true
@compatibility:tampermonkey 1:true
@compatibility:TampeRMonkey 2+:false
@compatibility:Firefox:true
- the program string is anyname (including spaces or with spaces replacd with -) that can be followed by space and a version.
- the end of line ends with either true or false (or 1 or 0) (or yes or no) preceeded with :
- eventually for ** untested** isn’t it better to say that when you don’t mention it, it is untested… I don’t see now why we would need to say it explicitly…
Or maybe even better ? (like exclude include) :
@incompatible opera 15+
@compatible Opera 12
@compatible violent monkey
@compatible tampermonkey 1
@incompatible TampeRMonkey 2+
@compatible Firefox
upper/lower case both ok.
I see no big issue in writing the full name, but then keep the syntax as it is now for most of the script information: No special characters in the names and no registration of upper / lower case. Also please not more than one ":" in the name of the tag (except for specific prefixes).
To leave maybe is also not an option as you can see in Jasons post: I can test something in some versions and in others not. And comments are also necessary to state some things which can't be expressed like "incompatible with script X or addon Y".
@JasonBarnabe: Shouldn't it be prefixed with gm as its a Greasy Fork specific feature?
The point of this is for the values to be easily readable by Greasy Fork and whatever else wants to use it. If you want something human-readable, then just put a comment and say whatever you like, no special format required.
I expect this to be useful to other managers and sites, so I don't expect this will be prefixed. I'm going to check with them once we get this sorted out more.
":" is used for localization.
Use this also for compatible may have some problem. also, if we want to write some localized text for user in the compatible information, this will not work.
So, I prefer a prefix version "@-moz-compatible" for compatible in Firefox, which just like "-moz-" in "-moz-document", or "-webkit-" in "-webkit-flex-direction". (I've no idea how to say scrip host.)
"@-moz-compatible" for compatible in Firefox
- It would be misleading because userscripts aren't supported by Firefox itself (without GM/Scriptish) whereas the suffix implies native Firefox implementation of things. The same goes for other browsers because even though Chrome and Opera support userscripts natively but they don't offer the Greasemonkey API which is used in lots of userscripts (half of them maybe?).
- Such suffix exists only because a) W3C takes many years to approve a new feature b) for browser-specific internal stuff. Both cases obviously do not apply here.
"@-moz-compatible" for compatible in Firefox
* It would be misleading because userscripts aren't supported by Firefox itself (without GM/Scriptish) whereas the suffix implies native Firefox implementation of things. The same goes for other browsers because even though Chrome and Opera support userscripts natively but they don't offer the Greasemonkey API which is used in lots of userscripts (half of them maybe?).
* Such suffix exists only because a) W3C takes many years to approve a new feature b) for browser-specific internal stuff. Both cases obviously do not apply here.
So what about @-greasemonkey-compatible ?
So what about @-greasemonkey-compatible ?
I'd say we should stick to the greasemonkey rules (yes, there are also other managers but the metadata is the same or based on this rules). These define four different types of keywords:
- keyword:
@<keyword> - keyword+ value
@<keyword> <value> - keyword + value1 + value2
@<keyword> <value1> <value2> - keyword + locale + value
@<keyword>:<locale> <value>
Other definitions are not known. keyword is just a word with no special characters (except for run-at). locale follows the RFC 3066 as far as i know (xx or xx-xx). Value can be anything. So I would stick as near to this as possible.
So I would suggest two versions based suggestions of @JasonBarnabe and @jesus2099 Comment is always optional. I used long values in the value1 section as it's more readable and if we define a value list, it should make no difference :)
// New version with value1, value2, value3 but follows the rules.
@compatibility <browser/addon identifier> <status> [<comment>]
// Example:
@compatibility opera maybe Works in Opera 12, untested Opera 15
@compatibility opera-tampermonkey true Some comment
@compatibility opera-violentmonkey false
// Different tags
@<compatible|incompatible|unknown> <browser/addon identifier> <comment>
// Example:
@unknown opera Works in Opera 12, untested Opera 15
@compatible opera-tampermonkey Some comment
@incompatible opera-violentmonkey
I like the first suggestion, but they both work for me. I only suggested a short version of the browser/addon identifier because this exists already in the form of proprietary prefixes.
Is there a better place than the Greasemonkey GitHub to get feedback on this wider stuff? I feel kind of weird because it's not like they're the bosses of the format, but I don't know of a better place.
All the posts here are very interesting !
no registration of upper / lower case
@Tobbe, if that ↗ means that oPEra, Opera and opera are treated the same, I’m all with you !
@JasonBarnabe, I still don’t get the use to have untested/maybe/unknown feature…
For instance let’s take some user of SuperBrowser. They will see a script where it’s written SuperBrowser untested. I can’t tell the difference for that user when they don’t see anything about SuperBrowser in another script… It really seems the same to them IMO. (._.?)
I didn’t really like the “:” characters without knowing how to say, so despite my personal preference for the second one (more concise and similar to existing @include/@exclude), I would be really happy with any of both @Tobbe suggestions ! :)
I only suggested a short version of the browser/addon identifier because this exists already in the form of proprietary prefixes.
They might be known amongst the developers, but the average user usually has no knowledge of the deeper structures and it is more readable und understandable for them if the names are not shortened :)
Is there a better place than the Greasemonkey GitHub to get feedback on this wider stuff?
I'd say any GitHub repo is fine as everyone can read it. And if you link from the newly created issue for OUJS to the GF issue most of the poeple affected by this would recognize it.
if that ↗ means that oPEra, Opera and opera are treated the same, I’m all with you !
Yes. That was my intention. I wrote it as you had different versions in your suggestion.
I've @-ed a bunch of people at https://github.com/JasonBarnabe/greasyfork/issues/30, let's continue discussion there.
Potential new feature: script compatibility
A while ago, I had an idea for a feature for Greasy Fork. I'd like to get more feedback on it before do anything with it.
My idea is to let script authors specify what browsers or user script managers their scripts are compatible with. They could specify "works", "doesn't work", or "untested" and this would be displayed to users. Users would also be able to filter scripts based on this info.
For users, this would let them know in advance if the script won't work for them. For script authors, it would potentially eliminate some bad reviews from people using things they're not supposed to.
Does this sound like a good idea? Would you use this feature? Or perhaps you find it's a general rule that things that work in one thing work in all, so this would just get in the way? Or maybe you'd rather just include compatiblity in your additional info if it's applicable.