Userscripts.org

Hey Everyone,

I just wanted to let you all know that I'm forking Greasemonkey, and calling the new extension Scriptish, the first beta is ready now, and I'm nearly ready to release a second beta soon, you can find it here if you are interested: https://addons.mozilla.org/en-US/firefox/addon/...

The minVersion of Firefox I plan to support will be 4.0, so it will only work with 4.0 betas atm.

Some new features that'll be available in 0.1 will be:
- GM_worker (web workers for user scripts, eventually with GM_xhr)
- GM_notification (Growl style notifications)
- clipboard api (next beta)
- @icon or @iconURL
- @author
- @homepageURL
- @screenshot (next beta)
- @contributor
- @version
- @noframes (excludes the user script from running on pages in a iframe)
- @match (Google Chromes @match include syntax)
- reg exp style @includes, example: // @include /^https?:\/\/(www\.)?google\.com.*/

Scriptish is also integrated with the addon manager, as Greasemonkey will be in it's next version, so that may be a surprise to some that try this.

And hopefully some more stuff to make sure it gets through the AMO editor requirement that it not be a total duplicate. Let me know what you think, you can submit issues here: http://github.com/erikvold/scriptish/issues

I hope you give it a try,

Thanks!

Erik Vold wrote:
minVersion of Firefox I plan to support will be 4.0

Erik Vold wrote:
clipboard api (next beta)

Erik Vold wrote:
reg exp style @includes

Erik Vold wrote:
integrated with the addon manager

I'm posting all of my ideas for future releases here: http://github.com/erikvold/scriptish/issues (I just put a few more up) please vote for the ones that you'd like to see and add ones that I haven't posted yet, so that I can get an idea of what other people want.

If you do, may I encourage starting with ditching backwards compatibility with everything that was an unintentional design bug, like the default rule of @include *, and make wchichever forward-looking decisions (in terms of not only design, but also community around it) that you are displeased with with Greasemonkey, so the community as a whole benefits as much as it possibly could from the fork?

The technical decision should come fairly easy, I think, as it means you'll initially get the most technical and pleasant (well, competent), users, scriptwrights and extension developers to switch over first, while leaving Greasemonkey with the progress-deterring user base that have the all the relatively uninteresting (and most frequent problems) with using it, until such time as people update to the better-than-GM GM, on its many merits.

Also, I think you would gain much from borrowing as much of the good design choices as you can from Chrome's (except for their user script UI), like killing @noframes and making that the default behaviour, and instead require @all_frames (or @allframes, if you want to avoid underscores), which will minimize unintentional script funcional and security bugs due to it.

One change you could do that I think would instantly appeal to a large crowd is sandbox-free unprivileged scripts, that can do only (but exactly!) as much as page scripts, with no gotchas -- effortlessly run jQuery and all the other javascript libraries, ideally without requiring any @header keywords for it (again, minimizing unintended security holes, at pretty much no cost to devs) -- as you know, I have spent much time lately hacking on my Github commit history unfold script which works like that, thanks to a magic hack of Anthony's -- and its just tons more fun than it is combatting the hostile Mozilla javascript sandbox environment we still enforce in Greasemonkey. I think that would make an instant crowd-pleaser for scriptwrights.

It might even be worth considering not offering the privileged APIs for a while, as all the cool HTML5 stuff coming fast now is pretty much deprecating what made GM more hackable for devs around the turn of the century.

I don't know about what your own experience with the Github issues system, but unless you like it and find it far less painful than me and Anthony does Github's, you might want to consider following Olivier Cornu's example (maybe after checking in with him about his own experience from WebMonkey) and try out lighthouseapp.com for the fork. I use it a bit at work, and while its integration with github hasn't been perfect in every detail in my experience, it has never been outright annoying to use so far.

Well, that's the off-the-top-of-my-head thoughts -- I hope you'll have lots of fun and keep making awesome software, as you have with Greasemonkey so far. Don't be afraid to hang around still, and the best of luck with the project!

Johan Sundström wrote:
If you do, may I encourage starting with ditching backwards compatibility with everything that was an unintentional design bug, like the default rule of @include *, and make whichever forward-looking decisions (in terms of not only design, but also community around it) that you are displeased with with Greasemonkey, so the community as a whole benefits as much as it possibly could from the fork?

