Manage User scripts

[SpaceMonkey]

Hi,

Let me firstly state that i know less than nothing about programming,
the finer working of a computer or how Greasemonkey and Scripts
work....i just enjoy the fact that they do............

all this seems to of changed.

Previously i simply right-click on greasemonkey, manage user script
and then i could add or remove pages from my chosen script...easy
peasy japaneesy.

Now it seems..that from the other discussions and the endless
programmer talk (that i do not understand) that i have to start
physically typing things/changing things??

is this correct or is there a trick im missing to add/remove/block
certain pages from my script?

i use GreaseMonkey and scripts for a MMORPG..and it previously worked
like a dream.

i appreciate that this is technically a repost...but i was kind of
hoping that someone on here would humour me and others with a
"laymans" version

thanks for your time

[Matt Sargent]

This is now done by directly editing the scripts. Easiest way to bring
up a script in your editor of choice, is to right-click the Monkey icon
in the status bar, then right-click on the script you want to edit.
Editing the script directly is now the only way to add includes and
excludes, and these custom edits will be lost should you install an
update to the script, so keep a copy elsewhere. Also, should your script
be in UTF-8 format (recommended), and your editor converts it to an
unsupported code page, your script could break, as happened to me.

[Anthony Lieuallen]

On Sat, Feb 5, 2011 at 12:41 PM, SpaceMonkey <stu...@yahoo.co.uk> wrote:

is this correct or is there a trick im missing to add/remove/block
certain pages from my script?

http://wiki.greasespot.net/Greasemonkey_Manual:Script_Management

[GrayFace]

What was the reason for the change?

[Dave Land]

On Feb 7, 2011, at 7:39 AM, GrayFace wrote:

> What was the reason for the change?

I'm sure that the august Anthony Lieuallen (frequent contributor to this
list and quite possibly the World's Leading Authority on the inner
workings of GM's code) could answer this in more depth, but it appears
from my reading of the long, long history of this change over on the
greasemonkey-dev list[1] that there were several reasons for this
change:

-- The feature was all but unused by any but the most technical
users, who represent a tiny sliver of the overall GM user base.

