ماك آب

تحتوي هذه المقالة على العديد من المشكلات. يُرجى المساعدة في تحسينها أو مناقشة هذه المشكلات على صفحة المناقشة . ( تعرف على كيفية ومتى يمكنك إزالة هذه الرسائل ) تمت كتابة هذه المقالة على شكل تأمل شخصي، أو مقال شخصي، أو مقال جدلي يوضح المشاعر الشخصية لمحرر ويكيبيديا أو يقدم حجة أصلية حول موضوع ما.يرجى المساعدة في تحسينه عن طريق إعادة كتابته بأسلوب موسوعي . ( مارس 2008 )( تعرف على كيفية ومتى يمكنك إزالة هذه الرسالة ) تحتاج هذه المقالة إلى مصادر إضافية للتحقق .الرجاء المساعدة في تحسين هذه المقالة عن طريق إضافة الاستشهادات إلى مصادر موثوقة . قد يتم الطعن في المواد غير الموثقة وإزالتها. ابحث عن المصادر:  "MacApp" – الأخبار  · الصحف  · الكتب  · العلماء  · JSTOR ( أكتوبر 2021 )( تعرف على كيفية ومتى يمكنك إزالة هذه الرسالة ) ( تعرف على كيفية ومتى يمكنك إزالة هذه الرسالة )

MacApp هو إطار عمل تطبيقي موجه للكائنات لنظام التشغيل Mac OS الكلاسيكي المتوقف عن الإنتاج من شركة Apple Computer . تم إصداره في عام 1985، وانتقل من Object Pascal إلى C++ في إصدار 3.0 لعام 1991، والذي قدم الدعم لمعظم وظائف System 7 الجديدة. تم استخدام MacApp لمجموعة متنوعة من التطبيقات الرئيسية، بما في ذلك Adobe Photoshop ^[1] و SoftPress Freeway . ^{[ بحاجة لمصدر ] كان كل من} MFC من Microsoft و OWL من Borland يعتمدان بشكل مباشر على مفاهيم MacApp.

على مدى عشر سنوات، شهد المنتج فترات لم يشهد فيها سوى القليل من التطوير، ثم تلتها فترات من النشاط. وخلال هذه الفترة، أصبحت مكتبة Think Class Library /Think Pascal من Symantec منافسًا قويًا لـ MacApp، حيث قدمت نموذجًا أبسط في بيئة تطوير متكاملة (IDE) ذات أداء أعلى كثيرًا .

كانت شركة سيمانتك بطيئة في الاستجابة للانتقال إلى منصة PowerPC في أوائل التسعينيات، وعندما قدمت شركة Metrowerks نظام CodeWarrior / PowerPlant لأول مرة في عام 1994، فقد حل بسرعة محل MacApp وThink باعتبارهما منصتي التطوير الأساسيتين على أجهزة Mac. حتى أن شركة Apple استخدمت CodeWarrior كمنصة تطوير أساسية لها خلال عصر كوبلاند في منتصف التسعينيات.

حصل MacApp على فترة راحة قصيرة بين عامي 2000 و2001، كنظام للانتقال إلى نظام Carbon في MacOS X. ^[2] ومع ذلك، بعد عرض إصدار في مؤتمر المطورين العالميين (WWDC) في يونيو 2001 ، تم إلغاء جميع التطوير في أكتوبر من ذلك العام.

كان MacApp سليلًا مباشرًا لـ Lisa Toolkit، أول جهد لشركة Apple في تصميم إطار عمل لتطبيقات موجهة للكائنات، بقيادة لاري تيسلر . تضمن فريق الهندسة لمجموعة الأدوات لاري روزنشتاين وسكوت والاس وكين دويل. تمت كتابة Toolkit بلغة مخصصة تُعرف باسم Clascal ، والتي أضافت تقنيات موجهة للكائنات إلى لغة Pascal . ^{[3] [4]}

