You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

Thunderbird Mail Directory Structure

When the work for thunderbird moves to the trunk, we will be moving the thunderbird UI into a new top level directory, mozilla/mail. Initially, we will only fork UI files we needed to modify from the mozilla mailnews client. Once we reach that point and have a trunk version of minotaur, our next step is to completely fork the UI from mozilla mailnews, and move to the new toolkit. Here is a proposal for the directory structure of mozilla/mail. Note: it is based on the structure used by Phoenix and the new toolkit (which includes removing extra directory layers, in particular: resources and en-US).

  • app: files necessary to generate minotaur.exe (nsMailApp.cpp)
    • profile: profile defaults for a minotaur profile (all.js, mailnews.js, etc).
  • base: core mailnews files used by all the mail components
    • content: xul, js files (messenger.xul)
    • locale: dtd, property files (messenger.dtd)
  • components: the various components that make up a mail client (address book, imap, news, etc).
    • news
      • content
      • locale
    • addrbook
      • content
      • locale
    • compose
      • content
      • locale
    • imap (if necessary)
      • content
      • locale
    • local (if necessary)
      • content
      • locale
    • prefwindow: minotaur pref files (pref-viewingmessages.xul, pref-mailpreftree.xul)
      • content
      • locale
    • accountmgr: account manager files
      • content
      • locale
  • skin: Files specific to the minotaur skin
    • messenger
    • addressbook
    • msgcompose
  • extensions: components which are not requied to build stand alone mail (smime, bayseian spam filters, mdn)
    • smime
      • content
      • locale
      • skin: skin specific files for this extension
    • bayesian spam filter
      • content
      • locale
      • skin
    • mdn
      • content
      • locale
      • skin
    • mailviews
      • content
      • locale
      • skin

Alternatively, instead of having a global top level skin directory, we could push that down into each module. For instance, base could have a skin directory, components/prefwindow could have a skin directory, components/addrbook, etc. (Note: in fact this is what we ended up doing)