(Comment: Technical users are the ones most likely to promote
GM and make it more useful by writing user scripts. I saw this
point mentioned once or twice in the gm-dev discussions of the
change, but it didn't carry the day.)

-- I gather that some sensed that the UI of GM was too complicated
for the majority of "casual" users.

(Comment: Those of us griping on gm-users about this lost feature
may disagree, but we didn't "vote" when this was being argued on
gm-dev. Apparently, "you snooze, you lose" is the order of the
day. Then again, I have contributed not a single line of code to
GM itself, and in the open source software world, only
committers get a vote. Users can go fish. If you _really want to
feel like a second class citizen, try complaining about some
lost feature in Google Chrome: those developers are openly
hostile to any and all user input.)

-- Other browsers' "GM-like" features (such as Google Chrome's
support for user scripts as a kind of "poor man's extension") do
not maintain a separate database of includes and excludes (as GM
has done 'til now, in the form of the config.xml file) but
require "technical" users who want to change which sites a
script addresses to find and modify the scripts themselves.

(Comment: For as long as I've used Chrome, I have found this to
be the most irritating feature of Chrome's User Script support.
When I decide to update a script, I have to remember to save the
header out of the old version, then install the new version,
then edit the new version, etc, etc, etc. Very, very weak. GM
was light-years ahead on this, and has now fallen back into the
middle of the pack, as far as I'm concerned.)

-- Maintaining a database (in the form of config.xml) of includes
and excludes that is separate from the scripts themselves is
considered to be some sort of "bad form".

(Comment: Mixed feelings about this one — keeping the data
separate from the script is a bit awkward, but it did insulate
users from script updates losing their customizations.)

I hope this helps. If I got it terribly wrong, I hope that someone who
knows the arguments better than I do will correct me.

1. http://groups.google.com/group/greasemonkey-dev

[Anthony Lieuallen]

On 02/07/11 13:31, Dave Land wrote:
> there were several reasons for this change

Generally correct. Plus the long standing issue of the strange fact
that Greasemonkey would always re-load changed source code, but not
changed metadata, when the file is (e.g.) edited. Now, any change to
the whole file is read and used, including adding a @resource or
@require (a feature that I find very useful).

> I have contributed not a single line of code to
> GM itself, and in the open source software world, only
> committers get a vote

The tone of your message was overly adversarial, and that's not helpful.
We're all volunteers here, cheerfully giving away our time and asking
nothing in return.

Towards that end, you might note that there are 474 members of the -dev
list, while there have only been 30 committers to Greasemonkey over its
entire life (quick'n dirty count from git commit log, it might be off a
tad). You don't have to write code to participate. I try very hard to
make sure discussion happens on the -dev list, so that everyone can
weigh in.

There's also 2270 members on this (-users) list, and this change was
revealed via a preview build here, no later than November 27th, 2010
[1]. There was a little back and forth, mostly with one user that
didn't understand at first, then said "Oh wow. This is a good change."
Again, I always try to include the community, but my time is valuable,
so there's only so much I can do.

[1] http://groups.google.com/group/greasemonkey-users/msg/67f049a81103608c

[Mr Warper]

Hi everyone,

Dave Land escribi�:

> On Feb 7, 2011, at 7:39 AM, GrayFace wrote:

...

> I'm sure that the august Anthony Lieuallen (frequent contributor to this

...

> workings of GM's code) could answer this in more depth, but it appears

...

> greasemonkey-dev list[1] that there were several reasons for this change:
>
> -- The feature was all but unused by any but the most technical
> users, who represent a tiny sliver of the overall GM user base.

...

> -- I gather that some sensed that the UI of GM was too complicated
> for the majority of "casual" users.

...

> -- Other browsers' "GM-like" features (such as Google Chrome's
> support for user scripts as a kind of "poor man's extension") do
> not maintain a separate database of includes and excludes (as GM

...

> (Comment: For as long as I've used Chrome, I have found this to
> be the most irritating feature of Chrome's User Script support.
> When I decide to update a script, I have to remember to save the
> header out of the old version, then install the new version,
> then edit the new version, etc, etc, etc. Very, very weak. GM
> was light-years ahead on this, and has now fallen back into the
> middle of the pack, as far as I'm concerned.)

Completely agreed on that, but I can see all of the above points, an I share
them to a certain extent.

> -- Maintaining a database (in the form of config.xml) of includes
> and excludes that is separate from the scripts themselves is
> considered to be some sort of "bad form".

...

> I hope this helps. If I got it terribly wrong, I hope that someone who
> knows the arguments better than I do will correct me.

Not me, certainly.

As I see it, GM shouldn't modify any files on its own, so editing the scripts
without user intervention (i.e. when updating, to keep old includes and
excludes) is a no-no; OTOH GM developers don't want to keep the
includes/excludes data in a database separate from the scripts--well, I'm not
completely OK with that, but I could live with it if...

What GM could do (or the developers be kindly asked to implement) to make
everyone lives' easier when being updated, OR updating scripts is to compare the
old include/exclude rules, either from the XML DB or scripts themselves, with
the new ones when updating a script, and tell the user that he needs to manually
update it.

Just an idea.

Regards,

[Anthony Lieuallen]

On 02/07/11 14:18, Mr Warper wrote:
> As I see it, GM shouldn't modify any files on its own, so editing the
> scripts without user intervention (i.e. when updating, to keep old
> includes and excludes) is a no-no

I agree.

> ... GM could ... tell the user that he needs to manually update it.

Let's say that a site rearranges their URL structure, and there's an
update to a script, to change the old @includes to match the new URLs.

Should the user be bothered about this? The list of includes in the
installed script, and the new script to be installed, are different.

[Dave Land]

On Feb 7, 2011, at 11:00 AM, Anthony Lieuallen wrote:

> On 02/07/11 13:31, Dave Land wrote:
>> there were several reasons for this change
>
> Generally correct. Plus the long standing issue of the strange fact
> that Greasemonkey would always re-load changed source code, but not
> changed metadata, when the file is (e.g.) edited. Now, any change to
> the whole file is read and used, including adding a @resource or
> @require (a feature that I find very useful).

Thank you: This sounds like the strongest argument for the change.
Sorry I didn't acknowledge it before.

>> I have contributed not a single line of code to
>> GM itself, and in the open source software world, only
>> committers get a vote
>
> The tone of your message was overly adversarial, and that's not
> helpful. We're all volunteers here, cheerfully giving away our time
> and asking nothing in return.

Similarly, I found your responses to be overly defensive, hence
equally unhelpful. Maybe we can just lay that to rest? I've tried to
express my appreciation in every message in this thread, though
apparently without benefit.

If I come across as adversarial, I am a "no compromises" user
experience guy. I side with end-users to the perpetual annoyance of
developers whose job I make harder in the process :-). Having worked
at Apple in the '90s, perhaps I too strongly embraced the company's
"no compromises" mentality of those days.

> Towards that end, you might note that there are 474 members of the -
> dev list, while there have only been 30 committers to Greasemonkey
> over its entire life (quick'n dirty count from git commit log, it
> might be off a tad). You don't have to write code to participate.
> I try very hard to make sure discussion happens on the -dev list, so
> that everyone can weigh in.

I recently joined the -dev list, will try to contribute there, as
kindly as possible. I hope my opinions won't always be viewed as
overly adversarial.

Dave

[Sam L]

I had some code that would write met-data out to a script, it was to preform a revert if the script was edited in such a way to cause a metadata conflict with script id (i1146).  A simple way to look at this problem would be custom includes that were user defined are @user_include, these are then maintained during script update, I'd prefer something more cryptic like %include or +include, some way to make metadata lines stick through an update, maybe even blocked from being in a script that's installing.  There are other ways to know if a script was user included to store an attribute in XML.  To the developer it doesn't matter if all their includes are listed as user included in xml, since removing a user include is still very much possible.  In any case it was the opposite function of readmetadata that I created and it worked pretty great as far as I tested I was hoping it would be used on this problem.  I wasn't happy that this would be happening but there wasn't much that I could do to stop it.  As long as we know we are dealing with opinions then one can expect all sorts of conflicts.  When someone believes something is wrong if they aren't adversarial enough then problems slip through and compound.  Some scripts ask their users to add new includes, it may be a small number, but if someone does a lot of work on includes then it can be a major issue doing it again, especially if they still loose it the next time, I thought this would severely discourage updating scripts since some level of trust about update capability could have easily been lost, since updating script you would never loose the include, the script author might encourage it while also encouraging custom includes, making the author seem insane for suggesting that if nothing else.  At this point many people will not update certain scripts again, or might complain to the author.  A feature such as update all scripts seems very dangerous at this point.  

[Lil Devil]

On Feb 5, 9:41 am, SpaceMonkey <stue...@yahoo.co.uk> wrote:
> Previously i simply right-click on greasemonkey, manage user script
> and then i could add or remove pages from my chosen script...
>

> Now it seems... that i have to start
> physically typing things/changing things??

It's telling that out of about 3 million active users of Greasemonkey,
we've only seen a dozen or so users complaining about this change.
That tells us that very few users (less than 0.001%) have a need to
edit the list of sites and/or pages a script runs on.

So let's look at this another way. *Why* do these users need to change
the @includes?

Reading between the lines of some of the complaints, my guess is that
these users are using some website where they want a script to only
run on certain pages, which the script author cannot pre-define. I'll
make a bunch of assumptions here:
1. The website is a game.
2. The game has multiple pages, perhaps for towns or armies or some
other entity.
3. These entities have arbitrary names that are part of the URL.
4. A user wants a script to only run on their own entity, and not on
opposing player's entities.
5. Because of the arbitrary names, there is no way for the script
author to define which pages to run on.
6. So the user must change the meta-data to tell the script which
entities to run on.

Now here's the rub:
7. The user previously used a feature of Greasemonkey (the scripts
dialog) to edit the list of pages the script runs on.
8. That feature of Greasemonkey changed in a way that it is now
undesirable for non-technical users to use.
9. In addition, any changes the user now makes will be lost next time
the script author pushes out an update.

Is there a better way?
YES!
The script author could add a mechanism in the script, where it could
ask the user what entities to run on, and save that list via
GM_setValue. The script would be have an @include to run on the entire
website in question, but then one of the first lines of code would be
a conditional that exits immediately if the document.location is not
on the previously saved list.

The point is, instead of looking at the changes in Greasemonkey, maybe
there are changes that can be made to the script(s) that would
eliminate the problem.

Lil Devil

[Dave Land]

On Feb 7, 2011, at 12:59 PM, Lil Devil wrote:

> Is there a better way?
> YES!
> The script author could add a mechanism in the script, where it could
> ask the user what entities to run on, and save that list via
> GM_setValue. The script would be have an @include to run on the entire
> website in question, but then one of the first lines of code would be
> a conditional that exits immediately if the document.location is not
> on the previously saved list.
>
> The point is, instead of looking at the changes in Greasemonkey, maybe
> there are changes that can be made to the script(s) that would
> eliminate the problem.

Or — and I'm wondering if this is even possible — one or more of us
could write a script or an extension that would let the (vanishingly
few) GM power users restore this functionality. Those of us who don't
like the change can take it upon ourselves to "fix" it, instead of
running down the good people who made Greasemonkey something worth
getting all heated up about.

Dave

[Mr Warper]

On 02/07/11 20:35 Anthony Lieuallen wrote:
> On 02/07/11 14:18, Mr Warper wrote:

...

>> ... GM could ... tell the user that he needs to manually update it.
>
> Let's say that a site rearranges their URL structure, and there's an
> update to a script, to change the old @includes to match the new URLs.
>
> Should the user be bothered about this? The list of includes in the
> installed script, and the new script to be installed, are different.

Of course. I'd prefer to be warned, check it, and realize there's no need to do
anything than the other way round. One easy way to make everyone happy about
this would be an appropriately labeled checkbox in the UI.

[esquifit]

I already suggested this approach a couple of days ago[1], but I'm too
lazy to file a bug. Maybe you want to show more involvement? ;-) I
promise I'll vote for it.

[1] http://groups.google.com/group/greasemonkey-users/msg/e381d40cf27432e3

[Mr Warper]

On Mon, Feb 7, 2011 at 11:35 PM,esquifit wrote:
> On Mon, Feb 7, 2011 at 9:45 PM, Mr Warper <mrwa...@gmail.com> wrote:

...

>> Of course. I'd prefer to be warned, check it, and realize there's no need to
>> do anything than the other way round. One easy way to make everyone happy
>> about this would be an appropriately labeled checkbox in the UI.
>
> I already suggested this approach a couple of days ago[1], but I'm too
> lazy to file a bug. Maybe you want to show more involvement? ;-) I
> promise I'll vote for it.

