New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update update updates #46
Comments
All my scripts are on Github, which is my main distribution center. I use GreaseFork (GF) and Userscripts.org (USO) only as secondary distribution centers. In my scripts, posted on GF, I have defined the Is it possible that you only set the
And according above statement from @arantius defining the Edit: updated quote. |
I see GF also change This is bad because if users have installed from different host a script before and then install the same script again from GF, they will have two same scripts. That's because Greasemonkey and Scriptish use
Test case
|
Note that Scriptish uses |
Confirm. That's even worse. Didn't noticed that before. Am getting not so happy with all those changes to my userscripts. |
That's probably the one case where setting these two properties does make sense. Some comments above make it clear that my comments are being misinterpreted, likely bits being taken out of context. Please reread the whole thing. Specifically, the quote in the first comment omits the critical conditional that the sentence started with: "If you don't set anything ...". And also, as said above by others, a script host should absolutely not go messing with the contents of the script at all, metadata or not. Changing the |
Don't know what you mean, but I updated the quote. |
The intention was to make it easier for script writers by not having these bits required, but I didn't adequately understand their importance when actually set. The new behaviour will be that The Greasy Fork saves the code as the author provided it, so when I put the changes, I can regenerate it. |
If they are provided by the author, they should not be stripped. The only time I am OK with those being stripped is in the case of an old version so that it doesn't update. |
My issue with off-site I know some people disagree with my restricting what authors can post, but I think it's necessary to maintain user safety. I think the syncing feature will accomplish what authors want to do (posting their script once in their location of choice and having Greasy Fork serve out the updated script) while keeping users safe. |
As long as you're really transparent, those sorts of changes make sense to me. I applaud improvements in the community around hosting/sharing/validating user scripts. I'm not surprised if the first few steps are a bit wobbly. |
This is an improvement for novice scriptwriters. 'Experienced' scriptwriters will use them anyways. Good choice.
I understand your opinion about user safety and stuff. But I want to make my situation, as a scriptwriter, also clear to you. So I'm a scriptwriter and I have multiple scripts. When I make a new one or update an existing one, it will be committed on my source control system (VCS) (Github since recently). To 'advertise' those scripts I had to upload them to USO, now also GF and soon to OUJS. Ok, that's fine, because I set my
This feature is already implemented in OUJS. If you implement this feature too, then it will save me some time. Don't get me wrong, user safety is very important, but I preferred to see some sort of reviewing system, like FF extension does. I would commit some of my time to review other scripts. Anyways, those were my two cents. Keep up the great work. |
But if the update happens outside of the system (i.e. if you allow the https://developer.mozilla.org/en-US/Add-ons/Install_Manifests#updateURL
|
This won't just save you some time, it should be equivalent in the "time required" department to what you were planning with
It's pretty useful to compare what I'm trying to do here with what AMO does.
I think if I made it as restrictive as AMO, people would go nuts! |
OK, changes committed:
All submitted scripts have been regenerated. Let's see how it goes! |
Excellent. I do understand the reasoning and am OK with it (the stripping of |
Actually they shouldn't be. If you right click on .user.js link and select View User Script Source with Greasemonkey, GM download it to temp folder, and if you click the Install button on notification, GM install it from temp folder and use If the script source on web host is updated, the script you installed won't be updated automatically. |
Maybe it's more Greasemonkey issue. @arantius? |
The install-time double-serving avoidance has nothing to do with updates. |
Per everything I've learned at greasemonkey/greasemonkey#1886
The text was updated successfully, but these errors were encountered: