I often get the urge to install an add-on from a file after checking out the add-ons window. Why do I need to open a browser tab and locate the file to get that done? If this "too much GUI" for FF, then at least for SM...

Install button is turned off by default. To turn it on, go to about:config and set extensions.hideInstallButton to false.

The Firefox UX team wanted it removed so it was in Bug 342656. If Seamonkey wants this please file a Seamonkey bug... all they have to do is add a pref. If you'd like to discuss adding it back you can do so in the Firefox mailing list.

Ok, making this an SM bug about enabling the button.

Before I knew about this config option, or about how dragging and dropping the .jar into the appropriate add-on window, I had to install a theme update by renaming the .jar to .zip, decompressing it, and then copying the contents on top of those into the appropriate subdirectory (which I had to manually check to make sure it was the right extension) in my profile's extensions directory. There is no way that any average user would be able to do something like this. Nor would they ever discover the easier drag and drop method, nor know about a preference to turn this back on again.

Simple one line patch to turn on the "Install" button in the Addon Manager window.

I'm against the change as per my comments in Bug 342806. to reply to Karsten's c#9 from there.. >- It's inconsistent, non-obvious and counter-intuitive. I don't see where this is inconsistent form. Non-Obvious and counter-intuitive, sure it can be argued. But you can file->open the .xpi as well (unless I am very mistaken) and to me that makes more sense. >- It makes "download once, install offline/often" very hard and non-obvious. In the SM2.0 world the "download once, install offline/often" shouldn't be needed this much this way, there is no need to re-install all/most extensions each time you upgrade, *most* users won't have 30-40 profiles (or even half that) etc. Most will have but one profile. I personally feel that we should/could easily go through a alpha release with the install button missing, and see how many alpha users miss this and/or get confused by its non-existing-nature. If it proves I am the minority, we'll enable it with my embrace. If it proves you are the minority, about:config exists. And if it is a close call, council can always vote on default, and we can provide UI in prefs to enable/disable (possibly, I'd be content with just a council vote). To note, *I* am *not* part of the SeaMonkey council.

Philip, Neil, Are you still working on this ?

Serge, there is a patch waiting for review as you are well aware of. Please don't add useless comments. I get enough bugspam as it is already.

