User talk:Joeytwiddle: Difference between revisions

From GreaseSpot Wiki
Jump to navigationJump to search
m (Undo revision 6483 by Joeytwiddle (talk))
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Suggestions ==
=== Further thoughts on Userscripts Toolbar ===


It could be useful to have an extra meta tag:
Greasemonkey gave userscripts all the powers that Bookmarklets were lacking, persistent state, auto-execute and cross-domain XHR, hooray!  But sometimes I feel that GM has an extra layer of hoops to jump through.  Bookmarklets are quick and flexible.  You don't have to specify which sites a Bookmarklet should load on.  You can be browsing on any website and invoke the Bookmarklet you need when you need it.  (The current GM policy is that users must define which URLs a userscript should run on, before loading the page.  Inconvenient!)


{{Core samp |1=<pre style="border: none; margin: inherit;">// @loadlib    script_name</pre>}}
I sometimes dream about a merger of the two technologies, and in my head it appears like this:


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.
* On every page I surf, Greasemonkey loads up my "Userscript bar".  Initially this is just a little icon (maybe a star or a monkey face) which sits in the corner of the page.  When I click it or mouseover, the bar unfolds.
* Sitting in my userscript bar are all my favourite userscripts.  They each have an icon.  The ones which won't work on this page are greyed out or hidden.  But basically I can click on the icon of a userscript when I want to use it.
* I would imagine these "scriptlets" would meet some standard which would allow them to:
** Maybe run some things at startup:
*** Maybe the user previously re-arranged this page using this scriptlet, and they want the changes applied on all visits.
*** The scriptlet might show meta-info about a page.  It could start loading this in the background, and update its icon to present the results summary, or the full summary when clicked.
*** The scriptlet can take a look at what is on the page, and can disable itself if it cannot be of use here.
** Have a default action when invoked by user click, or a standardized menu drop-down if the scriptlet has multiple features.
** Provide an Icon.
** Still have the ability to respond to @include and @exclude metas, but these will be used slightly less often.
** Provide an unload hook as described elsewhere.  If we have finished using a scriptlet, or it's simply not doing the right thing, we invoke this to unload the script and undo its changes.


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.
What would this achieve?


: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)
* I suggested a richer UI. We can interact with all our Userscripts in a fast way.  They can present us information through their icon and tooltip.  We can just occasionally invoke a rare script that is only useful in odd moments. If it works, we could click [x] Always run on this page or [x] Always run on this site.
 
* I am suggesting these userscripts become more like mini-apps.  Web helper tools, but cheaper than installing a Firefox extension.  If you want, think of it as "My Mashup Toolbar".
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!
* Have you other Linux users noticed how website GUIs running inside the browser window are actually faster than Firefox's own chrome/xul GUI with native Gnome/GTK?! Crazy but true.
 
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.
 
Regarding LibraryUserscripts, I should still think about other ways to do it.  I saw there is a Google project that offers some extra functionality for Greasemonkey scripting of Google Groups data (or was it Google Reader?).  I don't know how this is delivered, maybe it is an object they supply in the DOM for all browsers.
 
It just occurred to me that one existing way of making a library userscript would be to have it 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.
 
-
 
There are other problems I would be interested in solving.
 
ClearingStyle
 
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?
 
{{Core samp |1=<pre style="border: none; margin: inherit;">GM_clearStyle(node_element,bool_clearChildren);</pre>}}
 
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?
 
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?

Latest revision as of 02:45, 13 July 2011

Further thoughts on Userscripts Toolbar

Greasemonkey gave userscripts all the powers that Bookmarklets were lacking, persistent state, auto-execute and cross-domain XHR, hooray! But sometimes I feel that GM has an extra layer of hoops to jump through. Bookmarklets are quick and flexible. You don't have to specify which sites a Bookmarklet should load on. You can be browsing on any website and invoke the Bookmarklet you need when you need it. (The current GM policy is that users must define which URLs a userscript should run on, before loading the page. Inconvenient!)

I sometimes dream about a merger of the two technologies, and in my head it appears like this:

  • On every page I surf, Greasemonkey loads up my "Userscript bar". Initially this is just a little icon (maybe a star or a monkey face) which sits in the corner of the page. When I click it or mouseover, the bar unfolds.
  • Sitting in my userscript bar are all my favourite userscripts. They each have an icon. The ones which won't work on this page are greyed out or hidden. But basically I can click on the icon of a userscript when I want to use it.
  • I would imagine these "scriptlets" would meet some standard which would allow them to:
    • Maybe run some things at startup:
      • Maybe the user previously re-arranged this page using this scriptlet, and they want the changes applied on all visits.
      • The scriptlet might show meta-info about a page. It could start loading this in the background, and update its icon to present the results summary, or the full summary when clicked.
      • The scriptlet can take a look at what is on the page, and can disable itself if it cannot be of use here.
    • Have a default action when invoked by user click, or a standardized menu drop-down if the scriptlet has multiple features.
    • Provide an Icon.
    • Still have the ability to respond to @include and @exclude metas, but these will be used slightly less often.
    • Provide an unload hook as described elsewhere. If we have finished using a scriptlet, or it's simply not doing the right thing, we invoke this to unload the script and undo its changes.

What would this achieve?

  • I suggested a richer UI. We can interact with all our Userscripts in a fast way. They can present us information through their icon and tooltip. We can just occasionally invoke a rare script that is only useful in odd moments. If it works, we could click [x] Always run on this page or [x] Always run on this site.
  • I am suggesting these userscripts become more like mini-apps. Web helper tools, but cheaper than installing a Firefox extension. If you want, think of it as "My Mashup Toolbar".
  • Have you other Linux users noticed how website GUIs running inside the browser window are actually faster than Firefox's own chrome/xul GUI with native Gnome/GTK?! Crazy but true.
Retrieved from "https://wiki.greasespot.net/index.php?title=User_talk:Joeytwiddle&oldid=6486"