Archived Comments (locked)
|
|
The following is an archive of comments made before threaded discussions was implemented (November 16th, 2008) |
|
|
OK.... I wasn't aware of Tarquin's UserScript ts&cs. Thanks for drawing my attention to them. I no longer reccomend using any of his functions in your script obviously... and I'll be sure not to use any in my future scripts either. As for your "Check for updates" button, something like this (link only works in Opera), should be fine. (I know it's not entirely self contained, but I think it's a far nicer feature then GM_registerMenuCommand(), which is unconfigurable, and buried in two menus. how do you keep "whose code you're accessing" straight? One could say the same about the GM_api as with other browser users installing a script, how can you rely on it's existence. The fact is you can't, you simply say "if you don't have the prerequisites (GM_), this script won't work". Outside of that, functions not open to being used by other scripts shouldn't be defined in the global namespace. Edit: Ooops, I forgot this site doesn't allow js links. So the href of that link should read:
opera:/button/Go to page, 'javascript:alert(\'This is an Opera Button\')',1,'Check for UserScript update','Contact32' (also, on '_blank', Opera doesn't really differentiate all that much between windows and tabs as it has always been a true MDI since v1) |
|
|
Okay, between "that post" and the home site of the guy who wrote How many times on these forums have people had to be told "you have to install Greasemonkey to use these scripts" Touché. Again, my experience was colored by the fact that at the time, I was having to educate people about what Greasemonkey is and why people need Firefox and why they can't just stick with IE, etc., ad nauseam; finding that I was going to have yet more to add to the "stuff you need to use this script" list was frustrating. I believe Opera's ability to use multiple scripts is a feature Maybe, maybe not. What happens when Scriptwright A calls function B (either by error, or because he expects Scriptwright B's file to already be there), only to find that for some people, this is invoking Scriptwright C's function B, which may be a poorly written imitation, or worse, may do something completely different? When everybody has access to everybody else's code, how do you keep "whose code you're accessing" straight? I'd be happy with a simple "Check for updates" button instead That's doable, but where can you put it that makes it noticeable and unobtrusive - especially for a "library function" of this sort that has no way of knowing what space is or isn't being used on the page? It'd be nice if Opera had something, anything, for "out of band" script interaction - some UI feature that clearly says, "Hi there, Script speaking - this isn't coming from the page you're viewing, and may or may not be related, but..." Looks like a decent workaround; "_blank" doesn't differentiate between "new tab" and "new window" (or leaves it to the user to choose), but there's nothing official that does, so that's a minor quibble. |
|
|
Firstly, that post is extremely paranoid. People hear cookies and they think "danger" without thinking about it. A script having access to a sites cookies is far more of a security risk than a site having access to a scripts cookies. Please tell me what could be stored in script cookies that would need to be "under the radar". I agree they should operate under the radar in the sense of being unobtrusive, but this is just silly. It's as if they're trying to make this feature difficult to use. This, I think, is a little unfair. Opera is the only browser which has native userscripting, meaning the dev team have other things (like the rest of the browser) to develop as well. Unlike Aaron Boodman and co, who are developing a separate third party extension, something far more focused. Then again, Opera's implementation has been around a little longer, so in fairness it should be more mature at this stage. Although they do seem to be showing more interest recently. you also have to install aa-this.js and aa-that.js Also unfair. How many times on these forums have people had to be told "you have to install Greasemonkey to use these scripts". It is the same thing, you just have a different perspective on it, because as a FF user, you're used to extensions (not all are). Also, while some paranoid people might see this as a security risk (it is potentially, but not a huge one I think), I believe Opera's ability to use multiple scripts is a feature (unlike GM where no script has any access to the other). It makes things a lot more efficient when say an updating engine (hint-hint) was only defined (and parsed) once, and can then be accessed by any script. Consider this at least. Anyway... I'm rambling. Basically what I'm saying is.. thanks for attempting at least to help out us poor neglected Opera users. If the cookie issue annoys you, I'd be happy with a simple "Check for updates" button instead. I'd probably actually prefer a script in multiple parts, it would most likely be more efficient (than repeating code over and over in multiple scripts), and lastly, I notice your GM_openInTab still says
function GM_openInTab(url){
var a=document.createElement('a');
a.href=url;
a.target="_blank";
document.body.appendChild(a);
var e=document.createEvent('MouseEvents');
e.initEvent('click',1,1);
a.dispatchEvent(e);
}
|
|
|
Thank you for your response. your aims here are admirable Not really ;-) - I just heard that it would be really easy to slap an "Opera compatible" label on my original script, but when it came to adding the self-updater, I found maintaining that compatibility to be too much work (since I don't use Opera myself, except for testing these scripts), so I abandoned it, but posted the code up here anyway in case anyone else wanted to hack at it. If it hadn't been for When I was first working on this, I came across this post, and while I don't think it's as big a deal as this guy makes it out to be, I do agree that user scripts should operate "under the radar" as much as possible, and using that other script makes that impossible. This is okay if you know and trust the site being scripted, but in the case of this code, there's no way for me to know which sites it's being used on, so I don't want to be responsible if someone incorporates my script into their own, uses that combined script on some malicious Web site, and ends up with problems because of it. The other thing is, I don't know what you mean by 3 The Opera creators apparently see user scripting (despite the name) as a tool for programmers, not normal people; and so, in their opinion, interaction between scripts is OK, and having script writers needing to issue warnings like, "you also have to install aa-this.js and aa-that.js to get myscript.js to work" is also OK. I strongly disagree with this philosophy. A user script should be like any other program - you download one file and install it and It Just Works. Not only is there not anything resembling a user script installer in Opera, but there isn't even a default location for them, and setting one is considered an "Advanced" operation. It's as if they're trying to make this feature difficult to use. My goal #3 was to allow script writers to add self-updating functionality to their scripts that Just Works - without dependencies on other scripts. GM now has @resource and @require directives which make such dependencies workable without user intervention, but until Opera emulates this functionality, I'd rather stick with having all the code needed in a single file. As for 4, I could live without this. I don't think this should be possible to be honest. Comments are comments are comments, they should never be parsed. I agree that the Greasemonkey creators made a mistake when they designed it this way, but now, 30,000 scripts later, it's a mistake we all have to live with. Also, there's a good chance that the next version of Greasemonkey will make this info available to the script, so hacks like the one I used in the Firefox version will no longer be necessary (at least for Firefox). |
|
|
Firstly, may I say that your aims here are admirable. On your for your attempts at emulating GM functionality... this (quite old) script should help, and this forum topic might shed some light on the xmlhttprequest issue. I don't know if you've come across this before, but judging by all the Obviously much is not possible, just like emulating the As for your 4 listed goals... well you've achieved 1 and 2, and I don't know what you mean by 3.
Good luck with you script. Edit: Ooops.. I just noticed you mention the aa-gm-functions script above already.... which makes me wonder why you haven't used any of it's functions. I understand your dislike of the |