Johan Sundström wrote:
Also, I think you would gain much from borrowing as much of the good design choices as you can from Chrome's (except for their user script UI), like killing @noframes and making that the default behaviour, and instead require @all_frames (or @allframes, if you want to avoid underscores), which will minimize unintentional script funcional and security bugs due to it.

Johan Sundström wrote:
One change you could do that I think would instantly appeal to a large crowd is sandbox-free unprivileged scripts, that can do only (but exactly!) as much as page scripts, with no gotchas -- effortlessly run jQuery and all the other javascript libraries, ideally without requiring any @header keywords for it (again, minimizing unintended security holes, at pretty much no cost to devs) -- as you know, I have spent much time lately hacking on my Github commit history unfold script which works like that, thanks to a magic hack of Anthony's -- and its just tons more fun than it is combatting the hostile Mozilla javascript sandbox environment we still enforce in Greasemonkey.

Johan Sundström wrote:
I think that would make an instant crowd-pleaser for scriptwrights.
It might even be worth considering not offering the privileged APIs for a while, as all the cool HTML5 stuff coming fast now is pretty much deprecating what made GM more hackable for devs around the turn of the century.

Johan Sundström wrote:
I don't know about what your own experience with the Github issues system, but unless you like it and find it far less painful than me and Anthony does Github's, you might want to consider following Olivier Cornu's example (maybe after checking in with him about his own experience from WebMonkey) and try out lighthouseapp.com for the fork. I use it a bit at work, and while its integration with github hasn't been perfect in every detail in my experience, it has never been outright annoying to use so far.

Johan Sundström wrote:
Well, that's the off-the-top-of-my-head thoughts -- I hope you'll have lots of fun and keep making awesome software, as you have with Greasemonkey so far. Don't be afraid to hang around still, and the best of luck with the project!

Very nice! Glad there is some competition now! Not that it really matters! I like both! Just wish it worked on Firefox 3.6.x but that is ok that is a waste of time to do now.

Eric, is there a hack or something that we can do to get Firebug and Scriptish to play nicely with each other in the latest Firefox 4 beta?

Good work, Erik.
My feature suggestions:
- GM_startDownload(url, suggestedFilename, overrideMimeType, fSilent, requestHeaders, callback) - opens the "Save as..." dialog for url; fSilent - just saves the file in the dowload directory specified by the user previously (to save subsequent files without confirmation) or in the default download directory; optional callback for progress and completion
- GM_getClipboard() - disabled by default, enabled per-script
- GM_hookClipboard(callback) - callback when clipboard content changed; disabled by default
- per script permissions for insecure features (clipboard access, silent downloads, download/storage quota)
- GM_getPermissions() - informs the script about permissions granted by user, are desktop notifications turned on/off, etc.
- GM_requestPermissions() - prompts user to grant script a permission
- SQLite for data storage
var db = new GM_SQLite(dbname); db.query(sql); db.close();
- bundle some popular libraries (jQuery, MooTools, underscore.js, php.js)
- userscript access to HttpOnly cookies (GM_cookie interface)

Hello Eric I have installed scriptish with the koc official bot and tools and they wont keep the settings that I make and it crashes firefox regularly also I keep getting certificate verification is there something I can do to get this to work

This is cool! Thanks for sharing!

Is Scriptish still maintained?

Alexo wrote:
Is Scriptish still maintained?

Is it nice? I kinda gave up on trying things until they claim to have V 1.0.0.

If it took 3 years to get from 0.1 to 0.1.8 then 1.0 would be 30 years and 9 months? hehehe

But now I don't know what I'm missing.

Alexo wrote:
Is Scriptish still maintained?

There is Scriptish nightlies BTW
https://github.com/scriptish/scriptish-nightlie...

LouCypher wrote:
There is Scriptish nightlies BTW

The maintainer modified a bunch of issues yesterday. Seemingly abandoned with commits for a long time leaving a very bad user experience.

sizzlemctwizzle wrote:
The last changed…

there are no changes, just updates to the metadata