I've been slowly working on a branch for automatic update checking of
scripts for awhile now: https://github.com/sizzlemctwizzle/greasemonkey/compare/master...issu... and I feel like I finally have something worth presenting to others.
Test this in a clean profile because I have no clue how unstable it
might be.
Only script that have an update url stored are able to have automatic
update checking. Since upgrading to 0.9.0 any scripts that you have
installed had their install url saved(unless you installed it
locally). You can optionally override this by pointing to a url with
the @updateURL metakey in the script. For scripts that are capable of
update checking, basically there is a minimum number of days to wait
between update checks of a script, which is a preference you can
modify in the Greasemonkey preferences dialog. If this certain amount
of time passes after the last update check and the script is injected
into the page, then Greasemonkey will fetch the remote version number
and compare it to the version number stored locally. If the remote
number is greater, then the script will be marked that an update is
available. Scripts that have available updates can be seen by going to
the "Updates" tab in the addons manager. The will appear along-side
any extensions that have available updates. Here you can select which
scripts(or extensions) you'd like to update by clicking the checkbox
next to each script. Then you can install the updates of all the
selected scripts. Or you can individually install the updates via the
context menu. If you have any scripts with available updates at
startup, the addons manager will open automatically and display the
scripts that have updates. I think handling script updates just like
another type of extension makes a lot of sense, so this is what I'm
going for with the UI.
Obviously, none of this will work in Firefox 4 because of the
different UI, but I hope to start work on that as soon as this gets
more stable in Firefox 3(and greater). Please try out my build,
perhaps review by code(the changes in this branch are numerous), and
let me know what you think!
> Obviously, none of this will work in Firefox 4 because of the > different UI
First, thanks for your work this is awesome. But a pointer: In the future, I think it would be wise to target FF4 first, not last, for new features. Pretty much the day it's released, FF3 support will be significantly less important, and even if it never happens, nobody loses anything, they just have to upgrade to get new features.
As is, I'd generally refuse to merge this simply because I don't want to release this feature, then Firefox 4 comes out and everyone loses it.
On Thu, Feb 17, 2011 at 06:16, Anthony Lieuallen <arant...@gmail.com> wrote: > On 02/16/11 22:40, sizzlemctwizzle wrote:
>> Obviously, none of this will work in Firefox 4 because of the >> different UI
> First, thanks for your work this is awesome. But a pointer: In the future, > I think it would be wise to target FF4 first, not last, for new features. > Pretty much the day it's released, FF3 support will be significantly less > important, and even if it never happens, nobody loses anything, they just > have to upgrade to get new features.
> As is, I'd generally refuse to merge this simply because I don't want to > release this feature, then Firefox 4 comes out and everyone loses it.
> -- > You received this message because you are subscribed to the Google Groups > "greasemonkey-dev" group. > To post to this group, send email to greasemonkey-dev@googlegroups.com. > To unsubscribe from this group, send email to > greasemonkey-dev+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/greasemonkey-dev?hl=en.
On Feb 17, 4:40 am, sizzlemctwizzle <medleym...@gmail.com> wrote:
> For scripts that are capable of
> update checking, basically there is a minimum number of days to wait
> between update checks of a script, which is a preference you can
> modify in the Greasemonkey preferences dialog.
Someone over at userscripts.org had a different logic that worked like
this IIRC:
* Set a maximum amount of days to wait before checking for updates.
Let's say the user picks five days.
* After five days an update check is done, and an update is found.
* timeToNextUpdateCheck is now set to a few hours.
* After a few hours an update check is done, and NO update is found.
* timeToNextUpdateCheck is increased to half a day.
* As long as no updates are found timeToNextUpdateCheck will continue
to increase until it reaches the user's maximum setting. If an update
is found it is reset back to a few hours.
The reason behind this logic was that development on user scripts is
usually done in sprints. So when the script author takes time to
update the script it's likely there will be another update again soon.
And if there hasn't been an update in a long time (user's maximum
setting) there will probably not be an update anytime soon again.
On Feb 24, 12:35 am, Tobbe Lundberg <to...@tlundberg.com> wrote:
> Is this anything you'd like to implement?
That's an exponential backoff and it can still be incorporated into my
branch. Currently an update check takes place whenever a script is
executed and a constant interval of time has past since the last
update check. An exponential backoff could be used in place of that
constant interval if that's what people want.
