MCL has good window/view, dialog and dialog item classes, the latter in particular having been extended to provide almost every form of control and widget known to man, and menus are also well catered for. However, an examination of the class heterarchy (see the diagram on the facing page) with MacApp eyes shows that there are many gaps, particularly in command handling, printing and documents. In truth some of the classes which look attractive are in fact very shallow-for instance, the Application class arrived during the late development stage of MCL 2.0, and really handles AppleEvents and nothing else.
Discussion in the info-mcl mail group and elsewhere has suggested that the lack of a thorough application framework may be one of the major factors limiting the number of products developed with MCL, and we are all agreed that we would rather see the MCL development team spending their time making version 2.1 even better, rather than trying to design and build Blueprint too. So, it was a natural community project for those in the new OODL SIG to work on.
A future with Dylan has some serious consequences on Blueprint's design. There is already a massive and highly sophisticated application framework for Common Lisp systems, the Common Lisp Interface Manager (CLIM). This is currently offered for other platforms at version 2.0, but is still in its previous version for MCL. None of us conspiring to Blueprint would wish to be seen to attempt to subvert or compete with CLIM, which is – and should remain – the standard cross-platform framework for Common Lisp. However, it is by no means small, and it does not quite enable the development of applications fully compliant with the Apple Human Interface Guidelines. Blueprint will be much smaller and must be oriented at providing those developing true stand-alone Macintosh applications in MCL or Dylan with full compliance with the guidelines.
Another significant application framework used in the Common Lisp world is Garnet, which has recently been made available in the public domain. However, even though Garnet is rather leaner than CLIM, it is still large and does not use the Common Lisp Object System (CLOS), the current (and now draft ANSI) OOP system for Common Lisp. This would clearly not be tenable when we are promoting MCL as an OODL!
Others within our informal group have been looking at architectural issues, and I am delighted that Jeff Alger has his Solution Based Modeling hat on, and is making sure that whatever we do will work well with the Goldstein and Alger approach to development, as well as having a sound basis. With a surprisingly large number of renegades from a MacApp past, I am confident that we will end up with a framework which is practical as well as theoretically proper-and lean, mean and purposeful.
Another area of general agreement is that Blueprint will be available in source code, and essentially free and without runtime licensing cost through OODL SIG. Our group has the benefit of many great minds, and our aspirations are high. If you feel that you can make a contribution-particularly if you can write good Common Lisp, as it is in 'implementors' that we are weakest-please mail me. n
NOTE: 'Blueprint' is but a working name, and no claim is made for it as a trade mark.
