Per-Extension Preferences

[bengoodger]

<b>Preferences Changes</b>

If you've been watching Phoenix General, you'll see that the Preferences Dialog is being reorganized. This reorganization will probably make the way you are integrating with preferences currently obsolete, as the tree view is being removed in favour of a simplfied icon list with higher level categories. While obviously we cannot stop extensions from adding to this list, once the changes go in the list will be full and it will be practically impossible to add to it I thought about that for a while and decided it wasn't too much of a problem, since many extensions are not 'high level' enough to warrant an entry in this new category list. So, to solve this, extensions that have few enough settings to integrate smoothly and seemlessly with existing panels can do so, and others are encouraged to use:

<b>Per-Extension Preferences Dialogs</b>

I'm going to be adding support for per-extension preferences that allows extensions to provide a dialog that can be launched by a new "Settings" button on the Extensions panel in preferences.

Here is what I propose:

in your contents.rdf file, specify a chrome:settingsURL arc on your package definition resource that refers to a chrome file in your package that is your settings dialog. If this arc exists on the package definition resource selected, I will enable the "Settings" button, and open this dialog in a modal window above the preferences dialog.

e.g.

<code>
<RDF:Description about="urn:bengoodger.com:package:goatifier"
chrome:displayName="Goatifier"
chrome:author="bengoodger.com"
chrome:authorURL="http://www.bengoodger.com/software/goatifier/"
chrome:settingsURL="chrome://goatifier/content/pref/pref.xul"
chrome:name="goatifier"
chrome:skinVersion="1.2"/>
</code>

Using this arc means where you place the file in your extension package is up to you.

Note I'm also going to be adding 'authorURL' - after my preferences changes go in, this will be a link to your extension's homepage, and the author text in the extensions view will be linkified. I'll also add authorURL support to the themes panel.

What do you all think of this plan?

[asa]

<b>Preferences Changes</b>
What do you all think of this plan?

a=asa

--Asa

[seb]

What do you all think of this plan?

It sounds really cool, Ben.

[djst]

<b>Preferences Changes</b>
What do you all think of this plan?

a=asa

This sounds like a good idea, and I'm hoping most extension authors will take advantage of this separate dialog method. I see that you've gotten approval already.

One problem that I see is that this could lead to UI inconsistency, since it's up to the extension author to design this dialog. I was thinking if it would be possible to include a template dialog (an empty, sized and titled dialog that would then be used by the author to add widgets to). This way, the dialog would be consistent:

Code: Select all

______________________________________
| Settings for <ExtensionName>    [X]|
|____________________________________|
|                                    |
| [ ] Checkbox 1                     |
| (*) Radio 1                        |
| ( ) Radio 2                        |
|                                    |
|  (or whatever the author wants     |
|   to have here...)                 |
|                                    |
|                                    |
| Author: <AuthorNameOrLink>         |
| __________________________________ |
|                                    |
|                  [  OK  ] [Cancel] |
|____________________________________|

This would indeed lead to a consistent UI among the extensions. I don't know if it's worth the effort though.

[bengoodger]

This would indeed lead to a consistent UI among the extensions. I don't know if it's worth the effort though.

That's a problem though already though, no? But you're right, it's a nice idea.

[cdn]

Code: Select all

______________________________________
| Settings for <ExtensionName>    [X]|
|____________________________________|
|                                    |
| [ ] Checkbox 1                     |
| (*) Radio 1                        |
| ( ) Radio 2                        |
|                                    |
|  (or whatever the author wants     |
|   to have here...)                 |
|                                    |
|                                    |
| Author: <AuthorNameOrLink>         |
| __________________________________ |
|                                    |
|                  [  OK  ] [Cancel] |
|____________________________________|

~=

Code: Select all

<?xml version="1.0"?>
<dialog title="Settings for <ExtensionName>">
<vbox>
<groupbox>
<caption label="&menuPref.caption;"/>
<vbox>
    <checkbox id="compact-fileMenu" label="&fileMenu.label;" prefstring="compact.menu.showmenu.file"/>
</vbox>
</groupbox>

</vbox>

<label value="Author: whatever "/>

<separator/>
</vbox>
</dialog>

missed the buttons, but I assume they'll be in the template ?

[Chris Cook]

What do you all think of this plan?

This approach seems much more flexible and future friendly than the existing implementation.

I'm curious if you are currently thinking of implementing your proposed "additional browsing options" addon as an extension (I assume that was what you meant) and if so, how you will implement all the preferences for this extension. As I suggested in my post in the "prefs consolidation" thread in general, I hope this will not fragment preferences for related features.

[mboullet]

Ben,

If you create a "Settings" button in the extension panel, you should create an "Uninstall" button as well, since it is a generic function of an extension.

How the uninstall function is activated is to be defined.

Though I like the general idea, the danger is that Phoenix extension will be a bit further from the same Mozilla extension.

Today, it's quite hard (mainly because an extension developer is not full time on it and the targets are evolving) to maintain both a Mozilla and Phoenix extension in the same .jar.

In the future, with your proposal, maybe we"ll need to have 2 .jar.

[alanjstr]

There is an Extension uninstall button, it just doesn't work yet. This should be kept in mind for the future panels, though, since I do expect it to happen eventually.

[bengoodger]

Ben,
In the future, with your proposal, maybe we"ll need to have 2 .jar.

Shouldn't be necessary - Mozilla should just ignore the extra arcs I'm adding (someone else could add the functionality to Mozilla though).

I won't get to "Uninstall" at this point since it's a tough problem and my patch is already plenty large

Chris - I had imagined that extensions that add a small amount of UI could continue to integrate seamlessly, but those that have a bunch of controls that merit their own panel (e.g. mouse gestures) would need to use this mechanism.

[David James]

Looks like a good plan to me.

Ben,

I've reassigned <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=179560" title="Per-extension preferences">bug 179560</a> to you as this bug concerns this very topic.

[alanjstr]

I won't get to "Uninstall" at this point since it's a tough problem and my patch is already plenty large

I just meant be sure to consider it in the UI design, even if it is hidden for now.

[bengoodger]

OK folks, I'm done with my patch and I'm going to try and land soon. To give you an idea of what it takes to update an extension to use this new scheme I've updated my tab downloader add-on to v2.02 so that it supports this. The diff that describes the changes I had to make to convert my pref panel into a settings dialog are here:

http://www.bengoodger.com/software/tabl ... ialog.diff

mboullet - I see now what you mean by it being a bit trickier - before you could just use the pref dialog's automated saving scheme to save your changes.. and I can see how supporting both systems might be a bit more complex now. However, here's a thought:

Create a pref panel file - and put the script in it that interacts with Mozilla's automated pref system
Create a dialog file - and put script in that that saves the prefs itself.

Create an overlay file that overlays into each, containing XUL and script that will be the same between the two.

[Ted Mielczarek]

<b>Preferences Changes</b>
What do you all think of this plan?

a=asa :D

--Asa

Changed your mind since I submitted that bug? :-P

[bengoodger]

This is now checked in and working for themes and extensions.