(In reply to comment #8) > Serge, there is a patch waiting for review as you are well aware of. Please Yes, my comment was (more) a ping to Neil (too)... > don't add useless comments. I get enough bugspam as it is already. I apology ... I had not read comment 6. *** After having had to use this feature repeatedly (to create/handle multiple testing profiles), and reading bug 342806 and this one, I support this (as a) bug. If the point is, as it seems it was for Firefox, that (some/most) users may not understand that this button is only for (already) downloaded files, then SeaMonkey "should" make that clearer, not remove the button.

To quote my comment #9 in bug 342806, which Callek replies to in comment #6: --- quote on --- Having an Addon-Manager which can't install addons is just weird. - It's inconsistent, non-obvious and counter-intuitive. - It makes "download once, install offline/often" very hard and non-obvious. Many users (as seen in newsgroups and mails I got) maintain SM based installations for their family/friends and are downloading addons on memory sticks etc. to install them offline, on several mechines. Our capability of browsing the local file system in the browser is very obscure and unwieldy (in short: user-unfriendly). Hiding the button doesn't solve any problems, it's just taking away a useful and logical way of installing extensions... --- quote off --- I still think we should not ship SM2 without it and actually no Alphas either - we don't have _that_ much Alpha users to get a "vote of feet" on such a minor feature.

On a scale of %'s... I am about 55% against re-adding it, and I also just did a straw-poll of TB-folks on opinions one way or the other, and everyone was mostly indifferent. Useful thoughts brought up: * asuth: "Add it, kitchen sink!" -- while I know this was made in jest, I'm not sure I can feel good disagreeing with this assertion. * davida: "that's how it's easiest to install XPIs in Komodo" -- and what works for one animal may work for another. Even if the animal in question is many many times larger than us SeaMonkeys. Long story short, I can no longer gauge how strongly I felt on this before, but if you feel even 56% "for" adding it back, I won't object [anymore].

I still wonder if the bug 342656 argumemnts hold true for SeaMonkey, but I've mostly arrived at a point where such things get dontcare+ from me :p

Argument for not having things in Firefox always come down to the fact that they want everything as simple as possible, that only one way should be presented, and that the developers know what the right way is. One of the philosophies that makes Seamonkey different from Firefox is that more choice is given to the user, and UI elements like this are exposed rather than hidden.

Surely not blocking the about-to-be-frozen alpha for a debatable minor issue that doesn't break any functionality whatsoever. IMHO, no release should ever be *blocked* at all for something like this. Jason: Right, you're citing one reason why we badly need a real vision statement for SeaMonkey or we'll end up with an overloaded, confusing monster in the end. Simplicity is always better then confusing UI, the question is what's simpler and more for users here actually. But as I already said, I give this a dontcare+, i.e. I don't care either way, if we take this or not.

Updating patch. Now against comm-central Hg repository.

Comment on attachment 349762 [details] [diff] [review] comm-central patch v1.1 No approvals needed for any comm-central checkins right now.

(In reply to comment #16) > (From update of attachment 349762 [details] [diff] [review]) > No approvals needed for any comm-central checkins right now. ... and we really shouldn't encourage requesting approvals until review is granted ;-)

Comment on attachment 349762 [details] [diff] [review] comm-central patch v1.1 Code change is good; just get neil or jag to sign off on it, and someone other than me to push it, and I'm ok. :-)

In reply to comment #13 and comment #14: I agree with Jason, that SeaMonkey being targeted more at "seasoned" users and less at newbies than Firefox is, we can afford more UI stuff, meaning more choice possibilities, and more accessible. In this particular case however (Install button in the Addons Manager) I happen not to care what the app-default is, because the MR-Tech Toolkit extension (one of my highest-rated must-haves) offers a UI to reenable this button (in any app where the extension installs including at least Fx, Tb, Sm2) even if the app hides it. IOW, even if you hide it from me by default, my MTT settings will display it anyway. If you ask me, I believe it's more "SeaMonkey-like" to show the button, but of course that's only one man's opinion... OTOH if Firefox hides it, then that's one more reason for me not to go back to Firefox, or only with MTT handy.

Comment on attachment 349762 [details] [diff] [review] comm-central patch v1.1 > // Hides the install button in the add-ons mgr >-pref("extensions.hideInstallButton", true); >+pref("extensions.hideInstallButton", false); Comment is wrong and the default is false anyway, isn't it?

> Comment is wrong and the default is false anyway, isn't it? So it is. This new patch removes the comment and the pref as well.

Tree is going to reopen so adding checkin-needed keyword.

Comment on attachment 350732 [details] [diff] [review] comm-central patch v1.2 [Checkin: Comment 24] "approval-seamonkey2.0a2=?": If not too late, I think this is wanted in 20a2.

Comment on attachment 350732 [details] [diff] [review] comm-central patch v1.2 [Checkin: Comment 24] http://hg.mozilla.org/comm-central/rev/a4c9e6918a77

(In reply to comment #11) > On a scale of %'s... > > I am about 55% against re-adding it, and I also just did a straw-poll of > TB-folks on opinions one way or the other, and everyone was mostly indifferent. For what its worth, from reading newsgroups on a different subject than specifically this... I was swayed to 60% *for* this button... Basically someone is/was serving a TB-Extension as content-disposition: attachment to force it to download regardless of if the user used Firefox or not, and wanted to make his extension work for SeaMonkey... The reason this swayed me, is it would be great for such types of extension devs to actually be able to just specify one set of steps to install (download, and use install button) rather than have to write/detail 2 (one for SM and one for TB). Though IMO a better solution would be to use the in-app stuff for TB and use AMO. But for those who don't/can't etc, having a unified solution is good...