文档章节

MacApp

帝都老白
 帝都老白
发布于 2015/03/03 11:07
字数 1595
阅读 6
收藏 0

MacApp was Apple Computer's primary object oriented application framework for the Mac OS for much of the 1990s. First released in 1985, it is arguably the first such system to be widely used, notably on a microcomputer platform. Microsoft's MFC and Borland's OWL were both based directly on MacApp concepts.

It seems that Apple paid less attention to it than others, however, as it was alternately developed intensely and then ignored for long periods through the 1990s. Many Mac developers eventually gave up on it and moved to newer tools such as MetrowerksPowerPlant and Symantec's Think Class Library (TCL). MacApp had a brief reprieve between 2000 and 2001, but after demoing a new version at WWDC in June 2001, all development was cancelled that October.

Even with this checkered career, MacApp was used for a variety of major applications, including Adobe Photoshop and Freeway.

[edit]History

MacApp was a direct descendent of the Lisa Toolkit, Apple’s first effort in designing an object-oriented application framework. The MacApp and Lisa Toolkit projects were headed by Larry Tesler. The engineering team for the Toolkit and the initial implementation of MacApp included Larry Rosenstein, Scott Wallace, and Ken Doyle. MacApp was based on Object Pascal, Apple’s object-oriented extension to Pascal, developed in consultation with Pascal inventor Niklaus Wirth. At the time, Pascal was Apple's language of choice for Mac programming.

Writing a Mac program without an application framework is not an easy task, but at the time the object-oriented programming field was still very new and considered somewhat suspect by many developers. Early frameworks tended to confirm this suspicion, being large, slow, and typically inflexible.

MacApp was perhaps the first truly usable framework in all meanings of the term. Compiled applications were quite reasonable in terms of size and memory footprint, and the performance was not bad enough to make developers shy from it. Although "too simple" in its first releases, a number of follow-up versions quickly addressed the main problems. By this point, around 1987, the system had matured into a useful tool, and a number of developers starting using it on major projects. Given the small memory sizes and slow speeds of machines of the era, however, even the small overhead of MacApp was considered a bother, and developer uptake was not particularly widespread.

At this point the market was moving towards C++, and Apple was forced to move as well. The resulting MacApp 3.0 was subject to a long and heated debate between proponents of Object Pascal and C++ in the Usenet and other forums. Nevertheless 3.0 managed to garner a reasonable following after its release in 1991, even though the developer suite,Macintosh Programmer's Workshop (MPW), was growing hopelessly outdated. Poised for what appeared to be a success story, Apple then downsized the entire developer tools group, leaving both MacApp and MPW high and dry.

One of the reasons for this downsizing was Apple's long saga of attempting to introduce the "next great platform" for development, almost always in the form of a cross-platform system of some sort. Their first attempt was Bedrock, a class library created in partnership with Symantec that ran on the Mac and Windows, which died a lingering death as both parties eventually gave up on working with the other. One of the reasons for their problems was the creation of OpenDoc, which was itself developed into a cross-platform system that competed directly with Bedrock. There were some attempts to position Bedrock as an OpenDoc platform, but everyone involved knew this was nothing more than smoke and mirrors.

