Macアプリ

MacApp は、Apple Computerの廃止されたクラシック Mac OS用のオブジェクト指向 アプリケーション フレームワークです。1985 年にリリースされ、 1991 年のバージョン 3.0 リリースでObject PascalからC++に移行し、 System 7の新機能の多くをサポートしました。MacApp は、 Adobe Photoshop ^[1]やSoftPress Freewayなど、さまざまな主要アプリケーションで使用されました。^[要出典] MicrosoftのMFCとBorlandのOWL はどちらも MacApp の概念を直接ベースとしていました。

10 年にわたって、この製品はほとんど開発が行われなかった時期と、その後に活発に開発が行われた時期がありました。この期間を通じて、SymantecのThink Class Library /Think Pascal は、はるかに高性能な統合開発環境(IDE) でよりシンプルなモデルを提供し、MacApp の強力な競合相手となっていました。

Symantec は 1990 年代初頭のPowerPCプラットフォームへの移行への対応が遅く、Metrowerks が1994 年に初めてCodeWarrior / PowerPlantシステムを導入すると、Mac の主要開発プラットフォームとして MacApp と Think の両方が急速に置き換えられました。Apple でさえ、 1990 年代半ばの Copland時代には CodeWarrior を主要開発プラットフォームとして使用していました。

MacAppは、 MacOS XのCarbonシステムへの移行のためのシステムとして、2000年から2001年にかけて短期間休止状態となった。^{[2]しかし、2001年6月に}Worldwide Developers Conference (WWDC)でバージョンをデモした後、同年10月にすべての開発が中止された。

MacAppは、ラリー・テスラーが率いたAppleの最初のオブジェクト指向アプリケーションフレームワーク設計の取り組みであるLisa Toolkitの直系の後継である。Toolkitのエンジニアリングチームには、ラリー・ローゼンスタイン、スコット・ウォレス、ケン・ドイルが含まれていた。Toolkitは、 Pascal言語にオブジェクト指向技術を追加したClascalと呼ばれるカスタム言語で書かれていた。^{[3] [4]}

当初、Mac 向けの開発は Lisa Workshop のクロスコンパイラを使用して行われていました。Mac の販売により Lisa の販売が事実上終了したため、Mac 向けの新しい開発プラットフォームを構築する取り組みが始まりました。Lisa Programmer's Workshop は 1985 年にMacintosh Programmer's Workshop (MPW) になりました。このプロセスの一環として、Clascal はObject Pascalに更新され、Lisa Toolkit は MacApp となるものの設計ノートを提供しました。^[4]

アプリケーション フレームワークなしで Mac プログラムを書くのは簡単な作業ではありませんが、当時はオブジェクト指向プログラミングの分野はまだ比較的新しいものであり、多くの開発者からやや疑わしいと思われていました。初期のフレームワークは、大きく、遅く、通常は柔軟性に欠けており、この疑念を裏付ける傾向がありました。

MacApp は、あらゆる意味で本当に使える最初のフレームワークだったかもしれません。コンパイルされたアプリケーションは、サイズとメモリ フットプリントの点で非常に妥当であり、パフォーマンスも開発者が敬遠するほど悪くありませんでした。最初のリリースでは「単純すぎる」ものでしたが、その後の数バージョンで主な問題がすぐに解決されました。この時点で、1987 年頃には、システムは便利なツールに成長し、多くの開発者が主要なプロジェクトで使用し始めました。

MacApp 2.0 は 1989 年にリリースされました。改良点としては、UI 要素の操作の簡素化や、Multifinder のサポートなどがありました。^[5] Apple が 1992 年に MPW Pascal のサポートを中止すると発表したため、^[6]このバージョンは System 7 のサポートも含めて更新されず、Pascal 開発者は MacApp 2.0 を PowerPC に移植する作業に取り組まなければなりませんでした。^{[6] [7]}

1980年代後半のこの時点では、市場はC++へと移行しつつあり、Apple C++コンパイラのベータ版は1989年のMacApp 2.0リリース頃に登場した。^[5]同時に、Appleは多くの大きな新機能を備えたSystem 7のリリースに全力を注いでいた。そこで、Object Pascalの代わりにC++を使用する、MacAppのまったく新しいバージョン3.0に移行することが決定された。^{[8]この動きは、} Usenetやその他のフォーラムでObject PascalとC++の支持者の間で長く白熱した議論の対象となった。それでも、開発スイートであるMPWが時代遅れになりつつあったにもかかわらず、3.0は1991年のリリース後、かなりの支持を集めることができた。その後、Appleは開発ツールグループ全体を縮小し、MacAppとMPWの両方で人員不足に陥った。