في البداية، تم تنفيذ التطوير لنظام التشغيل Mac باستخدام مُجمِّع متعدد اللغات في Lisa Workshop. وبما أن مبيعات Mac أنهت مبيعات Lisa فعليًا، فقد بدأت الجهود لبناء منصة تطوير جديدة لنظام التشغيل Mac. أصبحت Lisa Programmer's Workshop في عام 1985 ورشة عمل مبرمجي Macintosh ، أو MPW. وكجزء من هذه العملية، تم تحديث Clascal ليصبح Object Pascal وقدمت Lisa Toolkit ملاحظات تصميم لما أصبح MacApp. ^[4]

إن كتابة برنامج Mac بدون إطار عمل للتطبيقات ليس بالمهمة السهلة، ولكن في ذلك الوقت كان مجال البرمجة الموجهة للكائنات لا يزال جديدًا نسبيًا ويعتبره العديد من المطورين مشكوكًا فيه إلى حد ما. كانت الأطر المبكرة تميل إلى تأكيد هذا الشك، حيث كانت كبيرة وبطيئة وغير مرنة عادةً.

ربما كان MacApp هو أول إطار عمل صالح للاستخدام حقًا بكل معاني المصطلح. كانت التطبيقات المجمعة معقولة جدًا من حيث الحجم ومساحة الذاكرة ، ولم يكن الأداء سيئًا بما يكفي لجعل المطورين يخجلون منه. على الرغم من "بساطته الشديدة" في إصداراته الأولى، فقد عالج عدد من الإصدارات التالية المشكلات الرئيسية بسرعة. بحلول هذه النقطة، حوالي عام 1987، نضج النظام ليصبح أداة مفيدة، وبدأ عدد من المطورين في استخدامه في مشاريع كبرى.

تم إصدار MacApp 2.0 في عام 1989. ومن بين التحسينات تبسيط بعض تفاعلات عناصر واجهة المستخدم ودعم Multifinder. ^[5] عندما أعلنت شركة Apple أنها ستتخلى عن دعم MPW Pascal في عام 1992، ^[6] لم يتم تحديث هذا الإصدار، حتى مع دعم نظام التشغيل 7، وتم ترك مطوري Pascal بمفردهم لنقل MacApp 2.0 إلى PowerPC. ^{[6] [7]}

بحلول هذه المرحلة، في أواخر الثمانينيات، كان السوق يتجه نحو C++ ، وظهرت النسخة التجريبية من مُجمِّع Apple C++ في عام 1989، حوالي إصدار MacApp 2.0. ^[5] وفي الوقت نفسه، كانت Apple تبذل جهودًا كبيرة لإصدار System 7 ، الذي كان يحتوي على عدد من الميزات الجديدة الرئيسية. تم اتخاذ القرار بالانتقال إلى إصدار جديد تمامًا من MacApp، 3.0، والذي سيستخدم C++ بدلاً من Object Pascal. ^[8] كانت هذه الخطوة موضوع نقاش طويل وساخن بين مؤيدي Object Pascal وC++ في Usenet والمنتديات الأخرى. ومع ذلك، تمكن الإصدار 3.0 من اكتساب متابعة معقولة بعد إصداره في عام 1991، على الرغم من أن مجموعة المطورين، MPW، كانت قديمة الطراز. قامت Apple بعد ذلك بتقليص حجم مجموعة أدوات المطور بالكامل، مما أدى إلى نقص الموظفين في كل من MacApp وMPW.

كان أحد أسباب هذا التقليص هو ملحمة أبل الطويلة في محاولة تقديم "المنصة العظيمة التالية" للتطوير، دائمًا تقريبًا في شكل نظام متعدد المنصات من نوع ما. كانت محاولتهم الأولى هي Bedrock ، وهي مكتبة فئة تم إنشاؤها بالشراكة مع Symantec والتي تعمل على نظامي التشغيل Mac وWindows، والتي ماتت موتًا طويل الأمد حيث تخلى كلا الطرفين في النهاية عن العمل مع الآخر. كان أحد أسباب مشاكلهم هو إنشاء OpenDoc ، والذي تم تطويره في حد ذاته إلى نظام متعدد المنصات يتنافس بشكل مباشر مع Bedrock. كانت هناك بعض المحاولات لوضع Bedrock كمنصة OpenDoc، ^{[9] [10]} ولكن لم يحدث شيء من هذا على الإطلاق.

