Tim-Smart wrote:
Move Userscripts management to Add-ons dialog

General consensus by a few people, is that Userscripts should be managed within the Add-ons dialog. This would generally be considered as an enhancement feature...

See also:
#1012
#1053
This branch

This issue could probably be marked as Duplicate

This issue could probably be marked as Duplicate

This is going to make things extra painful:
http://mozillalinks.org/wp/2010/04/meet-the-new-firefox-add-ons-manager/
Seems it's not only happening, but pretty soon.

Fail on Mac. The GM icon is displaying in a dialog where there normally are no icons.

We need to add a way for the user to control the order of the scripts. Execution order matters, some scripts will break other scripts.

Firefox no longer has, but used to have, move down/up/top/bottom options on the context menu. I don't know if/how well drag and drop will work for this new dialog.

Ref: Using http://github.com/downloads/arantius/greasemonkey/greasemonkey-2010-05-08-beta.xpi (0.9.0)

• Tooltips in Add-ons Manager under User Scripts (do we have a different name for this btw or is it still going to be called the Manage Dialog?) buttons (Edit, Disable/Enable, Uninstall) incorrectly reflect their actions.
• As mentioned before, in one of the correct issue tickets #1092, but rereferencing here... Adding a script while the Add-ons manager is opened doesn't reflect added script from USO.
• Minor?: When Add-ons dialog is left on something other than User Scripts and closed... middle click and all Manage User Scripts menu items never open to User Scripts (Migrated Profile only... FF, Mr Tech Toolkit and GM is probably getting confused at GM's abstraction in using the Extensions pane object for User Scripts)
• options.xul should include persistence of width and height...e.g. persist="screenX screenY width height"
• Technically speaking the options.xul "dialog" should be a "prefwindow" to support better preference options... but that is really up to upstream if they want to do it the correct way.
• Localization missing in source for addons.js and related dependencies.
• Code styling is inconsistent with other modules. Please pick a standard and stick to it as much as possible... this includes usage of single quotes vs double quotes and spacing. Perhaps upstream could actually comment and define this (again) maybe in Source Code Messy #1036

Nice, quick, job on uninstall preferences and manually changing the editor through the GUI.... I'm +1 for defaulting to true on uninstall associated preferences. I'm always ticking that on in 0.8.x

Again I may add more to this list as time and testing permits.

I prefer not removing prefs on uninstall as default. It provides safety for novice users who might uninstall a script accidentally or change their mind.

Hey Anthony,

I'm not sure if you noticed, but I made a number of of bug fixes to your addonstab on this branch.

Hmm this is going to be interesting. http://mozillalinks.org/wp/2010/04/meet-the-new-firefox-add-ons-manager/ will be released soon, which will require different code. So that means a conditional on the Mozilla / Firefox version, and two areas of maintainability. It will most likely end up breaking Greasemonkey for a short period when the new interface is released, unless a solution is formed and released during the alpha / beta period.

UI changes in Firefox are always going to happen periodically, maybe a dedicated UI for Greasemonkey isn't such a bad idea? Food for thought I guess.

Tim you're bringing up an old issue that Aaron brought up in 2006, everyone knows that already, and we still want this update for obvious reasons.

What we need is a suitable solution..

I've been thinking about the idea of having two UI for managing userscripts, a basic one that we control which would work independently of FF, and a UI that is integrated with the addons management window, which is more advanced perhaps (shows @Version, @ICON, and allows manually updates of userscripts). I'm not in love with this idea.. but it seems like the best option so far imo..

I've been thinking about the idea of having two UI for managing userscripts

Trying to keep this both short and fair: Unless Johan disagrees with me, I'd advise against spending your time on this, because I'll vote strongly against it.

which will require different code. So that means a conditional on the Mozilla / Firefox version, and two areas of maintainability. It will most likely end up breaking Greasemonkey for a short period when the new interface is released, unless a solution is formed and released during the alpha / beta period.

A) Yep, I know, look at my comment from April 30th.
B) This is one change. Over the decade or so that Firefox has existed.
C) There's very straightforward ways (zero code, just in the manifest) to control conditional overlays based on platform version.
D) It will perhaps mean 2x development, but only one will ever have to be maintained. There's only ever one released version of Firefox that will ever change outside of security-related maintenance.
E) I really really really care about this feature. It's happening, unless seriously major opposition arises.

C) There's very straightforward ways (zero code, just in the manifest) to control conditional overlays based on platform version.

Ah, that sounds good enough then.

E) I really really really care about this feature. It's happening, unless seriously major opposition arises

I do as well.

