Open Bug 456874 Opened 12 years ago Updated 10 years ago

Need a policy/rule of thumb, for new prefpane usage by extensions.

Categories

(SeaMonkey :: Preferences, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: misak.bugzilla, Assigned: mnyromyr)

Details

Attachments

(6 files)

The new prefpane landed in SeaMonkey 2 Alpha makes some extensions prefences inaccessible. xSidebar for example.
This is right time to decide where extensions preferences should go and how they should be organized.Mnyromir suggests "imo, all prefs pages should be available in the pref dialog, access from addons manager is just a plus. Maybe we should have a (usually hidden) branch for "Extensions" and extension authors should put their stuff below that?".
There is lot of possibilities there, and for better product usability IMHO we should have some set of rules and encourage extension developers to follow them.
Flags: wanted-seamonkey2?
FYI: The latest unstable xSidebar build overlays the new prefwindow with a prefpane.
I don't think this is a high-priority item, I'm not even sure how this should be solved or how it should be measured if this has been achieved.
Flags: wanted-seamonkey2? → wanted-seamonkey2-
This bug is open but targeted for seamonkey2.0b1, which has already been released. Please set the target milestone to an appropriate value, "---" if it has no specific target.
Target Milestone: seamonkey2.0b1 → ---
I'm planning to implement it this way:
- add a toplevel branch "Extensions" in the pref dialog between "Privacy" and "Advanced" where Extensions can/should place their panels in
- use the opportunity and put a draggable splitter between tree and panels

Policy would suggest then that an extension named xxx would name its subbranch xxx as well.
Assignee: nobody → mnyromyr
Target Milestone: --- → seamonkey2.1a1
This patch
- adds a new top level branch named 'Extensions', whose prefpane just 
  contains some educational text ('there be dragons')
- adds a new global Startup handler to our preferences main window, so that
  the new Extensions branch will be openable once there are extension
  subbranches in it
