SeaMonkey:Suite Directory Layout

This document describes the directory layout to be used within the suite/ directory in the mozilla.org source tree.

Do NOT change this document unless SeaMonkey Council people have agreed with what those edits are telling!
You can add your comments or proposals to the Discussion page instead, we're glad to read your opinion there.

Guidelines

• organize things according to function, not according to "how it's built"
• organize locales in a way that works well for "source L10n" (even if that might not fit with the above rule), i.e. all localizable stuff goes into mozilla/suite/locales/en-US/ directories (other locales will have the same structure of files under l10n/<ab-CD>/suite/ in the future)
• themes are kept in suite/themes/<name>/
• use general descriptive names for the components' directories, not "brand" names ("common" instead of "communicator", "browser" instead of "navigator", "mailnews" instead of "messenger", etc.)

Example

main repository:

mozilla/

• suite/
  • branding/ - stuff used for branding the application (mainly artwork)
  • browser/
  • common/
    • content/
      • prefs/
  • installer/
  • locales/
    • en-US/
      • chrome/
        • [branding|browser|common|mailnews|...]/
      • installer/
  • mailnews/
  • themes/
    • classic/
      • [browser|common|mailnews|...]/
    • modern/
      • [browser|common|mailnews|...]/

L10n repository:

l10n/

• <ab-CD>/
  • suite/
    • chrome/
      • [branding|browser|common|mailnews|...]/
    • installer/

IRC discussion snippets

[2006-01-17 07:00 PST] - topic: suite/ organization

<KaiRo> bsmedberg: you seemed to have a preety good image in mind when discusssing some "move to suite/" stuff a few months back... now that plans are getting more concrete on our side, can you give us some good rules to follow for the directory structure, so that we are a "good citizen" in your eyes?
<bsmedberg> KaiRo: organize things according to function, not according to "how it's built"
<bsmedberg> KaiRo: so instead of "suite/components" (which is basically meaningless)
<bsmedberg> use suite/printing and suite/ui
<bsmedberg> or something like that
<KaiRo> bsmedberg: with locales being somewhat an exception to that rule, right?
<bsmedberg> yeah
<bsmedberg> KaiRo: same thing for content files... instead of suite/content/*
<bsmedberg> KaiRo: use suite/global
<bsmedberg> (which is what xpfe/ does now, better than toolkit/)
<KaiRo> bsmedberg: suite/branding/content/ or suite/mailnews/content/ is okay, I guess? (so that some src/ or whatever can be placed next to the XUL content/)
<bsmedberg> That's fine if desired, though actually not necessary
<bsmedberg> IMO at least
<KaiRo> bsmedberg: so you'd place the XUL files directly in suite/mailnews/ or suite/browser/?
<bsmedberg> KaiRo: that depends on the size of the directory
<bsmedberg> KaiRo: suite/browser should almost certainly have some internal organization or it will be too large
<bsmedberg> as should suite/mailnews
<bsmedberg> but that organization need not be content/ src/ public/ subfolders
<KaiRo> bsmedberg: I guess so... though the current habit of xpfe to use an extra resources/ hierarchy does sound too much to me (e.g. xpfe/browser/resources/content/ atm)
<bsmedberg> yes, resources/ is too much
<KaiRo> bsmedberg: btw, how do you think we should handle themes? we'll likely will still deliver two themes, should those go inside the function-based dirs or into a suite/themes/ that is structured like themes/ is now? (I guess we should move out of the global themes/ dir as well)
<bsmedberg> KaiRo: I personally think that they ought to live in the function-based directories
<bsmedberg> KaiRo: but many people disagree with me, so you may pick suite/themes if your team thinks that's better
<KaiRo> bsmedberg: ok, we'll discuss that... how would you organize two themes in the function-based dirs? or is the reply just "I wouldn't do two themes"?
<bsmedberg> KaiRo: you have several options -- 1) start bug 305746 right now for suite (probably not the most expedient choice)
<bsmedberg> and then your default (presumably classic) theme would actually be in content/
<bsmedberg> 2) have dir/themes/classic and dir/themes/modern
<bsmedberg> 3) have dir/classic and dir/modern
<bsmedberg> 2) is probably best