I missed you suggestion. Anyway, I'm a stranger in a strange land here, so
that's not very likely; I run a version of GM modified to run on SeaMonkey
(which I find more convenient than FireFox) so I have enough issues to take care
of on my own.

[GrayFace]

Thanks for the replies. Honestly, I'm surprised. I thought there was
some important technical reason behind this change.

On 8 фев, 00:31, Dave Land <l...@aol.com> wrote:
> On Feb 7, 2011, at 7:39 AM, GrayFace wrote:
>
> -- The feature was all but unused by any but the most technical
> users, who represent a tiny sliver of the overall GM user base.
>

> -- I gather that some sensed that the UI of GM was too complicated
> for the majority of "casual" users.

Removing the feature hardly makes anyone's life easier. I think
Greasenonkey is used by somewhat technical people anyway, so they
shouldn't get scared by UI simplicity not being taken to extreme. GM
UI was very simple. The number of users of the feature may also be
underestimated.

The new UI has its flaws.
1) Scripts can't be rearranged by dragging, only via context menu.
2) I prefer more compact list of script names used in old version.
3) New version dosn't focus the scripts tab of Extensions window when
I click "Manage scripts", it just sows the Extensions window at the
last visited tab of it. And then, when I open Extensions window to
manage extnsions I get to Greasemonkey scripts tab because it was open
the last time. More clicks for no reason.