この縮小の理由の 1 つは、Apple が開発のための「次の偉大なプラットフォーム」を導入しようと長年試みてきたことであり、ほとんどの場合、何らかのクロスプラットフォーム システムの形で行われてきました。最初の試みは、Symantec と提携して作成されたクラス ライブラリであるBedrockで、Mac と Windows で実行できましたが、最終的に両者がお互いに協力することをあきらめたため、長らく失敗に終わりました。問題の原因の 1 つは、OpenDocの作成であり、それ自体がクロスプラットフォーム システムに開発され、Bedrock と直接競合しました。Bedrock を OpenDoc プラットフォームとして位置付ける試みがいくつかありましたが、^{[9] [10]}何も実現しませんでした。

これらの開発が行われている間、MPW と MacApp はほとんど無視されていました。これらの新しいプロジェクトに開発者リソースを投入して、より早く市場に投入することの方が重要でした。しかし、Bedrock が失敗し、OpenDoc があまり受け入れられなかったため、Mac にはほぼ 10 年前のツールが残され、サードパーティの新しい製品と競争できなくなりました。1990 年代初頭には、競合するフレームワークが MacApp の真の競合相手に成長しました。最初は Symantec の TCL が支持を集めましたが、その後 Metrowerks のPowerPlant が市場全体をほぼ独占しました。

MacApp のコア開発者は、1990 年代を通じて、活動レベルは低かったものの、引き続きこのシステムの開発に取り組みました。Apple の「公式」クロスプラットフォーム プロジェクトがすべて崩壊したため、1996 年後半にチームは MacApp のクロスプラットフォーム バージョンを提供すると発表しました。

その後すぐに、Apple はNeXTを買収し、今後はOpenStepをCocoaという名前で Apple の主要開発プラットフォームにすると発表しました。Cocoa は当時すでにクロスプラットフォームであり、約 6 つのプラットフォームに移植されており、MacApp よりもはるかに進んでいました。これにより、既存の Mac プログラマーから、自分たちのプログラムが「ペナルティ ボックス」に送られ、事実上放棄されていると抗議する強い抗議が起こりました。

WWDC'98 で、スティーブ・ジョブズは、Cocoa への移行に関する否定的なフィードバックはCarbonシステムの導入によって解決されると発表しました。Carbon は、いくつかの変換を行った後、既存の Mac プログラムを新しいオペレーティング システムでネイティブに実行できるようにします。Metrowerks は、PowerPlant フレームワークを Carbon に移植すると発表しましたが、Apple は MacApp に関して同様の発表をしませんでした。

この期間を通じて、Apple の態度にますます不満を募らせていた MacApp の忠実なユーザー層は存在していました。1990 年代後半、Cocoa の導入時には、この不満は製品に対する完全な拒絶へと発展しました。状況は悪化し、MacApp ユーザーのグループは、Apple のスタッフに会議の部屋を拒否されるのを避けるために、偽名を使って WWDC '98 で独自の会議を開催するほどでした。

この継続的なサポートは Apple 社内で注目され、1999 年後半には、これまでずっと MacApp に取り組んできたメンバーで構成される「新しい」MacApp チームが新バージョンのリリースを任されました。これには、新しい Apple Class Suites (ACS)、OpenStep から導入された多くの新しい Mac OS 機能用の C++ ラッパーの薄いレイヤー、および Project Builder でのビルドのサポートが含まれていました。MacApp 3.0 Release XV ^[11]は、多くの人々を喜ばせながら 2001 年 8 月 28 日にリリースされました。しかし、10 月にこの製品は再び、今度は永久に廃止され、MacApp の既存のバージョンのサポートは正式に終了しました。

Carbon 準拠の PowerPlant X は 2004 年まで出荷されませんでしたが、今日では Cocoa は MacOS と iOS プログラミングの両方でほぼ普遍的になっています。

MacApp は、Apple が 2001 年にサポートを中止して以来、フレームワークの保守と強化に尽力してきた熱心な開発者グループによって存続しています。MacApp は、Carbon イベント、ユニバーサル バイナリ、Unicode テキスト、MLTE コントロール、DataBrowser コントロール、FSRef、XML 解析、カスタム コントロール、複合ウィンドウ、ドロワー ウィンドウ、HIView ウィンドウ、カスタム ウィンドウを完全にサポートするように更新されています。MacApp には、HIObject と HIView 用の C++ ラッパー クラスもあります。また、主に MacApp-2 に基づく Pascal バージョンが Mac OS X と Xcode に移植されています。長い Unicode ファイル名と、自動バイト スワップによるストリーム ドキュメントが特徴です。

