Confirmed users
587
edits
mNo edit summary |
No edit summary |
||
Line 53: | Line 53: | ||
[[File:PanelMenu-i01-MenuAltList.jpg|600px|thumb|none|Potential Alternative: One Column List Menu]] | [[File:PanelMenu-i01-MenuAltList.jpg|600px|thumb|none|Potential Alternative: One Column List Menu]] | ||
<br style="clear:both" /> | <br style="clear:both" /> | ||
|Feature implementation notes=====Open UI questions==== | |||
* In the panel UI, should built-in widgets be separate from add-on widgets? | |||
** Thinking no - why create artificial boundaries? | |||
* In customization UI, should built-in widgets be separate from add-on widgets? | |||
** Thinking yes - for easier discovery | |||
* How do toolbars fit into the customization UI? | |||
** Would be nice to have, as the current UI isn't friendly (have to right-click on a built-in toolbar - many addon toolbars have their own right-click menu) | |||
** But we can't (reliably) get a preview of them | |||
* Scaling with many addons | |||
** Customization UI is relatively easy to scale - scrolling, and maybe text search | |||
** Panel UI harder to scale | |||
* Things add-ons will want: Everything. Only a subset of "everything" will fit in the Panel UI | |||
** Allow addons to restrict where a widget can go? How is that expressed in the customization UI? | |||
====Existing issues==== | |||
* Buttons added by add-ons aren't automatically available in the toolbar, add-ons need extra code and to make sure it's only run on first-run | |||
* Overlays don't play nicely with restartless add-ons | |||
* Customizing one window doesn't update other windows | |||
====Interaction with Add-ons Manager==== | |||
* Adding widgets from add-ons kinda fits with the Add-ons Manager, but built-in widgets do not - doesn't make sense to have such a big split between the two | |||
** Ergo, customization UI shouldn't be in the Add-ons Manager. | |||
* Customization UI includes lightweight themes (backgrounds), but probably shouldn't include heavyweight themes. The Add-ons Manager will keep supporting those, but the relevant UI will only shown if one is installed. | |||
====Method 1 - Re-use existing method of overlaying toolbarpalette==== | |||
* Buttons aren't automatically added to the toolbar when added to the palette - add-ons need extra code to do that, and make sure it's only done on first run. Easy to get wrong. This occasionally causes issues with addons re-adding a button after a user has chosen to remove it. | |||
* Widgets from existing add-ons won't always fit into new panel UI - eg, a longer-than-usual button, a button that opens a dropdown panel, etc | |||
* Doesn't play well with restartless add-ons | |||
====Method 2: Introduce new API==== | |||
Cu.import("resource://.../CustomizeableUI.jsm"); | |||
var button = CustomizeableUI.registerWidget({ | |||
id: "weather-indicator", // how to enforce reasonable value that should be unique? | |||
type: "button", | |||
name: "Weather", | |||
shortcut: "Ctrl-Alt-W", | |||
description: "The weather outside", | |||
defaultPlacement: "toolbar", | |||
allowedPlacement: ["toolbar"], | |||
icons: { | |||
16: "chrome://weather-indicator/icon16.png", | |||
32: "chrome://weather-indicator/icon32.png" | |||
} | |||
}); | |||
// Affect all windows: | |||
button.disable = false; | |||
// Affect one window: | |||
button.windows[window].disable = true; // .windows is a Map | |||
// When a restartless add-o is disabled, remove it: | |||
button.unregister(); | |||
Benefits: | |||
* Application wide registration, not per window. | |||
* Fixes issue of default buttons (When addon is installed, is it's button visible? Where?) | |||
* Much easier for restartless addons | |||
* Harder for addons to screw up normal styling | |||
* Should be able to support existing add-ons, by detecting added widgets. But for safely, might only be able to show them in the toolbar (not the Panel UI) | |||
Drawbacks: | |||
* Another API | |||
* More difficult for custom widgets? (Might be good thing) | |||
}} | }} | ||
{{FeatureInfo | {{FeatureInfo |