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.
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…
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.
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
.jpg)