- contains an example change to the Lightning pref branch, which moves it
  and its subbranches under the Extensions branch. 
     THIS CHANGE IS NOT CONSIDERED PART OF THIS PATCH! 
  (And won't be checked in with this, of course.)
- adds a splitter between preftree and prefpanes, since Extensions might add
  nesting levels of 3 or higher
- makes the splitter as invisible as possible without making it unusable
Attachment #410925 - Flags: superreview?(neil)
Attachment #410925 - Flags: review?(philip.chee)
Attachment #410925 - Flags: review?(philip.chee) → review+
Comment on attachment 410925 [details] [diff] [review]
Extensions branch, v0

Code review:

> This patch
> - adds a new top level branch named 'Extensions', whose prefpane just 
>   contains some educational text ('there be dragons')

See later.

> - adds a new global Startup handler to our preferences main window, so that
>   the new Extensions branch will be openable once there are extension
>   subbranches in it

Personally I'd just fix container="true" in the XUL and do away with the JS. But I don't have a strong opinion either way.

> - adds a splitter between preftree and prefpanes, since Extensions might add
>   nesting levels of 3 or higher
> - makes the splitter as invisible as possible without making it unusable

How does this splitter look on OSX?

> +<!ENTITY pref.extensions.description "&brandShortName; allows you to improve itself by custom
> +                                      extensions, using the Add-on Manager. Whenever such an
> +                                      extension provides additional preference settings, it
> +                                      should add its own prefpanel subbranch below this one,
> +                                      named after itself.">

I think this comment is more of a dev-doc aimed at extension developers and should go in DevMo. For end users I'd suggest something brief and succinct like:

"Preferences settings for Extensions"

You can then remove the brand.dtd. or you could say:

"Preferences settings for &brandShortname; Extensions".

diff --git a/suite/themes/classic/communicator/preferences.css b/suite/themes/classic/communicator/preferences.css
+
+.prefsplitter {
+  border: 0;
+  padding: 2px;
+  background: transparent;
+}
I'd check with stefanh if this is acceptable on OSX or if this file should be forked into suite/themes/classic/mac/....

r=me for the code assuming stefanh gives ui-r+.

Concept review:

1. I'm not too happy with the multiple levels as seen with the lighting extension but I don't see a way around this with your given UI.

2. Extra work for Extension authors. Currently all they have to do is to specify an optionsURL in their install.rdf. In your proposal the hypothetical extension author would have to {a} write at least one new overlay. If they are using a <prefwindow> they might be able to refactor their code and share a prefpane or two (as Neil did with Lightning) but still extra work. And several extension authors are still using <dialog>. What I've seen some (lazy) mozilla suite extension authors do is to add a pref-panel with just one button that opens their Firefox/Thunderbird options dialog.

Mat Tobbin has been hacking at the XUL recently and he came up with the concept of transplanting the EM Manager code into our Preferences window as seen here <http://personal.mattatobin.com/screenshots/misc/addonsprefpane.png>. Combine this with the compact EM styles I use for the EM manager in the sidebar in xSidebar and we might have something.

Advantages: No extra work for extension authors as the optionsURL is automatically picked up.

Disadvantages: The XPInstall prompt does not know how to talk to such UI and always opens a new top level EM window. This is hard coded somewhere inside the EM XPCOM component. But of course this also applies to your existing patch.
Comment on attachment 410925 [details] [diff] [review]
Extensions branch, v0

> r=me for the code assuming stefanh gives ui-r+.
*and* if you come up with a better text for the Extensions boilerplate.
As ratty stated above:
"Disadvantages: The XPInstall prompt does not know how to talk to such UI and
always opens a new top level EM window. [...]."

I have pretty much solved the xpinstall issue. This is still only conceptual... But it stands to reason that instead of finding a way of making xpinstall call elements inside of elements we should look at just using what is already there. By modifying the em xul file strip out everything but the Install portion of it we can solve that disadvantage easily.

This method will present a window with only the install elements and methods we need to install an addon and I think is justifiable because like the update ui for the entire program the user really only needs a window that requires the user to ether choose to restart or not restart after the installation of an addon.

In my own experience this is the only real required action after installing an addon. Eather the user is installing one addon and will restart right then and there to start using it or the user is installing many addons and will wait till they are done to restart. It is the same situation when the application is updating its self...
We know we can produce a list of installed themes. Maybe we can produce a pref pane containing a list of active extensions that have options dialogs?
Do we have a way of asking extension authors what they would like to see?
That is a good question... The idea is that functionality wise an EM pref pane needs to not break compatibility with extensions, ie: not make how developing extensions change in any way possible.
If we did code our own pref panels not based on the excising toolkit EM manager then it should retain the seamonkey type ui that is similar to what was in Firefox 0.8's preferences which was a clone of the themes prefpane and that in its self is from the mozilla suite (keeping in mind i am referring only to the extensions pane not the iconic sidebar)
I think the simplest approach is a listbox similar to the applications helper pane with an options button for each extension (which specifies an optionsURL in their install.rdf). I already do something similar in xSidebar where I interrogate the EM datasource to produce a dropdown menu list, example: <http://www.flickr.com/photos/aleytys/406326823/sizes/o/>
So the options button and possibly a Details button and Uninstall button would be inline like the drop down box in the applications helper? What about enable/disable and uninstall buttons?

If that is the case how can we fit that much inline with the extensions name in the default size constraints of the preferences window? I am thinking ether they have to be listed in a way that is close to the toolkit EM or use the older ui like the firefox 0.8 extensions
Since this is the SeaMonkey Preferences window we are talking about, we should only have UI for opening the extension preferences/options. All other functions e.g. enable/disable/uninstall/visit home page/update should be done through the toolkit Addons Manager UI.
Target Milestone: seamonkey2.1a1 → ---
You need to log in before you can comment on or make changes to this bug.