[greasemonkey] Re: [Greasemonkey] Feature: User scripts with HTML configuration?

Michael Bierman greasemonkey at thebiermans.net
Tue Jun 7 10:42:03 EDT 2005


 

I kind of like the about:config idea.  I had suggest this a few months
back... On the other hand, this provides a pretty direct and obvious way of
interacting with GM and setting preferences.  

I would hope that Advanced users could still edit the script directly as
they do now?

Michael


-----Original Message-----
From: greasemonkey-bounces at mozdev.org
[mailto:greasemonkey-bounces at mozdev.org] On Behalf Of Simon Willison
Sent: Monday, June 06, 2005 5:51 AM
To: greasemonkey at mozdev.org
Subject: [greasemonkey] Re: [Greasemonkey] Feature: User scripts with HTML
configuration?


On 6 Jun 2005, at 08:34, Nikolas Coukouma wrote:
> I agree that it's a pain (and inefficent) to store everything in 
> strings. Other people have brought it up before, and that's why I've 
> suggested/planned for "HTML overlays" and bundling (zip/xpi/jar).

Once we introduce bundling, what's the difference going to be between
Greasemonkey scripts and a full Firefox extension?

(The following is stream-of-consciousness stuff)

On the subject of preferences, it seems people are averse to "rolling their
own" preference UI using HTML appended to the page. This isn't that
surprising - the problem with adding HTML to an existing page using
Greasemonkey is that the page's style inevitably clash with the new
elements, and over-riding all of them is a non-trivial task.  
Embedding a UI in an IFRAME (as mentioned earlier on this thread) is
certainly possible, but it doesn't sound like much fun.

An alternative approach would be some kind of built-in support in
Greasemonkey for automatically generating pleasant user preference
interfaces. Konfabulator has something like this - when you create a
Konfabulator widget you can define some preference names; Konfabulator then
provides a very simple interface for the user to change these.

At its simplest, the feature could work something like this:

@prefs username,password

Greasemonkey would then maybe add a preference button to the script
management UI, which when clicked would pop up a simple dialog box thing
with two fields. Very simple, but already a problem has
emerged: we don't want an interface that displays passwords in the clear! A
modification could look like this:

@prefs username[text],password[password]

Now we've added syntax to simply define different types of field - but
extending it to cover things like radio buttons and select boxes would be a
nuisance. Not to mention we've invented a new metadata tag that /really/
isn't metadata (and we know how controversial metadata is anyway).

Another way of doing it would be adding a // UserPrefs block:

/*
==UserPrefs==
Username: <input type="text" name="username">
Password: <input type="password" name="password"> Favourite colour: <select
name="colour"><option>red</ 
option><option>blue</option></select>
==/UserPrefs==
*/

That's pretty weird as well. We're sort-of using HTML (we could use XML
here, or some new custom format) and we're sort of but not quite following
the format used by the ==UserScript== block.

I suppose the questions this lot brings up are:

1. Should Greasemonkey provide some kind of preference UI framework, or are
GM_setValue and GM_getValue good enough?

2. If yes to 1, what should it look like?

Here are the answers from my point of view:

1. Yes - there are SO many scripts that would benefit from a preference UI
(anything that could do with saving a username/password combo for example -
basically any script that wants to integrate with someone's user accounts on
one or more web applications) and creating HTML interfaces for them is a
royal nuisance - and a huge duplication of effort.

2. I have no idea. I don't like either of the solutions I proposed above.

Cheers,

Simon
_______________________________________________
Greasemonkey mailing list
Greasemonkey at mozdev.org
http://mozdev.org/mailman/listinfo/greasemonkey







More information about the Greasemonkey mailing list