So with the next big thing just around the corner, MPW and MacApp simply were not important. It was much more important to put those developer resources into these new projects to help them reach the market sooner. But when none of them really did reach the market (OpenDoc's "success" was arguable at best) the Mac was left with tools that were now almost a decade old and simply could not compete with the newer products from third parties. Through the early 1990s competing frameworks grew into real competitors to MacApp. First Symantec's TCL garnered a small following, but then Metrowerks' PowerPlant generally took over the entire market.

Nevertheless, the core developers of MacApp refused to let it die, and continued to work on the system throughout the 1990s. When all of Apple's "official" cross-platform projects were finally in their death throes, the team decided to take it upon themselves to fix the problem, and announced in late 1996 that they would be providing a cross-platform version of MacApp instead. By this point in time Apple was in serious trouble in the marketplace, and most developers had long given up believing any of their claims after watching one such product after another disappear.

Throughout the continuing saga there remained a core of loyal MacApp users who grew increasingly frustrated at Apple's behavior, which by the late 1990s had grown to outright dismissal of their own product during the introduction of Cocoa. Things were so bad that a group of MacApp users went so far as to organize their own meeting at WWDC '98 under an assumed name, in order to avoid having Apple staffers refuse them a room to meet in.

These antics did not go entirely unnoticed within Apple, and in late 1999 a "new" team, consisting of members who had worked on it all along, was put together to bring out a new version. Included was the new Apple Class Suites (ACS), a thinner layer of C++ wrappers for many of the new Mac OS features being introduced from OpenStep. MacApp 3.0 Release XV was released on August 28, 2001 to the delight of many, all of whom were around to see history repeat itself in October when the product was killed once again, this time likely forever.

MacApp is still being kept alive by a dedicated group of developers who have maintained and enhanced the framework since Apple stopped supporting it in 2001. MacApp has been updated to fully support Carbon Events, Universal Binaries, Unicode Text, MLTE control, DataBrowser control, FSRefs, XML parsing, Custom Controls, Composite Window, Drawer Window, HIView Window and Custom Windows. MacApp also has C++ wrapper classes for HIObject and HIView. Also the Pascal version, based mainly on MacApp-2, has been ported to Mac OS X and Xcode. It features long Unicode filenames and streamed documents with automatic byte-swapping.

MacApp supports the Xcode IDE. In fact at WWDC 2005, after Apple announced the transition to Intel CPUs, it took a single developer 48 hours to update MacApp and the MacApp example apps to support Universal Binaries.

[edit]Description

This description is based on MacApp 3.0, which had a more advanced underlying model than the earlier 2.0 and differed in many significant ways.

An application built in MacApp followed the command pattern, in which user actions are encapsulated in objects containing event details, and then sent to the proper object to carry them out. In the Mac OS this simple chain of events is actually not all that easy to code "by hand", as the OS only supports extremely basic events like "mouse click" or "keypress". It is the role of MacApp's internal machinery to take these basic events, translate them into semantically higher-level commands, and then route the command to the proper object.

Not only did MacApp relieve the author of having to write this code, which every program requires, but also as a side-effect cleanly separated code into commands and their handlers. In doing so, the resulting program was considered to be, in Apple parlance, factored. This was important under System 7 and later versions of the Mac OS, where commands were expected to flow in not only from the user's actions, but from AppleScript and its underlying Apple Events system as well. Under MacApp, Apple Events were decoded into the same commands as if they had been initiated by direct user actions, meaning that the developer didn't have to write much, if any, code to directly handle Apple Events. This was a major problem for developers using earlier systems, including MacApp 2.0, which had no such separation and often led to Apple Event support being too difficult to bother with.

In keeping with its role as an application framework, MacApp also included a number of pre-rolled objects covering most of the basic Mac GUI—windows, menus, dialogs and similar widgets were all represented within the system. Unfortunately, Apple typically supplied lightweight wrappers over existing internal Mac OS code instead of providing systems that were usable in the "real world". For instance, the TTEView class was offered as the standard text editor, but the underlying TextEdit implementation was severely limited and Apple itself often stated it should not be used at all after the MLTE control was introduced. As a result, developers were often forced to buy add-on objects to address these sorts of needs, or roll their own. The lack of a set of professional quality GUI objects can be considered one of MacApp's biggest problems.

These problem has been addressed with the release of MacApp R16. MacApp R16 uses standard Carbon controls for all MacApp GUI objects. The EditText Carbon control uses the MLTE control for full Unicode Text support. The TTEView class has been superseded by the TMLTEView class which uses the MLTE control for full Unicode Text support.

[edit]External links







© 著作权归作者所有

帝都老白
粉丝 15
博文 54
码字总数 150719
作品 0
朝阳
CTO(技术副总裁)
私信 提问
(有偿)如何用此GitHub项目将WebApp包装成MacApp(Cocoa Application)

技术爱好者,但在 Xcode 方面还是刚接触不久。诚心求助,有偿。 拥有一个 Web App 和 URL,要将其包装成 Mac App。就像 Teambition 那样,打开后窗口内实际加载的是一个网页,可以继续登陆操...

kerry689
2016/02/09
867
3
Photoshop v.1.0.1 源代码以及它的故事

当Thomas Knoll和John Knoll兄弟在20世纪80年代末开始设计和编写一个图像编辑程序时,他们无法想象他们会在字典中添加一个词。 密歇根大学(University of Michigan)计算机视觉专业的博士生T...

程序师
2018/07/10
0
0
模板方法--行为型模式之四

1. 意图 定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。 Te m p l a t e M e t h o d使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。 2. 动机 考虑一个提供 A ...

长平狐
2013/04/25
103
0
iOSer 必知必会的深度链接技术——WWDC2019更新

iOSer作为移动开发者中的一员,不得不说深度链接在当下这个“流量”时代已经成为我们的必修课了,那么什么是深度链接呢?简单的说就是,可以通过一个简单的“链接”,打开App并直接进入该App...

MobService
07/09
82
0
模版方法--行为型模式之二:类的关系

大家不要把它和C++的template class/method搞混了。后者是一种语法。 1. 意图 定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。 Te m p l a t e M e t h o d使得子类可以不改变一个算...

长平狐
2013/04/25
54
0

没有更多内容

加载失败,请刷新页面

加载更多

CRM、DMP、CDP都是什么?有什么区别?

Markter对CRM系统(Customer Relationship Management System,客户关系管理系统),营销自动化等概念都已经比较熟悉,也许DMP(Data Management Platform,数据管理平台)也多多少少有些了解。...

怡海软件-CRM
9分钟前
3
0
中台是什么,到底要解决什么问题?

故事的开始 这个最早由阿里在2015年提出的“大中台,小前台”战略中延伸出来的概念,最近在国内大热。阿里、腾讯、百度、京东、美团、滴滴等一众互联网巨头,从去年到今年,接连开始组织架构...

喵二狸
20分钟前
2
0
Linux Centos 7 - MySQL 5.7离线安装

内部网络通过离线包的方式进行安装。 一、下载 下载地址:https://dev.mysql.com/downloads/mysql/ 进入页面后,点击右侧链接。 下载对应版本。 通过xftp6等工具上传到服务器上。 二、安装和...

华山猛男
20分钟前
2
0
EventBus 3 全解

EventBus 3 全解 [TOC] 使用 一个基于观察者模式的事件发布/订阅框架. 用于模块间通信和解耦, 使用方便,性能高. 基本使用 1. gradle导入依赖库 implementation 'org.greenrobot:eventbus:3....

马湖村第九后羿
23分钟前
3
0
HTTP 协议

什么是HTTP协议? HTTP是hypertext transport protocol的缩写,即超文本传输协议。 是用于万维网服务器与本地浏览器之间传输超文本的传送协议。可以使浏览器更加高效,使网络传输减少。能够保...

彩色泡泡糖
33分钟前
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部