Barry,
Once you've opened the package, you should be able to just open the project at :osx:pmfb:pmfb3:mac:pmfb3:pmfb3.mcp and build and run it. Let me know if you have any problem with that. I'm sure we'll have to talk as you go, but just a quick list of organizational notes:
- I tried to split the code into two parts, engine (or library) and front end (or gui). pmfbLib is the library, :pmfb3:mac is the Mac front end. I didn't send them to you, but there are dos, windows and palm front ends too.
- I tried to make the pmfbLib compile as-is on all platforms - a common engine. I wound up having to create small OS layer (or mapping) files under pmfbLib for each platform. I've included :pmfbLib:mac, but there are dos, windows and palm OS versions too.
- The pmfbLib files should not change if possible, but let me know if you have to. You can do what you want with the front end files, but you probably would not have to change that much just to get it running under Carbon.
That should get you going. Let me know if you have any problems.
-Brian
With regards to the need for PowerPlant in the OS X version:
The latest Carbon suport has HIView support in InterfaceBuilder for all
the view types. The class support already built-in is extensive. This
pretty much gives you what you probably use in PowerPlant.
However if you use a lot of PowerPlant, a good first pass might be to
compile PowerPlant into a Carbon-ized application. First I Carbon-ize
the application in CodeWarrior and then get it to run as a mach-o
executable. After that it is pretty easy to get it into XCode. There
are some changes that have to be made to PowerPlant. Then I can begin
stripping out PowerPlant in favor of HIView if you want. The end result
will still work under OS 8.x, but would be limited to systems that
support the Carbon library. Knowing how schools are, you might want to
keep PowerPlant and a non-carbonized version for older Macs.
Cocoa and Objective-C is really sweet and I'd rather work in Obj-C any
day. You can use C++ and Obj-C together but you have to keep the
libraries separate. But I wouldn't recommend it unless forced or if
some earth-shattering feature was enabled by doing it.
What version of CodeWarrior are you using?
It seems the latest one I have already has a lot of OS X support.
I am looking at how the platform specific stuff is used now. Perhaps it may be easier to just treat OS X Carbon as a new platform.
I've got an old version of the CodeWarrior tools (Pro 5) and the PowerPlant that came with it. I had heard that the later versions allowed you to easily build to the Carbon API and thus have either a native OS X app or one that is compatible with OS 9. Migrating the current project to the new IDE would probably be the quickest way to get there, and we wouldn't have to define a new platform - just treat it as an upgrade of the current one since it would continue to provide the OS 9 support for those who needed it.
Migration to Xcode is still attractive though I think. If for no other reason, it allows more potential developers to get involved because the IDE is freely distributed. From there, I'm not as sure, my guess is that Cocoa might be biting off too much. I don't believe PowerPlant would still be an option (or could it be used under Xcode?). So unless there's another alternative, HIView might have to be it. It looks to mostly provide a view model. Is there any notion of a document? If not, the requirements are not so tough that the class couldn't be added.
I should mention one other thing I thought about today regarding Dialogs. I spend some time creating a small set of MFC Dialog emulation classes to theoretically ease Mac development. Since I had already written all the MFC dialogs, the theory was that if I write the emulation classes once, I get all the dialogs for free. Well, not quite. It wound up taking longer than I thought to get them right, and you still have to dress up the Windows code some, but it did allow me to very quickly implement all the dialogs quickly. The net result is a current dependency on that little system that may have to be addressed - especially if we wander to far from the Pro 5 version of PowerPlant or away from CodeWarrior entirely.
For me the issue is that just to see it compile I will have to reinstall Pro 5 CodeWarrior. Just as a test I simply converted the project to CW 8 and tried to compile it. Most code compiled "as is" except for PowerPlant and the Dialog stuff you've mentioned. In fact PowerPlant has already been Carbonized in CodeWarrior 8 so most of the changes are what we want but the test compile produced thousands of errors. Most are cascading off of the appearance manager dialog classes which have been changed. A few have to do with changes to the Metrowerks Libraries and they are the most insidious. For example "min" is gone.
I've been travelling over the Christmas break. Any progress?
Good news! I've built a working copy of n OS X native version of PMFB. The things I've tested work pretty well, but I'm sure there are a couple of undiscovered issues to resolve. I hope I can either apply the existing registration scheme soon, or finish the development of the next generation soon to release all of this ASAP.