> -- Other browsers' "GM-like" features (such as Google Chrome's
> support for user scripts as a kind of "poor man's extension") do
> not maintain a separate database of includes and excludes (as GM
> has done 'til now, in the form of the config.xml file) but
> require "technical" users who want to change which sites a
> script addresses to find and modify the scripts themselves.

Yep, GM is superior to them.

On 8 фев, 01:00, Anthony Lieuallen <arant...@gmail.com> wrote:
>
> Generally correct. Plus the long standing issue of the strange fact
> that Greasemonkey would always re-load changed source code, but not
> changed metadata, when the file is (e.g.) edited. Now, any change to
> the whole file is read and used, including adding a @resource or
> @require (a feature that I find very useful).

Yet, the number of people who change GM's xml manually is a very tiny
fraction of those people that do change includes/excludes, hence
prefer the old way...

Now, here's what I think would be best:
Basically the old way. When a script is updated GM can compare
@includes in script with user's includes. If includes weren't
customized, it can safely use includes from new script. If includes
were customized and have changed in new version of the script, GM
should ask user what to do.

The most disturbing thing in the new version is that it doesn't carry
over the old customizations in terms of editing. I mean, I needed to
change includes for one of scripts and to do so I would have to
manually look them up in some xml found in an unknown location, then
add them into script as @include.

I'm yet to see any advantage of the new version.

WBR,
Sergey Rozhenko

[GrayFace]

On 8 фев, 02:59, Lil Devil <devil.an...@gmail.com> wrote:
>
> It's telling that out of about 3 million active users of Greasemonkey,
> we've only seen a dozen or so users complaining about this change.
> That tells us that very few users (less than 0.001%) have a need to
> edit the list of sites and/or pages a script runs on.

In fact it doesn't. You don't count all the people that silently
rolled back to the old version, complained on local forums or saw
complaints of others and decided not to install new version etc. There
are 2270 registered people here, 3 of them (>0.1%) are complaining in
this single thread.

> So let's look at this another way. *Why* do these users need to change
> the @includes?

I change this for "Black text on white background" script. I apply it
to sites that use white text on black background. Overall, the feature
is used for scripts that don't target a specific site.
And no, there's no better way for such scripts. If they had their own
ways of managing sites (or parts of sites) they are applied to, that
would be a mess I suspect.

[maxfatter]

I just rolled back to the older version for this easy to use feature,
I am a more of visual guy, and not a text editing guy. It's another
one of those decisions that the developer forces a single way of doing
things, instead of giving options to the users.

[shteev]

On 8 фев, 02:59, Lil Devil <devil.an...@gmail.com> wrote:
>
>> It's telling that out of about 3 million active users of Greasemonkey,
> we've only seen a dozen or so users complaining about this change.
>> That tells us that very few users (less than 0.001%) have a need to
>> edit the list of sites and/or pages a script runs on.
>
>In fact it doesn't. You don't count all the people that silently
>rolled back to the old version, complained on local forums or saw
>complaints of others and decided not to install new version etc. There
>are 2270 registered people here, 3 of them (>0.1%) are complaining in
>this single thread.

Without being adversarial, I'd like to add my voice to those users
complaining
about the change.

>> So let's look at this another way. *Why* do these users need to change
>> the @includes?
>
>I change this for "Black text on white background" script. I apply it
>to sites that use white text on black background.

This is precisely what I use Greasemonkey for.

I have a question, tho: clearly, my version of Greasemonkey (which
I *think* is the latest but there seems to be no way to access a
version number) has remembered my list of websites for my 'Change
text background to gray' script; this script is still active on website I
told it to act upon, and only those websites. However, I have no way
of accessing the list or change it now that the 'Manage User Scripts'
option has been moved into Firefox's 'Add-ons' window. Where are they?
--
View this message in context: http://old.nabble.com/Manage-User-scripts-tp30852744p30972449.html
Sent from the GreaseMonkey List mailing list archive at Nabble.com.

[ArmEagle]

In my [profile]\gm_scripts folder I have a file 'config.xml'. That should still have the old settings, until you go and edit/update the script.

[Anthony Lieuallen]

On Sun, Feb 20, 2011 at 2:35 PM, shteev <ento...@hotmail.com> wrote:

I have a question, tho: clearly, my version of Greasemonkey (which
I *think* is the latest but there seems to be no way to access a
version number)

Like all Firefox extensions, the version number is show in the Add-ons dialog.
 

has remembered my list of websites for my 'Change
text background to gray' script; this script is still active on website I
told it to act upon, and only those websites. However, I have no way
of accessing the list or change it now that the 'Manage User Scripts'
option has been moved into Firefox's 'Add-ons' window. Where are they?

The easy way is to (temporarily) downgrade to an 0.8 version of GM, and get the data out with the old UI.  Other ways have already been discussed, and documented:
http://wiki.greasespot.net/Greasemonkey_Manual:Manage_Dialog

[Dexter]

So, now that this useless change has been made definite, how can I
uninstall scrips if they are not showing up when I click on "manage
scripts". All I get is is a blank page on the User Scripts tab on the
addons preferences.

[Matt Sargent]

It's possible they were "uninstalled" for you, as happened to me
yesterday. Every script - wiped out without notice. I was editing one
script, and copying some code from another, using Notepad++. When I
switched back to the file I was editing, I got a message that the file I
was editing no longer existed. Several of the "script" icons were
missing. I tried opening them, and they were gone. When I closed and
reopened the script interface, it was blank. Fortunately, most were
backed up on my installation site, and the 5 scripts in progress could
be recovered thanks to Notepad++'s auto-backup feature.

[Anthony Lieuallen]

Sounds like a bug. Have you read:
http://www.greasespot.net/2011/01/greasemonkey-091-release.html
(known issues)?

[sizzlemctwizzle]

On Feb 27, 4:06 pm, Dexter <dexter.progressive.me...@gmail.com> wrote:
> So, now that this useless change has been made definite,

Oh can assure you the change is far from being useless.

> All I get is is a blank page on the User Scripts tab on the
> addons preferences.

Sounds like you have either All-in-One-Sidebar on Personas installed,
which both cause your scripts not to show up. The scripts have most
likely not been uninstalled.

[sizzlemctwizzle]

On Feb 27, 8:40 pm, Matt Sargent <matt.sarg...@locusprime.net> wrote:
> It's possible they were "uninstalled" for you, as happened to me
> yesterday. Every script - wiped out without notice. I was editing one
> script, and copying some code from another, using Notepad++. When I
> switched back to the file I was editing, I got a message that the file I
> was editing no longer existed. Several of the "script" icons were
> missing. I tried opening them, and they were gone. When I closed and
> reopened the script interface, it was blank. Fortunately, most were
> backed up on my installation site, and the 5 scripts in progress could
> be recovered thanks to Notepad++'s auto-backup feature.

Well that is definitely weird. Haven't had anyone else report an issue
like this before.

[Dexter]

I know that they were not uninstalled as I can see them working and by
right-clicking the icon. I just can't manage them (I am forced to
manually edit the scripts). Yes, I do have both of the addons you
mentioned. Any future plans on fixing the incompatibility between
Greasemonkey and such addons?

[sizzlemctwizzle]

All-in-One-Sidebar will work with Greasemonkey in its next version.
Unfortunately there isn't much we can do to fix compatibility with
Personas, except hope that Mozilla will take the initiative to fix
that problem.

[Anthony Lieuallen]

On 03/03/11 03:03, sizzlemctwizzle wrote:
> Unfortunately there isn't much we can do to fix compatibility with
> Personas, except hope that Mozilla will take the initiative to fix
> that problem.

We have to be a bit dirty with it (it's a dirty problem) but I expect we
can at least work around the issue Personas creates. (On the other
hand, AFAIK that extension's functionality is built into Firefox 3.6+,
so there's no reason to have it installed.)

[sizzlemctwizzle]

On Mar 3, 8:09 am, Anthony Lieuallen <arant...@gmail.com> wrote:
> (On the other hand, AFAIK that extension's functionality is built into Firefox 3.6+,
> so there's no reason to have it installed.)

Yup, totally right. That extension is now redundant.