Last revised: 09Nov01 GLGAll the code in the WeatherEase Toolkit is platform-neutral except for a single class and one line in another class. Except for these two cases, all the source should compile under any Java installation compatible with JDK 1.1 or later. There is nothing else that's special about rebuilding the toolkit.
The single platform-specific class is app.util.MacAppFrameAdapter.The one line that refers to app.util.MacAppFrameAdapter is in app.weather.watch.Main.
The MacAppFrameAdapter class is a Mac-friendly connection to underlying application-interface capabilities. If you don't use the demo app, or you edit the Main class to remove the one line, then no other platform-specific code exists anywhere else in the WeatherEase Toolkit.
The decision of whether to be Mac-friendly or not is entirely up to you. If you are not targeting Mac OS as a platform, and do not wish to preserve the Mac-friendly features provided by MacAppFrameAdapter, you can omit the class and change the one line that refers to it in Main. Editing Main constitutes a source change, however, so you must redistribute the source of your changed version of Main.
If you wish to preserve the Mac-friendly features, then you must compile and run the app against the included MRJToolkitStubs.jar file. Any programs you write that refer to MacAppFrameAdapter must also be distributed with MRJToolkitStubs.jar, either bound into the same JAR as the app, or otherwise available in the class-path. If you don't include MRJToolkitStubs.jar in some way, then your program won't be able to load the MacAppFrameAdapter, and your program will not run.
Be sure you recompile the source against the included MRJToolkitStubs.jar file. I recommend compiling into a JAR file, so long class file-names are preserved.The distributed demo app was created using JBindery from the MRJ SDK. The creator-ID is 'WWac'. (I have not officially registered this creator ID with Apple.) Be sure to include the "Watcher-resources.rsrc" resource-file from the "Resources for demo" folder when you rebuild the app. I recommend that you also read the contents of "Watcher-merging.properties" to learn what values to assign to the JBindery-created app, such as default fonts, heap-sizes, etc.
You can also rebuild the classic Mac OS apps using MRJAppBuilder from the MRJ SDK. I have included the configuration properties files to do this in the "Watcher-merging.properties" file. This properties file is configured to build a merged application. That means you must add an appropriate JAR-file (i.e. WeatherEase.jar or your recompiled JAR) to MRJAppBuilder's "Files to merge" list, along with the "Watcher-resources.rsrc" file.
I chose to distribute the classic Mac OS demo as JBindery-built apps, rather than as apps built by MRJAppBuilder. This is mainly because JBindery-built apps will work on older versions of MRJ, as far back as MRJ 2.0. Apps built by MRJAppBuilder, on the other hand, will only work under MRJ 2.2 or higher. This would prevent the demo from working on older platforms, such as 68040 machines under MRJ 2.0, and I didn't want to do that.
Be sure you recompile the source against the included MRJToolkitStubs.jar file.The Mac OS X demo was originally created using MRJAppBuilder on Mac OS X 10.0. It's a tool that's included with the Mac OS X Developer Tools. Thereafter, I edited the configuration files using the Mac OS X tools "PropertyList Editor" for the Info.plist, and "TextEdit" for the MRJApp.properties. Double-clicking Info.plist launches the right program, but you have to drag-n-drop MRJApp.properties onto TextEdit. To get to those files on Mac OS X, contextual-click on the "Weather Watcher" application and choose the "Show Package Contents" contextual-menu item to see the internal anatomical structure of the app. Edit the files where they are (make a duplicate first, in case you blunder in editing), because Mac OS X apps look for specific files in specific locations within the internal anatomy of the app's folder bundle.
To Greg's Home Page
To Greg's Software Page