User:Joeytwiddle: Difference between revisions

From GreaseSpot Wiki
Jump to navigationJump to search
No edit summary
No edit summary
Line 1: Line 1:
I have various suggestions for Greasemonkey development below.
= GrimeApe - an HTTP Proxy acting like Greasemonkey =
= GrimeApe - an HTTP Proxy acting like Greasemonkey =


I recently wrote an emulation of Greasemonkey in a proxy, so that userscripts would run in Konqueror.  It's called GrimeApe and can be found at http://hwi.ath.cx/
I recently wrote an emulation of Greasemonkey in a proxy, so that userscripts would run in Konqueror.  It's called GrimeApe and can be found at http://hwi.ath.cx/


= Suggestions for Greasemonkey development =
= Library Userscripts and Dependencies =


== Library Userscripts and Dependencies ==
== Suggestion: @depends metadata ==


It could be useful to have an extra meta tag:
It could be useful to have an extra meta tag:


{{Samp |1=<pre style="border: none; margin: inherit;">
{{Samp |1=<pre style="border: none; margin: inherit;">
// @loadlib    script_name
// @depends    jims_js_library>=2.0
// @depends    temporary_iframes, floating_widgets>=1.2.5
//  or
// @loadlib    <script_name>
</pre>}}
</pre>}}


The loadlib meta would cause Greasemonkey to load the specified script from the user's gm_scripts/ folder before running the userscript which contained the meta.
The @depends meta would cause Greasemonkey to load the specified script from the user's gm_scripts/ subfolder before running the userscript which contained the meta.


This would allow us to define a library script of common functions which we can re-use in any of our userscripts, simply by adding the meta.  These library scripts are always loaded from a trusted source, they are local userscripts which do nothing when run alone.
This would allow us to define a library script of common functions which we can re-use in any of our userscripts, simply by adding the meta.  These library scripts are always loaded from a trusted source, they are local userscripts which do nothing when run alone.
The @version of the target library scripts could be checked against the conditions defined by >= in @depends.  The user or the update system could be informed if the requirements are not met.


:Sounds like a good start to a feature request in case the sandbox isn't ever expanded... you may wish to enter an enhancement ticket at http://greasemonkey.devjavu.com/newticket with this instead of the wiki talk pages.  It will get the proper attention there. [[User:Marti|Marti]] 04:46, 7 June 2009 (EDT)
:Sounds like a good start to a feature request in case the sandbox isn't ever expanded... you may wish to enter an enhancement ticket at http://greasemonkey.devjavu.com/newticket with this instead of the wiki talk pages.  It will get the proper attention there. [[User:Marti|Marti]] 04:46, 7 June 2009 (EDT)
::Thanks Marti, I see that is where the development discussion is.  The greasemonkey-dev mailing list is to be overwhelmed with user-like questions!


Thanks Marti, I see that is where the development discussion is.  The greasemonkey-dev mailing list looks a bit overwhelmed by what look to me like user questions!
== Current techniques for loading library userscripts ==
 
A richer and more useful tag might look something like:
 
{{Samp |1=<pre style="border: none; margin: inherit;">
// @depends    jims_js_library>=2.0
// @depends    temporary_iframes, floating_widgets>=1.2.5
</pre>}}
 
The @version of the target library scripts could be checked against the requirements defined in @depends.  The user or the update system could be informed if the requirements are not met.
 
=== Current techniques for Library Userscripts ===


It is already possible to use userscripts as libraries by a couple of techniques:
It is already possible to use userscripts as libraries by a couple of techniques:


==== Pre-embed with GM ====
=== Pre-embed with GM ===


Have one userscript load early, and let it embed some new JS functions into the unsafeWindow.  Later userscripts may check the window to see if the functions it wants to use are available.
Have one userscript load early, and let it embed some new JS functions into the unsafeWindow.  Later userscripts may check the window to see if the functions it wants to use are available.
Line 40: Line 37:
Or create an Object full of useful functions, and embed it in the DOM.  Any userscripts which execute later could reference the object to make use of those functions.  Unfortunately this raises security issues since untrusted scripts can access that globally visible object too.  (Maybe we can force our library to drop GM internals from our scope, using fn.toString() for example.)  We would somehow need to ensure the library scripts run first, and that they run on all pages where one of their dependent scripts will run.
Or create an Object full of useful functions, and embed it in the DOM.  Any userscripts which execute later could reference the object to make use of those functions.  Unfortunately this raises security issues since untrusted scripts can access that globally visible object too.  (Maybe we can force our library to drop GM internals from our scope, using fn.toString() for example.)  We would somehow need to ensure the library scripts run first, and that they run on all pages where one of their dependent scripts will run.


