We are starting to have a lot of tools. It's polluting browser.js. And these tools should share some code: - killswitch code - adding menuitems to Firefox's menus (appmenu, menubar, future tool menu) - adding items to the developer toolbar (as button or as menuitem) - handling the check state of their commands/buttons/menuitems - handling the tab events devtools.jsm would expose a global variable (gDevTools), that would let us to register tools.

Should we also include common objects and methods we use throughout different developer tools?

(In reply to Mihai Sucan [:msucan] from comment #1) > Should we also include common objects and methods we use throughout > different developer tools? That's possible. I suggest that we start with the very basic features (registering tools), and we will then add what we thing is needed.

Indeed. That makes sense.

first attempt

Description of the current approach: gDevTools is a global (real global, not window-global). Tools are described (see below) in devtools.jsm (we don't want any extra files to load as this is executed at startup). browser.js call gDevTools.newBrowserWindow() when a new Firefox window is created. Then, we dynamically build the buttons/menuitems/commands… gDevTools tracks the tab switches. The tool needs to implement a isOpenForBrowser() function. A tool is declared like that: let myTool = { id: "MyTool", killswitch: "devtools.mytool.enabled", get label() {return this._l10n("mytool.label")}, get accesskey() {return this._l10n("mytool.accesskey")}, get key() {return this._l10n("mytool.commandkey")}, keyModifiers: "accel,shift", keyModifiersMac: "accel,alt", checkbox: true, inDevToolbar: false, onCommand: function(aBrowserWindow) { // what happens when the menuitem/button/key is activated }, onOpen: function(aBrowser, aInstance) { // callback }, onClose: function(aBrowser, aInstance) { // callback }, isOpenForBrowser: function(aBrowser) { // to track if we should check/uncheck the buttons }, };

This is cool stuff Paul. I only have one comment - came to me while reading through the patch, then I saw your description. I would suggest we do not remove menuitems, commands, entities from DTDs, etc. I believe it makes sense to have those elements in XUL files. When someone works in XUL files or in a DTD, one expects to find all menu items and strings in their respective files. We should have really good reasons for adding these items dynamically. Do we often add/remove devtools? Why not have the tool descriptor defined in a way that it allows us to point to the existing menuitem/command IDs, etc? Also note that in the Web Console we will go slightly backwards: we will put UI markup in a separate .xul file - where it belongs. Too much of the Web Console UI is built in JS.

Things I didn't do: - handling instances of the tools in the gDevTools. It's up to the tool author to handle that (oncommand: "close if already open"). - unregistering tools - generic context: <browser> is the context. We could support: global, firefox window, tab/page, content window - destruction of context should close a tool. As it is, it's up to the tool to handle that.

I agree, if we could keep the Dtd, it would be better.

Another problem with the current approach is that we build a lot of things dynamically when the browser is loaded. It might impact the performance.

When I originally suggested this, my thoughts really were to just encapsulate the big block of devtools "enable/disable UI" code in browser.js - literally just copy it from there into the module, and have the code take a window/document argument, on which it can call getElementById/etc. I think having the module build the UI dynamically is going a bit too far - as Mihai suggests, it makes figuring out how the UI works more complicated for not much gain.

Yeah, building the UI dynamically might a bit too much. We are also polluting browser.js with all the lazy getters and code for starting the tools. Here are the minimal goals I have in mind for this bug: - cleaning browser.js - sharing code: operations like updating the status of the buttons (checked/unchecked), listening to tabs selection/destruction, ... are coded in all our tools, and in different ways. - sharing a global: tools instances have a different way to be reached. How do you get the Style Editor for tab n? feedback is welcome.

(In reply to Paul Rouget [:paul] from comment #11) > - sharing a global: tools instances have a different way to be reached. How > do you get the Style Editor for tab n? Bare in mind that the style editor can be passed a style rule and line number ... I think it can only be opened for the current tab though.

started on a patch to do this today. Got a ways into it before realizing several of our tools would have to change the way they get instantiated. The idea I had of passing in the chromeWindow as an argument is not going to cut it here and I'm out of time for today.

Our API documentatioon is here: https://etherpad.mozilla.org/devtools-framework-jsm Glossary: https://etherpad.mozilla.org/devtools-glossary Mockups: http://htmlpad.org/devtools-framework-api/

(for whoever read these documents: they are still drafts, nothing final yet)