MacApp はXcode IDE をサポートしています。実際、 WWDC 2005でApple が Intel CPU への移行を発表した後、1 人の開発者が MacApp と MacApp サンプル アプリを更新してユニバーサル バイナリをサポートするのに 48 時間かかりました。

この説明は、以前の 2.0 よりも高度な基盤モデルを持ち、多くの重要な点で異なっていた MacApp 3.0 に基づいています。

Mac OS 自体のイベント処理システムは非常にシンプルです。オペレーティング システムからアプリケーションに渡されるイベント構造には、「キー押下」や「マウスクリック」などのイベント タイプと、その場所の詳細、押されている修飾キーのみが含まれます。このシンプルな情報を、たとえばメニュー コマンドのクリックなど、ユーザーが実行したアクションにデコードするのはアプリケーションの役割です。これをデコードするのは難しく、画面上のオブジェクトのリストを調べ、その境界内でイベントが発生したかどうかを確認する必要があります。

MacApp は、コマンド パターンを使用してこの問題の解決策を提供しました。コマンド パターンでは、ユーザー アクションがイベントの詳細を含むオブジェクトにカプセル化され、適切なオブジェクトに送信されて実行されます。イベントを「適切なオブジェクト」にマッピングするロジックは、フレームワークとそのランタイム内で完全に処理され、このタスクの複雑さが大幅に軽減されました。基本的な OS イベントを取得し、それを意味的に高レベルのコマンドに変換し、コマンドを適切なオブジェクトにルーティングするのは、MacApp の内部機構の役割です。

MacApp は、すべてのプログラムに必要なこのコードの作成者を解放しただけでなく、副作用として、この設計により、コードがコマンド、ユーザー向けのアクション、およびそのハンドラー、つまり作業を実行する内部コードに明確に分離されました。たとえば、「緑に変える」コマンドと「赤に変える」コマンドがあるとします。これらのコマンドは、どちらも 1 つの関数 によって処理されます。ChangeColor()コマンドとハンドラーが明確に分離されたプログラムは、Apple の用語では、ファクタリングされた と呼ばれていました。

プログラムのファクタリングは、 System 7以降のMac OSの後のバージョンで特に重要でした。System 7ではApple Eventsシステムが導入され、オリジナルのMac OSのイベントシステムが、OSから特定のアプリケーションだけでなく、アプリケーション間で送信できる、より豊富なものに拡張されました。これは、これらのイベントをスクリプトコードから生成できるようにするAppleScriptシステムと組み合わされました。MacApp 3.0では、Apple Eventsは、直接のユーザーアクションによって開始された場合と同じコマンドにデコードされたため、開発者はApple Eventsを直接処理するためにコードをほとんど（あるいはまったく）書く必要がありませんでした。これは、そのような分離がなく、Apple Eventのサポートが省略されることが多かったMacApp 2.0などの以前のシステムを使用している開発者にとっては大きな問題でした。

アプリケーション フレームワークとしての役割にふさわしく、MacApp には、Mac の基本的なGUIのほとんどをカバーする多数の事前ロール オブジェクトも含まれていました。ウィンドウ、メニュー、ダイアログ、および同様のウィジェットはすべてシステム内で表現されていました。残念ながら、Apple は、通常、「現実世界」で使用できるシステムを提供するのではなく、既存の Mac OS 内部コードに軽量のラッパーを提供していました。たとえば、クラスTTEViewは標準のテキスト エディター ウィジェットとして提供されていましたが、基礎となる TextEdit の実装は大幅に制限されており、Apple 自身も、プロフェッショナル アプリケーションには使用すべきではないと頻繁に述べていました。その結果、開発者は、こうしたニーズに対応するためにアドオン オブジェクトを購入するか、独自のオブジェクトを作成する必要に迫られることが多かったのです。プロフェッショナル品質の GUI オブジェクト セットが不足していることは、MacApp の最大の問題の 1 つであると考えられます。

これらの問題は、MacApp R16 のリリースで解決されました。MacApp R16 では、すべての MacApp GUI オブジェクトに標準のCarbonコントロールが使用されています。たとえば、Carbon では、完全なUnicodeテキストと長いドキュメントのサポートのために、Multilingual Text Engine (MLTE) が導入されました。R16 では、元のクラスは、MLTE コントロールを使用する TTEViewに置き換えられました。TMLTEView

Adobe PhotoshopはもともとMacApp 1.1.1のObject Pascalで書かれ、後にPhotoshop 2.5でC++とMacApp 3.0に移植されました。AppleによるMacAppのキャンセル後、メンテナンスはPhotoshop開発チームによって内部的に引き継がれ、PowerPCに移植され、Windowsプラットフォームポートと共有されるように変換されました。^[1]

• MacApp プログラマーガイド - Inside Macintoshシリーズの完全なドキュメント