Firefox addons developer guide

Rules:

  • File and directory names: italic
  • method and variable names: class name
  • If you want to add a FIXME, add:
FIXME: a message

Notes:

The original document is in Japanese and distributed via the xuldev.org website. So there may be still some reference to the xuldev website (we want to host source code on MDC, not on xuldev), and to Japanese things (like some specific locales, which have been translated to French since non-latin characters are not well supported).

There are a few things that could be done to make this fit the site better, and for general cleaning up:

  1. Tables should use the "standard-table" CSS class so they're styled the same as those on the rest of MDC.
  2. There should be some introductory text on the table of contents page at https://developer.mozilla.org/En/Firefox_addons_developer_guide
  3. Obviously there are a number of FIXME items in the content that need dealing with, but those are already known.
  4. These should use the Previous, Next, and PrevNext templates to add quick routes to get from chapter to chapter. See the XUL Reference, for example.
  5. Each chapter should be tagged appropriately, based on content, and every chapter should include the tag "Firefox addons developer guide".
  6. Instead of using footnotes, we should inline these notes into the body of the article.
  7. Apostrophes are being done using curly apostrophes instead of straight ones as is done everywhere else in MDC.
  8. The stuff about installing the DOM inspector (https://developer.mozilla.org/En/Firefox_addons_developer_guide/Let%27s_build_a_Firefox_extension#Install_the_DOM_Inspector) is not accurate for Firefox 3 or later, since it's no longer included in the Firefox installer and must be downloaded from AMO.
  9. Filenames should use <code> styling. This is available from the Style drop-down menu in the editor.
  10. Variable and function names use <code> styling.
  11. XPI should be in all caps instead of written as ("xpi").
  12. Method and function names should have parentheses after them. For example, here: https://developer.mozilla.org/En/Firefox_addons_developer_guide/Let's_build_a_Firefox_extension#init_method The text of the paragraph should begin "The <code>init()</code> method is as shown...".
  13. If you use the Interface template when mentioning interfaces by name, MDC will automatically format them and generate links to their documentation, like this: nsIConsoleService. If you prefer, you can just link to the articles directly. Either way, these links should be added.
  14. These articles are all tagged as covering Firefox 3.1 using the fx_minversion_header template, but I don't think that's the case. Certainly Appendix 2 doesn't care what version of Firefox you're using, since it's just about open source software licenses.

Todo:

  • All FIXME notes inside the documents;
  • Add abbreviation definition to acronyms;
  • Add some link to the internal MDC documentation when it makes sense;
  • Indent source code;
  • Make sure documentation is relevant for all platforms: GNU/Linux, MacOS, Windows;
  • Add anchor links to Figures & Listings;
  • Add credits to original authors and license; COMPLETED
  • Sometimes, interfaces names are misspelled: s/nsL/nsI;
  • Talk about FUEL;
  • Titles of chapters and sub-headings should have CAPS for first letter of each word;
  • We should add a part about bad and good practices (leaks, global scopes, ...);
  • Add external resources (mozdev.org/community/books.html);
  • Add to chapter 3 or 5 more informations about overlay (how to overlay some interesting part of Firefox like status bar, menus or toolbar)
  • Add previous/next at the end of each chapter

Questions:

  • OpenSource appendix. Should we keep this part ?
    • Gen's opinion: yes, because it is important for developers to make informed decisions regarding OSS licenses and it was a part of the original guide.

Opinions:

  • I think we should be careful about adding new contents to this guide. The original version of this guide was written as a first step guide for beginners. If we add too much topics, they possibly make learners weary. An alternative idea: writing a "next step" guide for interested people such as adding statusbar buttons, sidebar panels, and so on. (by Piro)
    • I do think this guide should cover more advanced topics as well. There already is a tutorial for beginners: Building an Extension. Slosd 09 April 2009