SeaMonkey:Suite Directory Layout: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(add example for L10n repository as well)
 
(9 intermediate revisions by 3 users not shown)
Line 17: Line 17:
mozilla/
mozilla/
*suite/
*suite/
**branding/ - ''stuff used for branding the application (mainly artwork)''
**app/ - ''application startup''
**branding/ - ''common place for application branding (mainly artwork)''
**browser/
**browser/
**common/
**common/
***prefs/
***pref/
**installer/
**installer/
**locales/
**locales/
Line 42: Line 43:
****[branding|browser|common|mailnews|...]/
****[branding|browser|common|mailnews|...]/
***installer/
***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/:
* [http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/locale/en-US/ mozilla/mailnews/base/resources/locale/en-US/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/base/search/resources/locale/en-US/ mozilla/mailnews/base/search/resources/locale/en-US/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/extensions/mailviews/resources/locale/en-US/ mozilla/mailnews/extensions/mailviews/resources/locale/en-US/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/extensions/mdn/resources/locale/en-US/ mozilla/mailnews/extensions/mdn/resources/locale/en-US/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/imap/resources/locale/en-US/ mozilla/mailnews/imap/resources/locale/en-US/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/import/comm4x/resources/locale/en-US/ mozilla/mailnews/import/comm4x/resources/locale/en-US/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/import/eudora/resources/locale/en-US/ mozilla/mailnews/import/eudora/resources/locale/en-US/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/import/oexpress/resources/locale/en-us/ mozilla/mailnews/import/oexpress/resources/locale/en-us/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/import/outlook/resources/locale/en-us/ mozilla/mailnews/import/outlook/resources/locale/en-us/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/import/resources/locale/en-us/ mozilla/mailnews/import/resources/locale/en-us/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/import/text/resources/locale/en-US/ mozilla/mailnews/import/text/resources/locale/en-US/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/local/resources/locale/en-US/ mozilla/mailnews/local/resources/locale/en-US/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/mime/cthandlers/resources/ mozilla/mailnews/mime/cthandlers/resources/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/mime/resources/ mozilla/mailnews/mime/resources/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/news/resources/locale/en-US/ mozilla/mailnews/news/resources/locale/en-US/]
To mozilla/suite/locales/en-US/chrome/messenger/addressbook/:
* [http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/resources/locales/en-US/  mozilla/mailnews/addrbook/resources/locales/en-US/]
To mozilla/suite/locales/en-US/chrome/messenger/pref/:
* [http://lxr.mozilla.org/seamonkey/source/mailnews/base/prefs/resources/locale/en-US/ mozilla/mailnews/base/prefs/resources/locale/en-US/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/compose/prefs/resources/locale/en-US/ mozilla/mailnews/compose/prefs/resources/locale/en-US/]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/mapi/resources/locale/en-US/ mozilla/mailnews/mapi/resources/locale/en-US/]*
To mozilla/suite/locales/en-US/chrome/messenger/messengercompose/:
* [http://lxr.mozilla.org/seamonkey/source/mailnews/compose/resources/locale/en-US/ mozilla/mailnews/compose/resources/locale/en-US/]
To mozilla/suite/locales/en-US/chrome/messenger-offline/:
* [http://lxr.mozilla.org/seamonkey/source/mailnews/extensions/offline-startup/resources/locale/en-US/ mozilla/mailnews/extensions/offline-startup/resources/locale/en-US/]
To mozilla/suite/locales/en-US/chrome/messenger-smime/:
* [http://lxr.moziila.org/seamonkey/source/mailnews/extensions/smime/resources/locale/en-US/ mozilla/mailnews/extensions/smime/resources/locale/en-US/]
To mozilla/suite/locales/en-US/chrome/messenger-mapi/:
* [http://lxr.mozilla.org/seamonkey/source/mailnews/mapi/resources/locale/en-US/ mozilla/mailnews/mapi/resources/locale/en-US/]*
''relevant jar.mn files (containing locale information):''
* [http://lxr.mozilla.org/seamonkey/source/mailnews/jar.mn mozilla/mailnews/jar.mn]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/extensions/mdn/jar.mn mozilla/mailnews/extensions/mdn/jar.mn]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/extensions/mailviews/jar.mn mozilla/mailnews/extensions/mailviews/jar.mn]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/extensions/offline-startup/jar.mn mozilla/mailnews/extensions/offline-startup/jar.mn]
* [http://lxr.mozilla.org/seamonkey/source/mailnews/extensions/smime/jar.mn mozilla/mailnews/extensions/smime/jar.mn]


== IRC discussion snippets ==
== IRC discussion snippets ==
=== [2007-01-12 13:39 PST] - topic: mailnews locale organization in suite ===
<br><KaiRo> Standard8Away: btw, as we usually have only one or two files there, we tend not to do a separate *-region in suite/
<br><KaiRo> phew, locale/en-US/messenger/ in en-US.jar really has all the files of the different dirs merged, (almost) no subdirs? wow...
<br><NeilZZZ> KaiRo: my memory is that addressbook and messengercompose have their own subdirs, but everything else is in that dir
<br><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/
<br><KaiRo> hmm, even pref panels are directly in mailnews/
<br><NeilZZZ> well, there are two things to consider
<br><NeilZZZ> 1) we could reorganise mailnews under suite but in jar.mn it would still be mapped to the original locations
<br><NeilZZZ> 2) we could then reorganise messenger.jar with the new locations
<br><NeilZZZ> but we could only do that for forked files
<br><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
<br><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
<br><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
<br><KaiRo> just not sure if it's correct/good to move the MAPI one there as well
<br><KaiRo> wait, that's not even a panel, that's just an overlay


=== [2006-01-17 07:00 PST] - topic: suite/ organization ===
=== [2006-01-17 07:00 PST] - topic: suite/ organization ===
Line 76: Line 186:
<br><bsmedberg> 2) is probably best
<br><bsmedberg> 2) is probably best


 
[[category:SeaMonkey|s]]
=== [2006-02-06 18:00 PST] - topic: locales/ structure ===
<br><KaiRo> gandalf: could you give me some clue about what structure we need for source L10n? we've been discussing if it needs to be suite /locales/ or could be suite/<component>/locales/ as well, and I've been wondering what implications that might have for the dir structure in /l10n repository... could you shed some light on that?
<br><gandalf> hmm
<br><gandalf> in your case...
<br><gandalf> KaiRo: what are the chances that someone will want to build seamonkey without a mail?
<br><gandalf> or browser?
<br><gandalf> or chatzilla?
<br><gandalf> or another component?
<br><KaiRo> gandalf: well, we want to be able to do that... on the other hand, I'd probably like to ship the same en-US.jar in all cases... chatzilla is in a seperate structure anyways
<br><gandalf> so, I see no reason to put locales in components
<br><gandalf> rather use locales as one of the components
<br><gandalf> so
<br><gandalf> suite/locales/browser/
<br><gandalf> erm
<br><gandalf> suite/locales/en-US/chrome
<br><KaiRo> suite/locales/en-US/chrome/browser actually :)
<br><KaiRo> (and others in the same structure, of course)
<br><gandalf> yes
<br><KaiRo> I'd just like to know what path change it might have in /l10n if we'd like to use suite/browser/locales/en-US/chrome instead (not that I myself want it, but I have to explain it to the others)
<br><gandalf> well, if you'd switch to this
<br><gandalf> it's not a big deal for localizers
<br><gandalf> they'll just to ./ab-CD/suite/browser/chrome/ instead of ./ab-CD/suite/chrome/browser
<br><gandalf> but
<<br>gandalf> it would make a pain for you to maintain l10n module code
<br><gandalf> etc. more locale makefiles
<br><gandalf> etc.
<br><KaiRo> gandalf: true... and separate jar.mn files... but some developers would actually like that better
<br><gandalf> I'm trying to figure out possible cons
<br><KaiRo> thanks... I for myself still feel better with suite/locales but not everyone is sure of that...
<br><gandalf> ok
<br><gandalf> what about strings shared between components?
<br><gandalf> where those would land?
<br><KaiRo> gandalf: that might even be spread across multiple directories, most will have the related XUl in suite/common/ though
<br><gandalf> ah, ok
<br><gandalf> so suite/common/locales ?
<br><gandalf> because otherwise, if you'll not build a component, you're dead
<br><KaiRo> gandalf: our directory structure is defined by http://wiki.mozilla.org/SeaMonkey:Suite_Directory_Layout - but you might note that we don't have concrete stuff there yet for locales
<br><KaiRo> gandalf: sure, suite/common/locales would exist then... maybe others as well though, as suite/branding/locales or so
<br><gandalf> In my opinion it's too much splitting
<br><gandalf> locales is a module
<br><gandalf> and I'd like to think of it like that
<br><gandalf> of course if we have optional components that are enough big to have it's own component dir and have a lot of l10n, those should use it's own locales dir
<br><gandalf> but usually
<br><gandalf> product/locales is ok
<br><KaiRo> Id feel better with that as well... OTOH, having all browser files in suite/borwser and all branding stuff in suite/branding has its good things as well
<br><gandalf> we use flock/locales in Flock
<br><gandalf> but we're way smaller than Seamonkey
<br><KaiRo> suite will build multiple locales/ dirs from all over the tree anyways, as we'll have all the core files, editor files, eventually chatzilla/venkman/inspector (what way ever they'll go in the future), possibly calendar - and last not least toolkit, once we'll use it
<br><KaiRo> (add reporter to the extensions-like crowd)
[...]
<br><KaiRo> gandalf: but to come back, the main argument against suite/<component>/locales/ is that it's more complicated in our original /mozilla tree, right?
<br><gandalf> yes
<br><KaiRo> ok, good to know

Latest revision as of 20:02, 7 February 2007

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.allizom.org/index.php?title=SeaMonkey:Suite_Directory_Layout&oldid=48508"