How about replacing the "Edit" button with a "Show" button that when clicked will open up the folder that contains the user.js file? I think this would be more useful since it would allow the user to edit the script in whatever editor they like(without GM having to keep track anymore) and it lets them easily edit dependencies as well.

How about replacing the "Edit" button with a "Show" button

While hacking on my eriks-addonstab branch I noticed that the Edit button's access key 'E' conflicts with the access key for the "Enable" button. So I think that this is a good suggestion.

Okay, the "Edit" button is replaced with a "Show" button that opens up the directory of the user script in this commit.

a "Show" button that opens up the directory the user script

Nice idea!

a "Show" button that opens up the directory of the user script

I'm very mixed on this. In my usage, I want to edit the script something like 95-99% of the time, and the other files almost never. When I do want to edit another file, it's always as easy as a file->open, which starts in that same directory anyway.

I'm loathe to diverge very far from GM's roots which are all about making one file, quickly and simply, to get something done. I'd prefer to keep that (probably much more common) use case very streamlined and straightforward, even if it means the (probably much more rare) multi-file-requires-and-resources use case is slightly more work.

What would you say to leaving the edit button, but adding "show containing folder" to the context menu?

What would you say to leaving the edit button, but adding "show containing folder" to the context menu?

This sounds good to me, two options is better than one, and editing the userscript is going to be the more common use case. But there still is the minor issue of the access key letter.

Access keys, in general, need to be addressed as part of a localization bit that is definitely upcoming.

It looks like we'll be able to have a look at the new addon manager tomorrow.

erikvold wrote
two options is better than one

Probably better that way although it would be nice to have them flippable for developers versus users just to cut down on some clicking. +1

What would you say to leaving the edit button, but adding "show containing folder" to the context menu?

• Major Fail on notifying that a new script is installed when Add-ons manger is opened to another "tab" other than User Scripts... Script is added to that "tab" instead of "User Scripts"... e.g. I was viewing Plugins on clean profile and that's where it added the script... unstriked above list item.
• Adding single script to clean profile, then doing any Move Up, Move Down, Move to top, Move to bottom and Sort Scripts causes massive issues. Those menu items should probably be disabled if script count is 1
• Uninstalling all but one script doesn't show Enable/Disable and Uninstall buttons until leaving "tab" and then reentering. Probably more case instances on this too.

It looks like we'll be able to have a look at the new addon manager tomorrow.

The new addon manager is now in Minefield, check it out when you have a chance.

I wrote this patch to update userscripts in the addons tab when a userscript is modified.

Major Fail on notifying that a new script is installed when Add-ons manger is opened to another "tab" other than User Scripts... Script is added to that "tab" instead of "User Scripts"... e.g. I was viewing Plugins on clean profile and that's where it added the script...

patch

Note: when I 1st created this message the commit patch that I linked to had a style flaw in it, so 30mins after I wrote this msg I corrected that, and the hash was different, so use the patch mentioned here now.

erikvold wrote:
so use the patch mentioned here now.

That seems to have fixed two items... Thanks... still the one a single script causes failures with script order movement (obviously I know better then to do that but bullet proofing it for everyone else is a good thing)

I'll be unavailable most of tomorrow but I think everyone has enough feedback to keep the momentum up before 0.9.0 is released to AMO. :) See #1120 for some additional info.

Here is a "Write New Script" button.

This patch, on this branch, is a small fix for the mac. The build.sh will also need to be updated, but I haven't gotten to that yet..

Uninstalling all but one script doesn't show Enable/Disable and Uninstall buttons until leaving "tab" and then reentering. Probably more case instances on this too.

Ah, this is because no userscript is selected, select a userscript and the buttons will appear.

I think we should have an uninstall confirmation/undo, I hit uninstall by mistake when trying to move a userscript, and that was annoying..

Extensions use a confirmation.

Adding single script to clean profile, then doing any Move Up, Move Down, Move to top, Move to bottom and Sort Scripts causes massive issues. Those menu items should probably be disabled if script count is 1

patch

Uninstalling all but one script doesn't show Enable/Disable and Uninstall buttons until leaving "tab" and then reentering. Probably more case instances on this too.

Ah, this is because no userscript is selected, select a userscript and the buttons will appear.

This patch should alleviate the issue.

Ok, this issue is resolved. There's bugs, no doubt. But trying to track all these related-but-different issues in one place is overwhelming me.

See: #1111 #1112 #1113 #1114 #1115 #1116 #1117

Phew. There's at least seven separate things. If I missed something somehow, please just create a ticket for the individual issue to be discussed.