SeaMonkey:Suite Directory Layout

From MozillaWiki
Jump to: navigation, search

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/
    • app/ - application startup
    • branding/ - common place for application branding (mainly artwork)
    • browser/
    • common/
      • pref/
    • 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/

Proposed Mailnews l10n layout

Thunderbird's Layout:

l10n/

  • <ab-CD>/
    • mail/
      • chrome/
        • messenger/
          • addressbook/
          • messengercompose/
          • migration/
          • preferences/
        • messenger-mapi/
        • messenger-newsblog/
        • messenger-offline/
        • messenger-region/
        • messenger-smime/

Proposed SeaMonkey Layout:

l10n/

  • <ab-CD>/
    • suite/
      • chrome/
        • messenger/
          • addressbook/
          • messengercompose/
          • pref/
        • messenger-mapi/
        • messenger-region/
        • messenger-smime/

Note: migration is elsewhere in the SeaMonkey tree.

Note: preferences renamed to pref to match suite/chrome/common/pref/

Where to move directories to/from:

Note that * means the files need to move to more than one directory.

To mozilla/suite/locales/en-US/chrome/messenger/:

To mozilla/suite/locales/en-US/chrome/messenger/addressbook/:

To mozilla/suite/locales/en-US/chrome/messenger/pref/:

To mozilla/suite/locales/en-US/chrome/messenger/messengercompose/:

To mozilla/suite/locales/en-US/chrome/messenger-offline/:

To mozilla/suite/locales/en-US/chrome/messenger-smime/:

To mozilla/suite/locales/en-US/chrome/messenger-mapi/:

relevant jar.mn files (containing locale information):

IRC discussion snippets

[2007-01-12 13:39 PST] - topic: mailnews locale organization in suite


<KaiRo> Standard8Away: btw, as we usually have only one or two files there, we tend not to do a separate *-region in suite/
<KaiRo> phew, locale/en-US/messenger/ in en-US.jar really has all the files of the different dirs merged, (almost) no subdirs? wow...
<NeilZZZ> KaiRo: my memory is that addressbook and messengercompose have their own subdirs, but everything else is in that dir
<KaiRo> NeilZZZ: yes, that's what I'm seeing... which means that we probably need/want(?) to mirror that in the new structure in suite/locales/
<KaiRo> hmm, even pref panels are directly in mailnews/
<NeilZZZ> well, there are two things to consider
<NeilZZZ> 1) we could reorganise mailnews under suite but in jar.mn it would still be mapped to the original locations
<NeilZZZ> 2) we could then reorganise messenger.jar with the new locations
<NeilZZZ> but we could only do that for forked files
<KaiRo> hmm, true, we could reorganize in the source tree, but as you said, matching chrome structure to that would be a good idea, and that's hard because of shared files
<KaiRo> though somehow I start thinking that it might be a good idea to think of forking the whole mailnews UI and make mozilla/mailnews/ only have backend code in the long term
<KaiRo> NeilZZZ: it might be safe and perhaps a good idea in any case to move pref panels the way you describe, like Standard8Away proposes in his doc
<KaiRo> just not sure if it's correct/good to move the MAPI one there as well
<KaiRo> wait, that's not even a panel, that's just an overlay

[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

Retrieved from "https://wiki.mozilla.org/index.php?title=SeaMonkey:Suite_Directory_Layout&oldid=48508"