وبينما كانت هذه التطورات تجري، تم تجاهل MPW وMacApp إلى حد كبير. وكان من الأهمية بمكان استثمار موارد المطورين في هذه المشاريع الجديدة لمساعدتها على الوصول إلى السوق في وقت أقرب. ولكن عندما فشل Bedrock ولقي OpenDoc استقبالاً فاتراً، تُركت أجهزة Mac مع أدوات أصبحت الآن قديمة تقريبًا ولم تتمكن من المنافسة مع المنتجات الأحدث من جهات خارجية. وخلال أوائل التسعينيات، نمت الأطر المتنافسة لتصبح منافسين حقيقيين لـ MacApp. أولاً، اكتسبت TCL من Symantec متابعين، ولكن بعد ذلك استولى PowerPlant من Metrowerks على السوق بالكامل بشكل عام.

استمر مطورو MacApp الأساسيون في العمل على النظام بمستوى نشاط منخفض طوال تسعينيات القرن العشرين. وعندما انهارت جميع مشاريع Apple "الرسمية" متعددة الأنظمة الأساسية، أعلن الفريق في أواخر عام 1996 أنهم سيقدمون إصدارًا متعدد الأنظمة الأساسية من MacApp.

بعد فترة وجيزة، اشترت شركة أبل شركة NeXT وأعلنت أن OpenStep ستكون منصة التطوير الأساسية لشركة أبل في المستقبل، تحت اسم Cocoa . كان Cocoa بالفعل متعدد المنصات، في ذلك الوقت تم نقله بالفعل إلى حوالي ستة منصات، وكان أكثر تقدمًا من MacApp. أدى هذا إلى احتجاجات قوية من مبرمجي Mac الحاليين الذين احتجوا على إرسال برامجهم إلى " صندوق الجزاء "، وتم التخلي عنها فعليًا.

في مؤتمر WWDC'98، أعلن ستيف جوبز أن ردود الفعل السلبية بشأن الانتقال إلى Cocoa تم معالجتها من خلال تقديم نظام Carbon . سيسمح Carbon لبرامج Mac الحالية بالعمل بشكل أصلي تحت نظام التشغيل الجديد، بعد بعض التحويلات. أعلنت Metrowerks أنها ستنقل إطار عمل PowerPlant الخاص بها إلى Carbon، لكن لم يتم الإعلان عن شيء مماثل من قبل Apple فيما يتعلق بـ MacApp.

خلال هذه الفترة، ظل هناك عدد كبير من مستخدمي MacApp المخلصين الذين ازداد إحباطهم من سلوك Apple. وبحلول أواخر التسعينيات، أثناء طرح Cocoa، تطور هذا الشعور إلى رفض المنتج تمامًا. كانت الأمور سيئة للغاية لدرجة أن مجموعة من مستخدمي MacApp ذهبوا إلى حد تنظيم اجتماع خاص بهم في WWDC '98 تحت اسم مستعار، لتجنب رفض موظفي Apple لهم غرفة للاجتماع فيها.

وقد لوحظ هذا الدعم المستمر داخل شركة Apple، وفي أواخر عام 1999، تم تكليف فريق "جديد" من MacApp، يتكون من أعضاء عملوا عليه طوال الوقت، بإصدار إصدار جديد. وكان من بين هذه الإصدارات Apple Class Suites (ACS) الجديدة، وهي طبقة أرق من غلافات C++ للعديد من ميزات Mac OS الجديدة التي تم تقديمها من OpenStep، ودعم البناء في Project Builder. تم إصدار MacApp 3.0 Release XV ^[11] في 28 أغسطس 2001 لإسعاد الكثيرين. ومع ذلك، في أكتوبر، تم إيقاف المنتج مرة أخرى، هذه المرة إلى الأبد، وانتهى دعم الإصدارات الحالية من MacApp رسميًا.

