Features/Desktop/Panel Menu: Difference between revisions

no edit summary
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
Confirmed users
587

edits