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 has agreed with what you are saying! You can add your comments or proposals to the [Talk:SeaMonkey:Suite Directory Layout|Discussion] page.

Example

• suite/
  • browser/
  • common/
    • prefs/
  • installer
  • mailnews/

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