WAMADA News

John MacVeigh

August – MacApp, TCL, & FUD

The August WAMADA meeting began with a little group troubleshooting for some local developers. They brought up some shortcomings in MacApp which they wanted to work around. The first involved printing to a LaserWriter vs. displaying with QuickDraw. Their application creates and prints forms for a government agency (big, long forms). Naturally they wish to make use of the printing quality available on a PostScript printer. For example, the printed forms should use lines thinner than a standard one pixel QuickDraw line. But how to do this with MacApp's printing mechanism? The first suggestion was to pre-build the forms in PostScript and "fill-in-the-blanks". However, this application constructs the forms as it is run, thus there is no standard form to pre-build. Apart from writing everything in PostScript, the only other suggestion was to first produce a PICT so that the PostScript could be embedded in PICT comments. The idea was to alter the printing loop to open a picture, call the Draw methods which could add PICT comments where needed, then close the PICT and print that. This seemed doable, if not pretty. Since desktop publishing was the Mac's salvation in the early years, and is still a strength today, one might expect better printing support from MacApp. But what we have been given is only QuickDraw, i.e. the lowest common denominator (where have I heard that phrase before?). To say that GX will solve this problem is correct, but smacks of raising the river rather than lowering the bridge.

The second problem involved MacApp's sometimes haphazard use of color, especially in dialogs. For example, the floating TE view must be overridden to make use of the target view's foreground and background colors. Other color problems are caused by MacApp's use of standard Mac controls. Perhaps Bedrock will help solve this problem by abstracting controls into platform independent objects.

TCL

The evening continued with a presentation by Mark Gerl of McDonnell Douglas comparing TCL with MacApp. Mark's group recently switched from MacApp 3.0 to TCL. They did so partly based on the loss of support for MacApp, and partly on the belief that Bedrock will be more like TCL. In the end, they may have tried to hit a moving target; but given his group's existing knowledge of MacApp and their emphasis on R&D prototypes rather than finished product, I don't think they have lost anything. Indeed, TCL may be a better starting point for prototypes and experiments. Some of the benefits of TCL include:

• Shorter learning curve
• "Lighter" classes
• Fast environment with integrated debugger
• AppMaker™ support for quick start up of new projects
• Works with Object Master and Projector(Mark edits with Object Master, uses MPW to run Projector (SourceServer's still in the wings), and does the compile/link/debug work with Think C. This gives him the best of each application. It also gives him a reason for using a 32MB Radius Rocket™ to run Think C.)

It's not unexpected for a smaller framework to be faster to learn and work with than a larger one. But does it warrant giving up the richer and more complete (System 7 support, for example) framework embodied by MacApp? At first look, it would seem that MacApp requires a longer design phase, but less programming work, while TCL allows quicker start up, but more work to add the features needed by a commercial application. Which is "faster"? There is no single answer to this; the real lesson here might be that there is room for more than one application framework, and waiting for the "perfect" framework is surely the slowest way to develop software. And speaking of waiting for answers…

FUD

The meeting concluded with a report by Leslie Jeffries on Steve Weyl's talk at August MacWorld. Simply put, there was no discernable change in content from the Apple announcements made at the WWDC and at PC Expo.This led to a rather lengthy discussion among the group about the directions, both real and perceived, in which Apple is taking their development tools. Mostly, of course, we discussed perceptions and we did not perceive Apple to be doing a good job of explaining where it was going or how it would get us there. In particular, participants wondered about the fate of current MacApp users. Yes, Apple will provide a means to move to Bedrock. But what if our schedule doesn't match Apple's? How long after the appearance of Bedrock will MacApp support continue? Will bug fixes continue past the now-released 3.0.1? There are also still questions about Apple's support for developers using object technologies. For example: will future APIs be provided as classes? And at the same time as procedural APIs?

If these questions sound familiar, it's because they are. I think part of the reason for this discussion was that Apple didn't do much to answer these questions when they were first brought up. In fact the Bedrock announcement may become a perfect example of how not to announce new development tools. Early announcement (i.e., before you can say that most of the work is already done) creates more FUD (fear, uncertainty and doubt) than it creates useful planning information. It appears that, despite all of its bravado about Windows not being a threat, Apple became panicked that its developers might leave in droves for Windows, and began trumpeting the cross-platform framework before it should have. The result: a sense that the Apple tools group is in disarray.

The arrival of the Shared Library Manager (SLM) gives some hope, though, that work is proceeding apace towards an improved, and object-based, development environment. For example, the SLM provides Apple with an incentive to release future system extensions as classes, so that they may be shared.

The SLM also provides an example of how to release new tools: first do it, then announce it. Previous to the release of E.T.O. #8 we only heard that Apple was working on "DLLs". Then, unexpected by most developers, it appears in Beta form. Some may say that they want to know about such developments as early as possible. But suppose Apple had been working on four or five different DLL solutions before selecting one? Would this have provided useful information? Or a reason to delay work while the final choice was made? It would seem that, in this case at least, ignorance is bliss. Also, the journey is the reward, don't stare directly at Suns or stick your hands out Windows, and objects are closer than they appear.

September – Delays & SLM

The September WAMADA meeting got off to a late start. A week late to be exact, due to the pressing demands of the organizers's jobs. Of course this can be seen as a good thing: people are busy developing new and improved software. The bad news, though, is that often the work being done is to recode old work, change languages, change development systems, and reconsider where to allocate future development resources; new work is being delayed. One developer is recoding a large (215K lines) Pascal program into C++. To keep the switch-over orderly, no features will be added or changed. Another developer is adopting Component Workshop and will be taking time out to attend training. A third must re-consider a design which used Dinker, now that the Shared Library Manager (SLM) has taken its place. To continue the good news bad news theme, the good news is that new Apple software, like the SLM, is beginning to appear.

The SLM was the focus of this month's meeting, as developers tossed around ideas on how best to use it. Our first impression was that this is a very good technology for Apple. It provides them with an organized and powerful method for distributing system enhancements. Everyone also agreed that a shared MacApp (or, more likely, Bedrock) library would be an excellent use of the SLM. We could not, however, immediately describe to one another how to set up a Dinker-like system where a DLL would contain objects derived from an application base class. What, for example, is the best way to find out which derived classes exist? Generally, it was felt that as the SLM matures Apple needs to provide more examples of its use in application programs, as well as for system extensions.

The SLM also brings changes to other aspects of the software business. One developer observed that breaking applications into shared libraries, not all of which might come from the same source, pushes compatibility problems into the user's arena. Currently, if you link with a third-party library, and something makes that library out-of-date, then you, the developer, have to solve the problem. But if that library was purchased separately, or came with another package, who is responsible for updating it? While the SLM provides version management, it can't automatically order upgrades (now there's an interesting third party opportunity). It also appears that the Finder will need to be improved in order to provide a useful interface for all the DLL files that will begin proliferating on the user's hard disk. Constantly selecting files and doing "Get Info" to check version numbers can become tiring, real fast. Lastly, the SLM accelerates the question of how to price, sell, and prevent the piracy of add-on code modules. Apple's up-coming policy of charging for system upgrades may, in fact, be part of an attempt to get people used to paying for code, even if it's not a complete application.

It will be interesting to see, as developers begin to depend on the SLM, how these problems are solved. In the short term, I think, we will see developers use the SLM for access to Apple extensions, but rarely for access to DLLs from other companies.

WAMADA meets every third Wednesday at McDonnell Douglas in Tyson's Corner, Virginia, beginning around 7:15 p.m. For a map, send a message to JEFFRIES.L on AppleLink, or call Leslie at (301) 340-5126 during business hours (EDT). n