لم يتم شحن PowerPlant X المتوافق مع Carbon حتى عام 2004، واليوم أصبح Cocoa عالميًا تقريبًا لكل من برمجتي MacOS وiOS.

يتم الحفاظ على MacApp من قبل مجموعة مخصصة من المطورين الذين حافظوا على الإطار وعززوه منذ أن توقفت Apple عن دعمه في عام 2001. تم تحديث MacApp لدعم Carbon Events و Universal Binaries و Unicode Text و MLTE control و DataBrowser control و FSRefs وتحليل XML و Custom Controls و Composite Window و Drawer Window و HIView Window و Custom Windows. يحتوي MacApp أيضًا على فئات غلاف C++ لـ HIObject و HIView. كما تم نقل إصدار Pascal، الذي يعتمد بشكل أساسي على MacApp-2، إلى Mac OS X و Xcode. يتميز بأسماء ملفات Unicode طويلة ومستندات متدفقة مع تبديل البايتات تلقائيًا.

يدعم MacApp بيئة التطوير المتكاملة Xcode . في الواقع، في مؤتمر WWDC 2005 ، بعد أن أعلنت Apple عن التحول إلى وحدات المعالجة المركزية Intel، استغرق الأمر من مطور واحد 48 ساعة لتحديث MacApp وتطبيقات MacApp النموذجية لدعم Universal Binaries.

يعتمد هذا الوصف على MacApp 3.0، الذي كان لديه نموذج أساسي أكثر تقدمًا من الإصدار 2.0 السابق له وكان يختلف في العديد من النواحي المهمة.

إن نظام التشغيل Mac OS نفسه يحتوي على نظام بسيط للغاية للتعامل مع الأحداث. فبنية الحدث التي تنتقل من نظام التشغيل إلى التطبيق لا تحتوي إلا على نوع حدث مثل "ضغطة مفتاح" أو "نقرة ماوس"، وتفاصيل موقع الحدث ومفاتيح التعديل التي يتم الضغط عليها باستمرار. ويتعين على التطبيق فك تشفير هذه المعلومات البسيطة وتحويلها إلى الإجراء الذي نفذه المستخدم، على سبيل المثال، النقر فوق أمر قائمة. وقد يكون فك تشفير هذا الأمر صعبًا، حيث يتعين عليك المرور عبر قوائم من الكائنات التي تظهر على الشاشة والتحقق مما إذا كان الحدث قد وقع ضمن حدودها.

لقد قدم MacApp حلاً لهذه المشكلة باستخدام نمط الأوامر ، حيث يتم تغليف إجراءات المستخدم في كائنات تحتوي على تفاصيل الحدث، ثم يتم إرسالها إلى الكائن المناسب لتنفيذها. تم التعامل مع منطق تعيين الحدث إلى "الكائن المناسب" بالكامل داخل الإطار ووقت تشغيله، مما قلل بشكل كبير من تعقيد هذه المهمة. إن دور الآلية الداخلية لـ MacApp هو أخذ أحداث نظام التشغيل الأساسية، وترجمتها إلى أوامر ذات مستوى أعلى دلاليًا، ثم توجيه الأمر إلى الكائن المناسب.

لم يقم MacApp بإعفاء المؤلف من الاضطرار إلى كتابة هذا الكود فحسب، وهو ما يتطلبه كل برنامج، ولكن أيضًا كأثر جانبي، قام هذا التصميم بفصل الكود بوضوح إلى أوامر وإجراءات تواجه المستخدم ومعالجاتها ، الكود الداخلي الذي قام بالعمل. على سبيل المثال، قد يكون لدى المرء أوامر لـ "Turn Green" و"Turn Red"، وكلاهما يتم التعامل معهما بواسطة وظيفة واحدة، ChangeColor(). كان البرنامج الذي يفصل الأوامر والمعالجات بوضوح معروفًا، في لغة Apple، بعامل .