==== Load-on-demand via http ====
=== Load-on-demand via http ===


When we want to load a library and it is not already in the page.  Add a new script element to the page, with src attribute pointing to a publically visible http URL where the library userscript is located.  Whether the functions from the loaded script become immediately visible depends.  It seems to work fine when done with Bookmarklets in Firefox3.5, but some other browsers may need to wait (via a setTimeout or scriptElement.onload) *before* the loaded functions will become visible to running code.
When we want to load a library and it is not already in the page.  Add a new script element to the page, with src attribute pointing to a publically visible http URL where the library userscript is located.  Whether the functions from the loaded script become immediately visible depends.  It seems to work fine when done with Bookmarklets in Firefox3.5, but some other browsers may need to wait (via a setTimeout or scriptElement.onload) *before* the loaded functions will become visible to running code.
Line 54: Line 51:
[This could be seen as using a Userscript more like a Bookmarklet.  It can work over a large range of websites, but we usually prefer it disabled.  Occasionally we want to enable it for one page, or for a while during a browsing session.]
[This could be seen as using a Userscript more like a Bookmarklet.  It can work over a large range of websites, but we usually prefer it disabled.  Occasionally we want to enable it for one page, or for a while during a browsing session.]


== GM_clearStyle ==
= GM_clearStyle =


It is common that you want your userscript to add some floating menus or windows on top of the page.  Unfortunately these will often inherit CSS rules from the page, and your added elements can end up with strange colours and alignment.  It would be handy to break out of page style settings and create elements using a default empty stylesheet.  How might this be possible?  Can we literally move to a fresh CSS namespace?  Or do we need something like this?
It is common that you want your userscript to add some floating menus or windows on top of the page.  Unfortunately these will often inherit CSS rules from the page, and your added elements can end up with strange colours and alignment.  It would be handy to break out of page style settings and create elements using a default empty stylesheet.  How might this be possible?  Can we literally move to a fresh CSS namespace?  Or do we need something like this?
Line 60: Line 57:
{{Samp |1=<pre style="border: none; margin: inherit;">GM_clearStyle(node_element,bool_clearChildren);</pre>}}
{{Samp |1=<pre style="border: none; margin: inherit;">GM_clearStyle(node_element,bool_clearChildren);</pre>}}


== Tracking Installed Scripts Source URL (and updates) ==
= Tracking Installed Scripts Source URL (and updates) =


I often want to visit the homepage of a script I have installed, but the author didn't include it.  I would like Greasemonkey to make a record of the update URL and the homepage of a script when I install it.  We could insert the meta tags if they were not included by the author, or inaccurate.  There are update scripts which try to track scripts, but shouldn't it be supported?
I often want to visit the homepage of a script I have installed, but the author didn't include it.  I would like Greasemonkey to make a record of the update URL and the homepage of a script when I install it.  We could insert the meta tags if they were not included by the author, or inaccurate.  There are update scripts which try to track scripts, but shouldn't it be supported?


== What is Namespace good for? ==
= What is Namespace good for? =


Finally a thought on logging and @namespace.  The only standard I have really seen @namespace used for is to provide the homepage of the script or the author in @namespace.  Should this be officially declared as the intention of @namespace?  And since these URLs are often long, does it really make sense to make them part of the headers of log messages?  Wouldn't just the name of the script be more appropriate when reading the log?
Finally a thought on logging and @namespace.  The only standard I have really seen @namespace used for is to provide the homepage of the script or the author in @namespace.  Should this be officially declared as the intention of @namespace?  And since these URLs are often long, does it really make sense to make them part of the headers of log messages?  Wouldn't just the name of the script be more appropriate when reading the log?


== Contra Development ==
= Contra Development =


I'm actually quite happy that Greasemonkey has kept its API small, this can accommodate wider compatibility.  I think any additions to the API should be discussed over time by developers and users.  I was wondering whether the developers were intending to extend Greasemonkey in the future, or have decided to keep it small and tidy, and leave the addition of features (aka bloat) to other projects.
I'm actually quite happy that Greasemonkey has kept its API small, this can accommodate wider compatibility.  I think any additions to the API should be discussed over time by developers and users.  I was wondering whether the developers were intending to extend Greasemonkey in the future, or have decided to keep it small and tidy, and leave the addition of features (aka bloat) to other projects.

