![]() ![]() |
I was just pointing this out so that hopefully the future GM updater doesn't do that. Let me be honest for once: I'm sorry my shitty updater wasn't good enough for you. edit: #$@#$!%!#%@#% |
![]() ![]() |
Firstly, I'm disappointed that you took my statements so personally. I'm in this discussion to talk about the proposed implementation of a updater in GM, not to bash you or your updater. lazyttrick wrote:I never said your updater was shitty. In fact, on the contrary I think its amazing, hence why I've given it 5 stars. Just because I don't currently use it because I've had problems with it doesn't mean I don't realize the great work you have done. lazyttrick wrote:You took my statement the wrong way. When I said that we were talking about methods of update checking. You were advocating checking for all updates at once like you do in your updater. I was saying only scripts that are used(which would not include disabled scripts) should be checked for updates. I admit that now that I read what I said again it sounds like I was calling your updater stupid for checking for updates of disabled scripts, but what I really meant is that if the future GM updater checked for updates of disabled scripts that would be stupid. I'm sorry for my poor choice of wording that lead to this misunderstanding. |
![]() ![]() |
communication can be tricky sometimes, I'm sorry I misunderstood that part too... I think these ideas are good for a start, though they are spread all over the topic... |
![]() ![]() |
Rycochet wrote:Since when you install a user script Greasemonkey will know where it comes from we can just store that then. I also don't like the idea of adding a bunch of extra meta keys, but @homepage(equivalent to your @website) might not be that bad of an idea. A link in the manage scripts dialog to go to that page to get more info about a script might me useful. Rycochet wrote:That'd take care of the problem of overwriting scripts, but I don't know how memory intensive it is to generate hashes from a user script's source in Javascript so it might not be worth it. Rycochet wrote:changing the GM UI is a completely different issue, but I agree it would really be nice to have better GM integration in Firefox. lazyttrick wrote:Yeah that can be a problem. Anyone who wants to get all the ideas will have to read the entire topic and as the topic grows the more difficult of a task that will become. This topic has already been linked to in the related GM issue so hopefully these ideas will become of some use. I don't really have the extension development experience to initiate anything myself, so I've just got to wait for someone else get the ball rolling before I can hope to contribute any actual code. |
![]() ![]() |
lazyttrick wrote:Your updater is just fine just a different approach. Everyone here should realize that it is still up to the end user on what they choose. I would hope that I've made this very clear throughout all of the discussions over the last year. I try my best to help everyone when I can with another viewpoint. Constructive criticism is a good thing until someones ego gets in the way and feelings get hurt. I do my best to choose words carefully but sometimes that's not enough to convey what is meant. The spirit of collaboration is to figure out what needs improvement... not to argue "my way or the highway". lazyttrick wrote:I'm already to the point where I'm going to need to reread it again and again. sizzlemctwizzle wrote:They are and eventually it will come to fruition but patience is a virtue. We all have our own pace and being impatient can be a double-edged sword. I still prefer the incremental approach as a lot of things coming down the pipeline are newer to some of us and some aren't. Tim's initial post is out of his impatience with upstream... They will get around to it but there's still a lot of voices to be heard in the meantime. |
![]() ![]() |
Marti wrote:His impatience is valid though. Update checking has been an issue since the very beginning of Greasemonkey, but it is not something that is trivial and can't be done over night. He's right that it is a feature that is simple to implement, but defining how it should be implemented is the difficult part. I think he, like myself and others I assume, would just like a little head-way to be made and discussing the details of this feature is the first step towards that end. Plus there is no harm in suggesting and debating ideas, while we wait for GM devs to get around to it(the issue has already been labeled so that is a good sign). |
![]() ![]() |
sizzlemctwizzle wrote:Did you mean can't?... all the updaters around are there to "fill the void"... It's one of the reasons I'm dedicating more time here than Moz right now. |
![]() ![]() |
Marti wrote:Yes, but I thought my "not" earlier in the sentence took care of that negation for me, but perhaps I'm wrong. I've never been very good with grammar, as you've already been made aware lol. |
![]() ![]() |
sizzlemctwizzle wrote:Okay... I agree the fundamentals of shifting the management dialog to the Mozilla Preferences dialog is a large task but it also has several small steps to come first. I just have to remind myself that there are a lot of good ideas for updating out there. I'm still trying to figure out if updating can ever work cross-browser... but that's not the focus of this topic. The "Defacto Standard" that Aaron has made is a bit incomplete and he's "outies" so that leaves it up to upstream to figure out a way... this includes anyone who has forked GM... this is one of the primary reasons I interact here. The clearer something is made besides "It should just do it" the better. |
![]() ![]() |
I know that the install location is stored in the script (mentioned earlier in the thread too) - however that doesn't really help if the script wasn't installed from the "official" location, ie. the place where the coder puts updates... As an example - person a patches a script and sends it to person b. They like it but won't know about updates to the original script without checking for updates (manually or otherwise)... Now the update scripts, and the various update snippets, all check a known location for the new version - if people using them want to swap to the GM update code then they need to be able to specify that location. If it was easy to check the config.xml for the source location then no doubt the update checkers that are just @required would make use of that and not just link to the uso scripts (sorry if they do, I've only had a quick look). An old link about javascript md5 if here - http://www.myersdaily.org/joseph/javascript/md5... - which shows it's not exactly too slow to use... The homepage/website link isn't just an "update only" idea... Sort of like having an "about" page, but not needing to code it into the source directly ;-) |



