MacFE Issues
+ +A general document on how to build, what works, what doesn't, and +things to watch out for when working on the Mac client. Please +read the entire document before you start tinkering...heck, you +may just learn something!
+ +Abbreviations you will probably see in this document:
+ +-
+
- MacFE - the Macintosh front end, including all the + things you see and some you don't. + +
- XP - cross platform back end code, mostly written in C. + You will see this used like, "This is an XP problem" which means + it's broken everywhere. + +
- MW - Metrowerks Corporation. They make our build tools + (CodeWarrior) and PowerPlant + +
- PP - PowerPlant, the GUI framework on which our app is + built + +
- CWProX - CodeWarrior Pro version X. You'll probably see + CWPro1, CWPro2, and CWPro3. We may also just refer to this as + CW. + +
- IDE - Integrated Development Environment. CodeWarrior + is an IDE. + +
- NC - the working name for our Aurora technology, the + Navigation Center. + +
- HT - HyperTree, a layer of XP APIs over RDF on which + the NavCenter is built. +
Building
+ +New 5.0 Features
+ +Unfinished Features
+ +Pitfalls
+ +History and Future
+ +Help for parts of this document, especially build instructions, +was received from Dan Kogai.
+ +
+
+
+
+Building
+
+What are the minimum machine requirements?
+ +To build Navigator, you need a fast PPC Mac. The faster the +better. You can't build with a 68K machine because we have too many +resources, and the build process will crash when trying to generate +resources out of our cross-platform strings. See the discussion below +for a way around this.
+ +You will need about 96 MB of physical RAM to "fast link" the app. +You can still fast link if you give your machine 96 MB of virtual +memory, but then the VM hit is large enough to counteract any +improvement. One of our beta testers had a machine with only 64MB of +physical RAM (VM was off) and it ran out of memory trying to link. +Turning VM on got it to link, but build time increased greatly.
+ +Reports from the net indicate that the optimized version +(MozillaPPC) take much less RAM to build than the 96MB we suggest. If +you are running out of memory, try building that instead of the debug +version (the debug symbols require a lot of RAM come link time).
+ +The moral of the story: get lots of physical RAM and don't use +VM.
+ +How big of a partition do I need for the source?
+ +You should be ok with a 400MB disk partition, even when fully +built. This does not include tools like the IDE, just source.
+ +On an HFS+ volume, a full build takes about 110MB. HFS+ is good, +but utilities are sparse.
+ +Why do I need CWPro2 or better?
+ +We use CodeWarrior as our development environment at Netscape for +the MacFE. All of the projects and tools are geared towards the +CodeWarrior IDE. In addition, we make heavy use of PowerPlant and MSL +which you can only get from Metrowerks.
+ +While we say you need at least CWPro2, you may be able to get by +with Pro1, but probably not for very long. We haven't tested it, so +we don't recommend it. Get the upgrade. CodeWarrior kicks serious +butt!
+ +How do I setup my development environment?
+ +This part is very important--and somewhat difficult (especially +when compared to other platforms). I repeat: Read very carefully! +Once this part is done right, the build process itself should be as +easy as drag and drop.
+ +Here's a list of 3rd party software that we compile into +the application and where to get it:
+ +-
+
- PowerPlant 1.8 - obtainable from the CodeWarrior CD. + +
- MSL - the Metrowerks Standard Library, obtainable from the + CodeWarrior CD + +
- WASTE + 1.3 + +
- CWASTE + 1.6.2 + +
- Menu + Sharing Toolkit (from UserLand) + +
- Mercutio + 1.5 SDK (only download the SDK, not the entire package, else + the access paths will be wrong) + +
- Internet + Config 1.4 SDK + +
- AEGizmos + 1.4.2 +
Here's a list of other build tools that you need to install +in order to build and where to get them:
+ +-
+
- MacPerl + 5 MPW Tool + +
- MacPerl 5 Application +
- MakeStub - MPW (installed with CodeWarrior Heaven option). If + you choose not to install MPW, it is located on the MacOS Tools CD + in "CW Pro 2 Tools:CodeWarrior MPW:MPW:Tools" + +
- RunTSScript - in Mozilla source distribution + (mozilla:build:mac:RunTSScript), needs to be installed by hand + +
- ToolServer + - or in the CW distribution (CW Pro 2 Tools:Apple Development + Tools:ToolServer 3.4.1.sit). We recommend pulling it off the + CD because it comes with configuration files for CodeWarrior + which you would have to create manually were you to pull it off + the net. + +
- New Alias MPW Tool + An MPW tool that creates Finder aliases for files. + + +
- StreamEdit MPW Tool - MPW (installed with CodeWarrior Heaven option). If + you choose not to install MPW, it is located on the MacOS Tools CD + in "CW Pro 2 Tools:CodeWarrior MPW:MPW:Tools" + + +
- ToolFrontEnd + +
- patch + 2.1 +
Once you have all the pieces, here are the steps required to put +everything together:
+ +-
+
- Install CodeWarrior from the CD. While it is large, installing + the "CodeWarrior Heaven" option will guarantee that you have + everything you need. This will give you PowerPlant, MSL, and MPW. + If you choose to install less, proceed at your own risk. + +
- In the Finder, increase the memory partition of the IDE to + 15MB (you can get by with 12, if need be). + +
- Download ToolFrontEnd. After expanding it, in "ToolFrontEnd
+ Folder:Drop-Ins" there are three items:
+
+
-
+
- #include + +
- ToolFrontEnd + +
- ToolFrontEnd Panel +
Create a folder named "Include Scanners". Place the file + "#include" into the Include Scanners folder. Move the Include + Scanners folder to the CodeWarrior Plugins folder. Create a folder + named "ToolFrontEnd". Place the files "ToolFrontEnd" and + "ToolFrontEnd Panel" into the ToolFrontEnd folder. Place this + folder in the CodeWarrior Plugins folder.
+
+ - Open "ToolFrontEnd Panel" with ResEdit. Change the file type + from 'Panl' to 'PanL'. Save. + +
- Uncompress the StuffIt Archive for ToolServer. The goal is to
+ let ToolServer and MPW share the same Tools directory so you don't
+ need to have multiple versions of tools. Do the following:
+
+
-
+
- Open ToolServer's Tools folder. There is one file called + "RMetrowerks". + +
- Move RMetrowerks to Tools folder of MPW. MPW folder must be + at "Metrowerks:Codewarrior MPW:MPW" if you installed + Codewarrior Heaven. + +
- Remove ToolServer's Tools folder. + +
- Now create an alias of Tools folder in "CodeWarrior MPW" + and move it to your ToolServer folder. Rename the alias + (probably called "Tools alias") to "Tools" + +
- IMPORTANT: Make sure + you only have one instance of ToolServer on your machine. If + the build script finds the wrong one, the correct tools will + not be found and strange things will happen. +
+
+ - After installing the MacPerl MPW Tool distribution (run the + InstallerVISE application), in the "MacPerl ƒ" folder, there + will be an MPW tool named "perl". Install this in MPW's tools + folder. + +
- Install the MacPerl Application (run the + InstallerVISE application). You can install this anywhere, but it is + recommended that you install it inside of your CodeWarrior folder for + easy reference. After installation, you will need to set a preference + to enable double-click launch of the perl scripts. This preference is set + by going under the Edit Menu to Preferences. Click on the "Script" button + and hit the radio button "Run Scripts opened from Finder" + +
- Install the "patch", "MakeStub", "NewAlias" and "StreamEdit" Tools in the tools + folder. Note that "MakeStub" and "StreamEdit" are automatically installed by the + "CodeWarrior Heaven" install option. + +
- Install RunTSScript (found in the Mozilla source distribution) + in the compilers folder in your build environment + ("Metrowerks:Metrowerks Codewarrior:Codewarrior + Plugins:Compilers") + +
- Next, after downloading all the 3rd party software components, + drag WASTE, CWASTE, Menu Sharing, Mercutio, Internet Config, and + the AEGizmo folders (just as they are) into the "MacOS Support" + folder in your build environment. + +
- Start ToolServer from within CodeWarrior (or use MPW if you
+ are brave enough). We're about to patch some files. Make sure the
+ ToolServer menu is in the CodeWarrior menu bar by turning on the
+ preference under the "Extras" panel in
+ the IDE Preferences (not the project preferences!). The menu bar
+ should look like this:
+
+
+ +
Choose "Start ToolServer" from the ToolServer menu (this is the + icon menu between "Window" and "Help" in the menubar above). You + will now see a window with no close box. This is your ToolServer + Worksheet where you will type (or cut & paste) the commands + for the following steps.
+ +In case you have never used MPW/ToolServer before, the + following is very important. Pressing "return" does not + execute commands like you might think. It just inserts a newline + into the worksheet like a normal text editor. To actually get + ToolServer to execute the command, you must press "Enter" (lower + right of numeric keypad). This executes the line that the + cursor is on, and only that line. If you want to execute multiple + lines at once, select them all and hit Enter.
+
+ - Set the shell variables {IDE} and {Source} to the correct
+ paths for your build environment. {IDE} is where your CodeWarrior
+ IDE is located. {Source} is the folder containing the toplevel
+ "ns" folder of the Mozilla source. Mine look like this (don't
+ forget to keep the quotes if your path includes spaces), yours
+ will almost certainly be different (to
+ punctuate this, the things you need to change are in red).
+
+
Set IDE "Develop:Source331 Build Environment:CW Pro 2:Metrowerks CodeWarrior:" +Set Source "Source:FreeSource:"
+
+ - If you are using CWPro2, execute the following lines to patch
+ LDropFlag to draw correcly over non-white backgrounds. You do
+ not have to do this if you are using Pro3 because it has been
+ fixed.
+
+
directory "{IDE}MacOS Support:PowerPlant:_In Progress:_Table Classes:" +patch LDropFlag.cp "{Source}mozilla:lib:mac:patches:LDropFlag.patch" +duplicate -y "{Source}mozilla:lib:mac:patches:DropFlag Icons.rsrc" "{IDE}MacOS Support:PowerPlant:PowerPlant Resources:"
+
+ - Execute the following lines to patch menusharing.c to allow it
+ to compile with the new Universal Headers. It references an
+ obsolete header file (GestaltEqu.h).
+
+
directory "{IDE}MacOS Support:Menu Sharing Toolkit 4.1:" +patch menusharing.c "{Source}mozilla:lib:mac:patches:menusharing.patch"
+
+ - If you are using CWPro2 straight off the CD, you need to patch
+ AppleEvents.r to fix a problem with the Universal Headers (the
+ definition of the 'aedt' resource was omitted). You do not have
+ to do this if you have applied the netborne patch to Pro2 or are
+ using Pro3 because it has been fixed.
+
+
directory "{IDE}MacOS Support:Headers:Rez Headers:" +patch AppleEvents.r "{Source}mozilla:lib:mac:patches:AppleEvents.r.patch"
+
+ - You need to patch stat.mac.h to fix a problem in MSL where
+ lines were omitted (both CWPro2 and Pro3 share this problem)
+
+
directory "{IDE}Metrowerks Standard Library:MSL C:MSL Mac:Public Includes" +patch stat.mac.h "{Source}mozilla:lib:mac:patches:stat.mac.h.patch"
+
+ - If you are using CWPro3, you have to unstuff and copy the old + Grayscale Appearance classes into the PowerPlant hierarchy. As of + Pro3, they are now obsolete and are located with the rest of the + obsolete PowerPlant files. We'll fix this shortly. + +
- Congratulations! Now you are ready to build. Once these steps + are done, you don't have to repeat these setups the next + time! +
Ok, so how do I build?
+In the folder mozilla:build:mac:, there are several Perl scripts with +names of the form BuildMozillaXXX.pl, where XXX is "Optimized", +"Debug", "Tinderbox", et al. Each script builds the corresponding +version of Mozilla. If you configured the MacPerl application to +execute scripts that are opened from the finder, all you have to do is +double click on the appropriate one; otherwise, launch MacPerl, and +run the appropriate script from the "Run Script..." menu item.
+ +These `configured build' scripts are simple, and you might want to +make your own to force your build to StopForErrors(), or alternatively +DontStopForErrors(), et al. You can set up certain build-script +variables and (soon) compile-time flags. Compare the supplied scripts +to figure out what you might want. Note that CodeWarriorLib, Moz.pm, +and BuildList.pm, are AppleScript libraries and Perl modules meant to +be used by a `configured build'. Use your favorite POD viewer (Shuck +comes with MacPerl) to view the documentation in the Perl scripts.
+ +If there were any errors in any of the projects along the way, the +script will stop at that point and the IDE will tell you the errors. +You can fix them and make sure they current project builds, but to +continue the automation, you have to start from the beginning by +double-clicking the script again. This isn't quite as bad as it +sounds because the previous projects are already built (unless you +changed some major header file). Please note that stopping the script +once it has started is difficult. We are working to address +this issue.
+ +After the build is complete, you can find aliases to the built libraries +and the final Mozilla application. Debug builds are built to +Mozilla:dist:client_debug, while optimized builds are built to Mozilla:dist:client. +
+ +Don't worry too much about the numerous warnings generated during +the build. We try our best to get the XP teams to use real compilers, +but alas, they continue to write warning-laden code. There is also +some generated code (Java is one example) that has a lot of warnings +that we can't help either. If you write any new code, please help us +in our quest to get zero warnings.
+ +How long does it take to build?
+ +On a G3 with the source and IDE on a RAM disk, it takes about 25 +minutes. On a PowerTowerPro 225 and everything on the hard drive, it +takes about 45mins to an hour. On a 9500/132 it takes over 2 1/2 +hours.
+ +The moral of the story: Don't try this on your 6100/66.
+ +From Dan Kogai:
+ +It took me 70 minutes to build Mozilla Debug with + configurations below; + ++ +PowerMac 7600/120
+ 192MB RAM (No VM)
+ 1 + 4 GB HD (No RAM Disk)
+ MacOS 8.1
+ CWPro2
+ HFS+
What's special about running the debug build?
+ +Running the optimized (non-debug) version is easy, just +double-click it and it will work. This is because all the shared +libraries are compiled directly into the application. We don't do +this with the debug version to facilitate changing bits in projects +other than the main one. This way, you don't have to relink the +entire app (which can take a while) to see the changes, just the +project that was modified.
+ +As a result, you have to find a way to get all the shared +libraries from where they are built (scattered throughout the tree) +into the same folder as the app so CFM can find them. Luckily, the +BuildList script will create all these aliases for you and put them +in the right places!
+ +Another nicety about the debug build is that there is a special +"trace" function which can be used to display messages about the +state of the application as it runs through certain blocks of code. +To see these messages (since the Mac doesn't have stdout or stderr) +you need to run an application called TraceMonitor. TraceMonitor is +available through Apple Computer with the ASLM package. +
+ +How do I build a 68K version?
+ +For now, you can't. The projects have not been kept up to date and +aren't even in the tree anymore. If you would like to create them and +get all the exports right with CFM-68K, go right ahead. We will be so +happy!
+ +Why use IDE_Options.h when all that is in the project file?
+ +It was originally intended to make sure that all 300 of us at +Netscape are using the same environment and compilation flags. If +something gets turned on/off by accident in the project prefs, it can +introduce a subtle bug that can take days to track down for naught. +Having a file that specifies exactly what flags should be used +guarantees that this can't happen.
+ +Now that we move to net development, I'm sure you will agree that +this is even more important.
+ +
+
+
+
+New 5.0 Features
+
+Navigator Center (Aurora)
+ +The Navigation Center (referred to as "Aurora" in press releases) +is an attempt to make it easier to access and organize information on +the web. The NC unifies Bookmarks, History, Search, and local files +into a sequence of workspaces which are accessible from a single +location in the browser window. One of the ways the NavCenter +diverges from a similar concept seen from our competition is the +ability for users to create their own workspaces to organize and +store information from both the web and their desktop.
+ +-
+
- Main access point is a bar along the left side of the + browser. + +
- Each icon represents a workspace. Click any workspace icon + once to slide out a hierarchical tree (like the list view in + the Finder) that displays the information appropriate to that + workspace. You can manipulate the URLs and folders in the tree + while you are surfing the web in the adjacent pane. + +
- Clicking on another workspace while the shelf is open switches + to showing the contents of that workspace. + +
- To hide the shelf, click the close box above the column + headers + +
- To create new bookmarks, drag bookmarks from the location
+ bar of the browser into the NC and file them where you want.
+ Of course, the old methods still work.
+
+
-
+
- If the NC shelf is not open, drag to the workspace where + you want to file the bookmark and after a small delay, the + shelf will spring open. You can now drop your new + bookmark exactly where you want. + +
- If the workspace you want is not displayed, drag over that + workspace and after a small delay, the contents of that + workspace will become visible. +
+
+ - You can also open a stand-alone NC window from the + Communicator menu. The standard "cmd-b" and "cmd-h" for bookmarks + and history are wired to open a new NC window with the appropriate + workspace visible. + +
- You can hide the list of workspaces at the left of the + browser window by choosing "View:Hide NavCenter Selector". You can + show it again by doing the same thing. Even when hidden in the + browser, the stand-alone versions are always available. + +
- Drag bookmarks to the trash to delete them. You can also hit + the "delete" key (backspace) to remove bookmarks. + +
- The NavCenter is fully context-menu savvy. There are + many commands that are in context menus that are not in the main + menubar (right now). + +
- ToolTip savvy. Both the title and URL can be seen in + their entirety by hovering over the appropriate column. + +
- 3-state sorting: alphabetical, reverse-alphabetical, + none. Like in the Finder, setting a sort does not change the + hierarchy or make any permanent modifications to your + organizational structure. +
Personal Toolbar
+ +-
+
- A toolbar to store bookmarks, first seen on Win/UNIX in 4.0. + Single click to load URL in current browser window + +
- Drag and drop bookmarks to the toolbar to add them. + Drag existing bookmarks on the toolbar to rearrange the order. + Drag bookmarks to the trash can to remove them from the + toolbar. + +
- Dynamically allocates horizontal space to buttons on + toolbar. Adding new buttons shrinks existing ones, removing + buttons distributes the vacated space to existing buttons. + Changing the window width reallocates space accordingly. + +
- You can further manipulate, rename, rearrange, add to and + remove the URLs in the folder that represents the personal toolbar + in the Navigation Center. + +
- ToolTips show the full title. +
Navigator
+ +-
+
- new "Mariner" technology makes table layout much faster and + does not reload the page when the window is resized. + +
- buttons/popup menus in the chrome now look more like MacOS + controls. +
Composer Features
+ +-
+
- Drag and Drop + +
- Direct manipulation editing of tables +
+
+
+
+Unfinished "Features"
+
+This source release is not of beta quality, hence it will have +lots of bugs that a normal beta (or even an alpha) would not have. +There are many features which we are not even close to being finished +with, let alone knowing what the final UI will be. Here are some +things that we know about but didn't have time to get to before the +code left the building. Feel inclined to help us out? +Grrrrrrreat!
+ +Aurora
+ +Aurora is definitely a work in progress. Here are the bugs that we +just don't have time to fix
+ +-
+
- Real icons for files on disk + +
- changing view from XP code (e.g., JavaScript) has not been + tested, but should work + +
- move vs. copy notification (cursor doesn't change, etc. No XP + support for this yet) + +
- double-click on the text of an item should launch the url, not + trigger an in-place edit + +
- separator needs UI consensus and its own icon + +
- drag & drop
+
+
-
+
- can't disallow drags to trash when pane is read only. Trash + will still highlight even though nothing will happen. + +
- occasional -49 error when dragging repeatedly to browser + window. I think the DragManager is corrupt because -49 is not a + drag manager error and d&d doesn't work anywhere else after + that. + +
- drag feedback doesn't work correctly when view is sorted or + when some items are local vs. remote. + +
- Composer needs to correctly handle HT_Node flavor + +
- Sometimes things will move, other times they will copy. Its + an XP thing. +
+
+ - Chrome properties not correctly respected (relies on personal + toolbar being hidden to hide NavCenter) + +
- sort state of columns not saved (nor is anything else with + columns) + +
- we shouldn't be using HT_SetNodeName(). Use HT_SetNodeData() + instead + +
- Open/Close context menu does not redraw disclosure triangle + after executing + +
- There are currently no user configurable prefs for Aurora. + This will change. + +
- You can't edit the URL field because RDF uses this as the key + in its database. As a result, having two bookmarks in the same + workspace can lead to odd behavior + +
- Undo/redo does not work yet (XP problem) + +
- Cut deletes nodes, it does not put them on a clipboard. + Copy/paste do nothing. This is an XP problem. +
Still major work to do:
+ +-
+
- create new workspaces with d&d + +
- rollover feedback on selector + +
- sitemap notification + +
- scroll selector bar + +
- HTML pane/search pane + +
- spring-loaded folders on d&d +
General FE Problems
+ +-
+
- DNS lookups may hang up the machine for up to a minute. + Don't worry, your mac did not freeze! + +
- FTP doesn't work quite right. URLs typed into the location bar + will not load and the MIME mappings (save to disk, etc) are broken + so everything is loaded into the browser window instead of saving + to disk. + +
- frame around current tab group broken + +
- tabbing around to text entry areas and back to the Location + field is broken + +
- can't drag from Navigator when app is in background + +
- Folders on personal toolbar. Sigh, unless we can rewrite the + bookmarks menu code, we just don't have enough hierarchical menu + id's to put menus on personal toolbar folders. They still act as + drop sites, so you can drop urls into them but clicking on them + will just beep. + +
- Printing is....sub-optimal. + +
- "Mariner" layout improvements are nice, but on very + complicated pages the machine will hang for a few seconds while it + is relaying out the page. This can last 4-6 seconds sometimes. + This really looks bad when the NavCenter shelf is sliding out + during a drag and drop. If you are patient enough, you will be + rewarded, but it is slow. +
+
+
+
+Pitfalls
+
+There are a couple of pitfalls that we have to keep straight when +it comes to editing resources.
+ +Why do I keep getting messages about unknown custom types in +Constructor?
+ +For starters, make sure you have an alias to the following two +files in your Constructor folder:
+ +-
+
- mozilla:cmd:macfe:rsrc:CrossProduct:Mozilla_Custom_CPPbs + +
- mozilla:cmd:macfe:rsrc:Communicator:MailNewsCppbs.cnst +
You may have to explicitly open these files up while running +Constructor to be able to see the new types, especially for the ones +in MailNewsCppbs.cnst. Not sure why yet.
+ +For editing other kinds of resources, we have a TMPL file for +ResEdit/Resourcerer. Place these in the appropriate location for your +resource editor
+ +-
+
- mozilla:cmd:macfe:rsrc:CrossProduct:Mozilla_Custom_TMPLs + +
- mozilla:cmd:macfe:rsrc:CrossProduct:Other_Comm_TMPLS.rsrc +
Why don't my toolbar buttons work anymore in the browser +window?
+ +Because of the way we have the toolbars as CIncludeViews (which +work in a similar way to #include in C/C++), the RidL will be messed +up if you edit the main browser window PPob. Constructor regenerates +this list based on all the controls that are in the view when you +save, but because we use CIncludeView, the toolbar buttons aren't +actually in the view so the RidL is empty. They will still show up +when you build, but they won't do anything because they are not +registered with the browser window. Until we fix this, just use +Resourcer to replace the incorrectly generated one with an old +version. The old version is about 58 bytes long and the new one is +about 10 so you should be able to easily tell which is which.
+ +Why are there so many damn resources?
+ +As you may have noticed, we've got too many damn resources. Most +of them are 'STR ' resources which are generated at build time and +contain all of our cross-platfrom strings. We would like to generate +these resources more intelligently (into 1/10 the number of 'STR#' +resources maybe) but ran out of time before the source had to go out. +Before you rush out and change it for us, stop! There are some +constraints on the final solution, mostly to do with i18n and l10n +being able to leverage existing work on older product to do new +products. If you want to help us out with this, please send us some +email and we can have out i18n team talk with you to make sure it +gets done correctly!
+ +Why doesn't it work better with Internet Config?
+ +For starters, the main reason why we never drank the IC kool-aid +was that there was no support for multiple profiles. Being one of the +main features which our competition did not have, we thought this was +pretty important. There are rumblings in the IC world that IC 2.0 +will support multiple profiles. Great! That still leaves us with the +second reason: there are many, many, many preferences that we use +that are not reflected in IC. As a result, we already have to +maintain prefs for those that are not covered by IC so we can't be +totally IC dependent.
+ +Of course, now that the source is free, maybe we can drive the +direction of IC to include all of our wacky networking prefs.
+ +Where are all my old 4.0X bookmarks and prefs?
+ +In the process of getting the source ready for distribution, we +removed all mentions of "Netscape" from the product. As you may know, +the 4.0X preferences are stored in a folder called "Netscape Users." +Well, that folder is now called "Navigator Users" and the preference +file is now called "Navigator Preferences" instead of "Netscape +Preferences."
+ +It's probably best not to use any of your old prefs at this point +since some of them rely on security calls that are no longer in the +free source product. After you create a new profile (and you will +have to when you start the free source), copy your bookmarks.html +file from your old profile into the new user profile folder and +replace the empty one that's already there (if there is one).
+ +For your old bookmarks to be seen, you must throw away the +"NavCntr" folder created in your new profile folder. After you do +that bookmarks will be imported into Aurora automagically. Note that +changes that you make to your bookmarks in 5.0 will not (as of today) +be written back to the Bookmarks.html file, but instead are stored in +a database within the "NavCntr" folder. If anything gets corrupted in +the NavCenter, you can always throw this folder into the trash and +your original bookmarks will be reimported.
+ +Also note that these new bookmarks and preferences are totally +separate from your 4.0X prefs.
+ +
+
+
+
+History and Future
+
+History
+ +Excuse me while I ramble...
+ +-
+
- Built using Metrowerks PowerPlant, the client has been PPC + native from day one. 68K support was dropped in 5.0 due to the + high cost of maintenance. Any takers? + +
- Mail/News was added in 2.0 and Composer was added in 3.0 + (called Navigator Gold). Both were dramatically improved with + 4.0. + +
- Java came to the Mac in 3.0, even though Windoze and unix had + it in 2.0. + +
- Multi-byte language support for inline edit fields added in + 4.0 + +
- The preferences used to be STR# resources. Now they are done + in javascript. + +
- Because of the sheer number of resources (and the "theoretical + limit" on the number of resources in a file imposed by the + Resource manager -- which we still exceed on a daily basis), a + number of strings and icons were moved out of the main application + and into a file called "Netscape Resources" in 4.0 + +
- For plain-text email/form composition, we used VText up + through 4.0. For 5.0, we switched to WASTE because of its minimal + impact on the PowerPlant hierarchy. VText caused us fits every + time we wanted to upgrade to a newer version of PowerPlant because + it wrapped its tentacles around every limb of PowerPlant. + +
- 4.0 included a new memory management scheme which drastically + reduced the amount of memory used by the client. This is why the + memory partition of 4.0 is about half of 3.0. + +
- A version of Navigator sans Mail/News/Composer debuted with + 4.03, and again two days later with 4.03.1. +
Future
+ +There is certainly a lot to do. In order to not duplicate too much +work (since we are still working on this full time here at Netscape), +I've put together a list of what we plan on doing and what we want to +do but probably won't get around to because of time constraints.
+ +Things that we are going to focus on:
+ +-
+
- More NavCenter work + +
- Solve the issues with too many 'STR ' resources (see note on + issues page) + +
- Modularization (HTML display isolated from networking, + etc) + +
- use new Appearance Manager classes in PowerPlant + +
- Navigation Services (new open/save dialogs in Allegro) + support. We have an ancient SDK and have integrated it in a few + places, but the current implemenation that we have doesn't work + very well. It's cool, though. + +
- More drag and drop in composer. + +
- More support for Internet Config (see note on issues + page). + +
- external Java VM support (MRJ, etc) +
Things we would like some help on:
+ +-
+
- printing support + +
- 68K version + +
- Context Menu Manager support + +
- bug fixes of any kind + +
- performance tuning of any kind + +
- getting around the limitation of 255 hierarchical menus + imposed by the OS. This would let us do a "real" personal toolbar + with folders that have popup menus. + +
- Fixing the build system so it uses makefiles without having to + give up the CW IDE for source browsing/editing. + +
- better publishing in Composer + +
- add NavCenter to Composer window + +
- better table editing in Composer +
+ +Mike Pinkerton (pinkerton@netscape.com) + + + diff --git a/README/mozilla/unixbuild.htm b/README/mozilla/unixbuild.htm new file mode 100644 index 00000000000..6bd661ba9cd --- /dev/null +++ b/README/mozilla/unixbuild.htm @@ -0,0 +1,82 @@ + + +
+Unix Build Instructions
+This document explains how to build Mozilla for Unix. ++
+
Requirements:
+
+ Memory:
+ 32MB of RAM, 128MB of swap, recommended 64MB of RAM.
+
+ Tools:
+ GNU C/C++ compiler 2.7.2 or better
+ GNU make 3.74 or better
+ Motif 1.2 (Lesstif has been used with limited success)
+
+ Tools that will be helpful later:
+ Perl 5.0
+ CVS 1.8.1
+ RCS
+ gdb 4.16
+
+ NOTE:
+ * gcc version 2.8 has been used successfully.
+ Your mileage may vary.
+
+Build:
+
+ Untar the tar.gz file with the following (or your favorite variant thereof):
+
+ gzip -dc tarball.tar.gz | tar -xvf -
+
+ Set the following environment variables:
+ csh/tcsh:
+ setenv NO_SECURITY 1
+ setenv MOZ_MEDIUM 1
+ setenv MOZILLA_CLIENT 1
+ setenv NO_MDUPDATE 1
+
+ sh/bash/ksh:
+ NO_SECURITY=1
+ MOZ_MEDIUM=1
+ MOZILLA_CLIENT=1
+ NO_MDUPDATE=1
+ export NO_SECURITY MOZ_MEDIUM MOZILLA_CLIENT NO_MDUPDATE
+
+ Debug build is default; optimized build:
+ setenv BUILD_OPT 1
+ (BUILD_OPT=1; export BUILD_OPT)
+
+ On AIX, append /usr/lpp/xlC/bin to your PATH.
+ On Solaris, SINIX, and UnixWare, prepend /usr/ccs/bin to your PATH.
+
+ Build it. Default target is "export libs install":
+ cd mozilla
+ gmake
+
+NOTE:
+
+If you haven't got perl:
+
+setenv PERL /bin/echo
+
+gmake -e
+
+Run the app:
+ Executable lives in mozilla/cmd/xfe/{ARCHITECTURE}.{DBG|OPT}.OBJ
+ (e.g. mozilla/cmd/xfe/Linux2.0.31_x86_DBG.OBJ/mozilla-export)
+ Statically-linked app is "mozilla-export"
+ dynamically-linked app is "moz-export"
+
++
+WinFE Build Instructions
+This document explains how to build Mozilla for the Windows platform. WinFE +is the Windows front end module. +Required Tools: +
-
+
- +Microsoft Visual C++ version 4.2 or later + +
- +GNU Tools for Windows:You can find these all over the web. Specifically, +you'll need: + +
cp.exe + + rm.exe+ +
- Here are some sample download sites to find these:
+
- +Cygnus + +
- +GNU home page + +
- +MIT +
gmake.exe + + shmsdos.exe + + uname.exe+These are located in the \tools\bin directory of the source package. All +of these tools need to be put in your path. +
-
+
- +You need a Pentium with at least a 133 MHz processor and at least 250 megs +(NTFS partition) or 500 megs (FAT partition) of hard drive space. You need +to have a minimum of 64 megs of memory in order to build this tree. Having +at least 128 megs of memory will make your debugging experience noticeably +less agonizing + +
- +The preferred platform is NT 4.0. NT 3.51 will also work, and Win95 might +work if you're lucky. Maybe. + +
- +Install MSVC. If you don't choose to have the MSVC install modify your +environment variables for PATH, INCLUDE, and LIB information, be sure to +run VCVARS32.BAT out of the MSVC bin directory prior to attempting to build. + +
- +Download and install GNU tools. Put them in your path. + +
- +Install Mozilla source. + +
- +There are several environment variables you will need to set, either manually +or via a script within a command session, or by setting them in your system +environment located through the Control Panel | System icon. Those variables +are: + +
- +set MOZ_BITS=32 + +
- +set MOZ_DEBUG=1 (don't set this if you want to build an optimized release +build) + +
- +set MOZ_GOLD=1 + +
- +set MOZ_MEDIUM=1 + +
- +set MOZ_NT=351 (if running NT 3.51, don't set otherwise) + +
- +set MOZ_OUT=(location of resulting executable and totally optional, see +Notes for more details) + +
- +set MOZ_SRC=(top of your tree, drive letter and path, i.e. set MOZ_SRC=d:\mozilla_src. +The topmost directory under this should be mozilla) + +
- +set MOZ_TOOLS=(location of the bin directory containing your GNU tools. +The build looks for MOZ_TOOLS\bin\gmake.exe, so make sure your MOZ_TOOLS +is figured appropriately) + +
- +set NO_SECURITY=1 + +
- +set NSPR20=1 + +
- +if you are running VC++ 5.0 or higher: set _MSC_VER=1100 +
-
+
-
+
- +You need to be running a vanilla command prompt. Other shells may work, +but you might have to tweak makefiles. + +
- +Build the tools: This generates several tools that handle things +like dependency generation + +
- +cd mozilla\config + +
- +nmake /f makefile.win +
- +Build the whole lizard: This will do a complete build of the source +tree. You will end up with a mozilla.exe at the end. + +
- +cd mozilla + +
- +nmake /f client.mak +
-
+
-
+
-
+
- +If you want to build communicator a piece at a time, these are the steps +that client.mak steps through. If you successfully ran the client.mak step +above, you don't need to do this. + +
- +Build the back end: This builds cross platform components like NSPR +and the shared library modules. All of the interesting output from this +part of the build will end up in mozilla\dist, under public\ if it's a library +header, and under WIN32_D.OBJ\ (or WIN32_O.OBJ\ for an optimized build) +if it's a dynamic or static library. The exception is the NSPR public headers, +which live in WIN32_D.OBJ\include. + +
- +cd mozilla + +
- +nmake /f makefile.win +
- +Build the front end: This builds and links into the final executable, +mozilla.exe. + +
- +cd mozilla\cmd\winfe\mkfiles32 + +
- +nmake /f mozilla.mak DEPEND=1 + +
- +nmake /f mozilla.mak +
-
+
-
+
-
+
- +MOZ_OUT: If you don't set this, mozilla.exe will be generated into mozilla\cmd\winfe\mkfiles32\x86dbg +(or x86rel for optimized builds) + +
- +This build process does not use Visual C++ generated project files for +several reasons having to do with (among other things) size, maintainability, +and the long term desire to start using more of tools like gmake, or plug +and play developer tools. This does not preclude you from using the Visual +C++ IDE, or it's debugger (somebody fill this out with more detail). + +
- +All of the DLLs that you need to run mozilla.exe get copied automagically +into your output directory as the last part of build, so all you need to +do is cd into x86dbg and run mozilla.exe to get a runnable browser. + +
- +On a Pentium II 266 MHz machine with 128 megs of memory, it takes approximately +30 minutes to build. Your mileage may vary. +
+
+Running Mozilla Without Trashing Netscape +Installation
+This document explains how to run mozilla.exe separately from +netscape.exe without trashing your regular installation of Netscape +Communicator. This is necessary if, for example, you want to use Communicator's +mail client while you work on Mozilla development. ++
+
-
+
- +Before running mozilla.exe, create a new user profile either from +a Netscape 4.0x installation using the "User Profile Manager" shortcut +in the Utilities folder (on Windows) or by using the -new_account +option on the command line of either netscape.exe or mozilla.exe. +We suggest calling the profile "mozilla." + +
- +Always use that new account when running mozilla.exe, and never +run netscape.exe using that same account profile. +
- mozilla.exe -P"mozilla"
important as new prefs are added to the Mozilla product. Note that +you must use quotes around the name and there can be no space between the +"P" and the profile name. Otherwise, the application won't catch the profile +switch, and it will try to load the profile name as the initial URL. + +
+
+
You can copy your bookmark.htm file from an existing profile +to your new profile directory if you want to share bookmarks. + +
After the initial 3/31 release, we will add some code to Mozilla to
+prevent running with a profile that is already being used by netscape.exe.
+
+
+
Copyright © 1998 Netscape +Communications Corporation + + diff --git a/README/nglayout/winbuild.html b/README/nglayout/winbuild.html new file mode 100644 index 00000000000..254d085ea21 --- /dev/null +++ b/README/nglayout/winbuild.html @@ -0,0 +1,184 @@ + + + + + + +
+NGLayout Windows Build Instructions
+This document explains how to build NGLayout for the Windows platform. +Required Tools: +
-
+
- +Microsoft Visual C++ version 4.2 or later + +
- +The same set of tools for building Mozilla +
-
+
- +You need a Pentium with at least a 133 MHz processor and at least 250 megs +(NTFS partition) or 500 megs (FAT partition) of hard drive space. You need +to have a minimum of 64 megs of memory in order to build this tree. These +numbers are approximations. + +
- +The preferred platform is NT 4.0. NT 3.51 will also work, and Win95 might +work if you're lucky. Maybe. + +
- +Install MSVC. If you don't choose to have the MSVC install modify your +environment variables for PATH, INCLUDE, and LIB information, be sure to +run VCVARS32.BAT out of the MSVC bin directory prior to attempting to build. + +
- +Download and install GNU tools. Put them in your path. + +
- +Install NGLayout source. + +
- +cd <your-source-area> + +
- +unzip -o -q win-19980415.zip +
- +There are several environment variables you will need to set, either manually +or via a script within a command session, or by setting them in your system +environment located through the Control Panel | System icon. + + +
- +set MOZ_BITS=32 + +
- +set MOZ_DEBUG=1 (don't set this if you want to build an optimized release +build) + +
- +set MOZ_GOLD=1 + +
- +set MOZ_MEDIUM=1 + +
- +set MOZ_NT=351 (if running NT 3.51, don't set otherwise) + +
- +set MOZ_OUT=(location of resulting executable and totally optional, see +Notes for more details) + +
- +set MOZ_SRC=(top of your tree, drive letter and path, i.e. set MOZ_SRC=d:\mozilla_src. +The topmost directory under this should be mozilla) + +
- +set MOZ_TOOLS=(location of the bin directory containing your GNU tools. +The build looks for MOZ_TOOLS\bin\gmake.exe, so make sure your MOZ_TOOLS +is figured appropriately) + +
- +set NO_SECURITY=1 + +
- +set NSPR20=1 + +
- +if you are running VC++ 5.0 or higher: set _MSC_VER=1100; if you are running +VC++ 4.2 then set MOZ_VCVER=42 + +
- +set STANDALONE_IMAGE_LIB=1 + +
- +set MODULAR_NETLIB=1 +
-
+
Note: There is an additional variable for building NGLayout! +Use this list carefully! + +
The variables are: +
-
+
-
+
- +You need to be running a vanilla command prompt. Other shells may work, +but you might have to tweak makefiles. + +
- +Build the tools: This generates several tools that handle things +like dependency generation + +
- +cd mozilla\config + +
- +nmake /f makefile.win +
- +Build the NGLayout: This will do a complete build of the source +tree. You will end up with a viewer.exe at the end. The viewer.exe will +be in your dist\win32_[OD].obj\bin directory (O will be used when you don't +set MOZ_DEBUG; D will be used when you set MOZ_DEBUG). + +
- +cd mozilla + +
- +nmake /f nglayout.mak +
-
+
-
+
-
+
- +Once you have built the system, do this to run the viewer program (the +viewer program is a simple test program that uses the nsIWebWidget API +to embed a web widget object). The viewer program has a few basic menu +items, include "Samples" which load sample tests. + +
- +cd mozilla\dist\win32_[OD].obj\bin + +
- +.\viewer.exe +
-
+
-
+
- +This build process does not use Visual C++ generated project files for +several reasons having to do with (among other things) size, maintainability, +and the long term desire to start using more of tools like gmake, or plug +and play developer tools. This does not preclude you from using the Visual +C++ IDE, or it's debugger. Once you have built a viewer.exe do this to +run it under the debugger: +
-
+
- +cd mozilla\dist\win32_[OD].obj\bin + +
- +msdev viewer.exe +
-
+
+