Revision as of 18:55, 7 August 2009

I have various suggestions for Greasemonkey development below.

GrimeApe - an HTTP Proxy acting like Greasemonkey

I recently wrote an emulation of Greasemonkey in a proxy, so that userscripts would run in Konqueror. It's called GrimeApe and can be found at http://hwi.ath.cx/

Library Userscripts and Dependencies

Suggestion: @depends metadata

It could be useful to have an extra meta tag:

Template:Samp

The @depends meta would cause Greasemonkey to load the specified script from the user's gm_scripts/ subfolder before running the userscript which contained the meta.

This would allow us to define a library script of common functions which we can re-use in any of our userscripts, simply by adding the meta. These library scripts are always loaded from a trusted source, they are local userscripts which do nothing when run alone.

The @version of the target library scripts could be checked against the conditions defined by >= in @depends. The user or the update system could be informed if the requirements are not met.

Sounds like a good start to a feature request in case the sandbox isn't ever expanded... you may wish to enter an enhancement ticket at http://greasemonkey.devjavu.com/newticket with this instead of the wiki talk pages. It will get the proper attention there. Marti 04:46, 7 June 2009 (EDT)
Thanks Marti, I see that is where the development discussion is. The greasemonkey-dev mailing list is to be overwhelmed with user-like questions!

Current techniques for loading library userscripts

It is already possible to use userscripts as libraries by a couple of techniques:

Pre-embed with GM

Have one userscript load early, and let it embed some new JS functions into the unsafeWindow. Later userscripts may check the window to see if the functions it wants to use are available.

Or create an Object full of useful functions, and embed it in the DOM. Any userscripts which execute later could reference the object to make use of those functions. Unfortunately this raises security issues since untrusted scripts can access that globally visible object too. (Maybe we can force our library to drop GM internals from our scope, using fn.toString() for example.) We would somehow need to ensure the library scripts run first, and that they run on all pages where one of their dependent scripts will run.

Load-on-demand via http

When we want to load a library and it is not already in the page. Add a new script element to the page, with src attribute pointing to a publically visible http URL where the library userscript is located. Whether the functions from the loaded script become immediately visible depends. It seems to work fine when done with Bookmarklets in Firefox3.5, but some other browsers may need to wait (via a setTimeout or scriptElement.onload) *before* the loaded functions will become visible to running code.

There may be other techniques...

Immediate loading of enabled script

When we bring up the monkey's menu to turn on a script which was un-checked (disabled), we then have to reload the page, for it to be applied. Why?! Since userscripts are not run until after the page has loaded, couldn't GM run the activated script immediately, without the need for a page refresh?

(You don't necessarily need a full Reload. Navigating to the current page via a link or by URL bar -> Enter should be enough. However I tend to naturally hit Ctrl+R or the Reload icon, although this causes a full reload which is significantly slower.)

[This could be seen as using a Userscript more like a Bookmarklet. It can work over a large range of websites, but we usually prefer it disabled. Occasionally we want to enable it for one page, or for a while during a browsing session.]

GM_clearStyle

It is common that you want your userscript to add some floating menus or windows on top of the page. Unfortunately these will often inherit CSS rules from the page, and your added elements can end up with strange colours and alignment. It would be handy to break out of page style settings and create elements using a default empty stylesheet. How might this be possible? Can we literally move to a fresh CSS namespace? Or do we need something like this?

Template:Samp

Tracking Installed Scripts Source URL (and updates)

I often want to visit the homepage of a script I have installed, but the author didn't include it. I would like Greasemonkey to make a record of the update URL and the homepage of a script when I install it. We could insert the meta tags if they were not included by the author, or inaccurate. There are update scripts which try to track scripts, but shouldn't it be supported?

What is Namespace good for?

Finally a thought on logging and @namespace. The only standard I have really seen @namespace used for is to provide the homepage of the script or the author in @namespace. Should this be officially declared as the intention of @namespace? And since these URLs are often long, does it really make sense to make them part of the headers of log messages? Wouldn't just the name of the script be more appropriate when reading the log?

Contra Development

I'm actually quite happy that Greasemonkey has kept its API small, this can accommodate wider compatibility. I think any additions to the API should be discussed over time by developers and users. I was wondering whether the developers were intending to extend Greasemonkey in the future, or have decided to keep it small and tidy, and leave the addition of features (aka bloat) to other projects.