# 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:

1. 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.
2. In the Finder, increase the memory partition of the IDE to 15MB (you can get by with 12, if need be).
3. 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.

4. Open "ToolFrontEnd Panel" with ResEdit. Change the file type from 'Panl' to 'PanL'. Save.
5. 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:
   1. Open ToolServer's Tools folder. There is one file called "RMetrowerks".
   2. Move RMetrowerks to Tools folder of MPW. MPW folder must be at "Metrowerks:Codewarrior MPW:MPW" if you installed Codewarrior Heaven.
   3. Remove ToolServer's Tools folder.
   4. 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"
   5. 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.
6. 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.
7. 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"
8. 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.
9. Install RunTSScript (found in the Mozilla source distribution) in the compilers folder in your build environment ("Metrowerks:Metrowerks Codewarrior:Codewarrior Plugins:Compilers")
10. 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.
11. 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.

12. 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:"

13. 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:"

14. 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"

15. 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"

16. 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"

17. 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.
18. 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