كان تحليل البرنامج مهمًا بشكل خاص في الإصدارات اللاحقة من نظام التشغيل Mac OS، بدءًا من نظام التشغيل System 7. قدم نظام التشغيل System 7 نظام Apple Events ، الذي وسع نظام أحداث نظام التشغيل Mac OS الأصلي بنظام أكثر ثراءً يمكن إرساله بين التطبيقات، وليس فقط من نظام التشغيل إلى تطبيق معين. تم دمج هذا مع نظام AppleScript الذي سمح بإنشاء هذه الأحداث من كود البرمجة النصية. في MacApp 3.0، تم فك تشفير أحداث Apple إلى نفس الأوامر كما لو كانت قد بدأت من خلال إجراءات المستخدم المباشرة، مما يعني أن المطور لم يكن مضطرًا إلى كتابة الكثير من التعليمات البرمجية، إن وجدت، للتعامل مباشرة مع أحداث Apple. كانت هذه مشكلة كبيرة للمطورين الذين يستخدمون أنظمة أقدم، بما في ذلك MacApp 2.0، والتي لم يكن بها مثل هذا الفصل وغالبًا ما أدت إلى استبعاد دعم أحداث Apple.

تماشياً مع دوره كإطار عمل للتطبيقات، تضمن MacApp أيضاً عدداً من الكائنات الجاهزة التي تغطي معظم واجهة المستخدم الرسومية الأساسية لنظام Mac — النوافذ والقوائم والحوارات والأدوات المساعدة المماثلة كانت جميعها ممثلة داخل النظام. لسوء الحظ، كانت Apple تقدم عادةً غلافات خفيفة الوزن فوق كود نظام التشغيل Mac OS الداخلي الحالي بدلاً من توفير أنظمة قابلة للاستخدام في "العالم الحقيقي". على سبيل المثال، TTEViewتم تقديم الفئة كأداة محرر نصوص قياسية، لكن تنفيذ TextEdit الأساسي كان محدودًا بشدة وكانت Apple نفسها غالبًا ما تذكر أنه لا ينبغي استخدامه للتطبيقات الاحترافية. ونتيجة لذلك، غالبًا ما أُجبر المطورون على شراء كائنات إضافية لتلبية هذه الأنواع من الاحتياجات، أو إنشاء كائنات خاصة بهم. يمكن اعتبار الافتقار إلى مجموعة من كائنات واجهة المستخدم الرسومية ذات الجودة الاحترافية واحدة من أكبر مشاكل MacApp.

تم معالجة هذه المشكلة بإصدار MacApp R16. يستخدم MacApp R16 عناصر تحكم Carbon القياسية لجميع كائنات واجهة المستخدم الرسومية الخاصة بـ MacApp. على سبيل المثال، قدمت Carbon محرك النص متعدد اللغات (MLTE) لدعم نصوص Unicode الكاملة والمستندات الطويلة. في R16، TTEViewتم استبدال الفئة الأصلية بـ TMLTEView، والتي تستخدم عنصر التحكم MLTE.

تم كتابة Adobe Photoshop في الأصل باستخدام MacApp 1.1.1، بلغة Object Pascal ، وتم نقله لاحقًا إلى C++ وMacApp 3.0 لـ Photoshop 2.5. بعد إلغاء MacApp بواسطة Apple، تولى فريق تطوير Photoshop الصيانة داخليًا، وتم نقله إلى PowerPC ، وتحويله ليتم مشاركته مع منفذ نظام التشغيل Windows. ^[1]

• دليل المبرمجين لـ MacApp - وثائق كاملة من سلسلة Inside Macintosh