砸死

好,没多久就澄清了。

周四我写了关于Dan Gillmor的文章San Jose Mercury News上关于前NeXT开发者发布成功的Mac OS X应用程序的一篇考虑不周的文章我特别提到了Gillmor引用Stone Design的Andrew Stone的一些评论但是我试着在Stone上轻松一点,因为Gillmor只引用了几个选择词,我无法知道它们是否脱离了语境。

然而,第二天,斯通澄清了他的立场星期五Stone Design发布FontSightMac OS X的新工具,增加了一个WYSIWYG字体菜单所有Cocoa应用程序它类似于经典的Mac OS扩展,如MenuFonts和行动所见即所得

现在这一事实FontSight仅适用于可可应用程序不是一个问题显然会更好如果它与碳应用程序,但它是一个合理的限制在旧的Mac OS上,像MenuFonts和Action WYSIWYG这样的扩展通过修补操作系统本身的例程来完成它们的工作。这使得一些非常有创意的软件,但它也可能会导致严重的不稳定除了Apple扩展之外什么都没有运行的Mac OS系统是坚如磐石的然而,开始投入修补系统的第三方扩展,并且所有赌注都已关闭问题是虽然可以修补,但是不支持当补丁发生冲突时(例如两个扩展使用相同的低内存变量玩游戏),可能的结果是你的整个系统崩溃了。

这不是Mac OS X上的工作方式,这绝对是一个更好的改变你仍然可以实现全系统攻击(参见亵渎神的Haxies), but you can’t do it at the same “one wrong step and your entire machine will crash” level that you could on Mac OS 9.

此外,因为Cocoa应用程序使用相同的编程框架和依赖于相同的操作系统资源,它是可能的修改或添加这些资源的影响所有系统上的Cocoa应用程序这不是黑客攻击 - 这是Cocoa面向对象设计中非常慎重的特性例如,F-脚本is a powerful scripting system for Cocoa applications; F-Script scripts have access to the same Cocoa object model as Objective-C.

I don’t know how Stone’s FontSight is implemented, but I think it’s a reasonable guess that he’s overriding the default menus in Cocoa’s object model如果是这样,这种技术不可能在Carbon应用程序中起作用就像我说的,在可可FontSight只应用程序并不是一个问题,没有什么错与利用先进的可可特性。

什么是一个问题,然而,是石头的描述non-Cocoa应用程序。

例如,关于FontSight Developer的信息页:

FontSight™与所有Cocoa应用程序(真正的Native [原文如此] OS X应用程序)无缝地[原文如此] - 例如iCal,iPhoto,TextEdit,Mail以及Stone Design的所有应用程序,如Create®或PhotoToWeb®。

Eric Blair称Stone出局在这笑声,写道:

What the hell does “truly Native OS X apps” mean? As much as I like可可,没有什么更多的OS X本地写得比一个好应用程序如果您将Carbon应用程序编译为Mach-O的二进制,它只能在OS X上运行Stone Design的人们是否试图告诉我们这些应用程序不是OS X原生的?

是的,这正是他们试图告诉我们的这里有更多,来自FontSight新闻稿

FontSight功能包括:

  • 将可视字体菜单添加到本机OS X应用程序

换句话说,“原生OS X Apps [sic]”的意思是“Cocoa”然后,在脚注中:

可可是苹果的革命性,本地OS X开发系统所有Stone应用程序都是用Cocoa编写的,Apple的TextEdit,iCal,iPhoto,Safari,Mail等也是如此。在不利用OS X的本机功能的情况下移植到OS X的Carbon应用程序不显示FontSight菜单。

现在这只是彻头彻尾的侮辱这意味着开发人员“利用”Mac OS X的唯一方法就是使用Cocoa因此,例如,BBEdit 7与以下内容集成的事实:

  • 所有Unix shell脚本语言
  • CVS
  • 项目构建器

更不用说它在Dock图标中显示搜索结果的运行计数,它不是“利用OS X的本机功能”?

这并不是说所有Mac OS X应用程序都是平等的Cocoa应用程序确实具有Carbon应用程序无法使用的某些功能(同样,Carbon API可以访问Cocoa独有的功能。)Cocoa开发人员推广这些功能没有任何问题,石头可能不是简单地写类似如下:

“FontSight是使用Apple的革命性Mac OS X应用程序框架Cocoa中的高级功能实现的因此,FontSight菜单只出现在Cocoa应用程序中,例如所有Stone Design应用程序,以及Apple的TextEdit,Mail,Safari,iCal和iPhoto。“

这称为推广您的功能。

但相反,斯通利用这个机会污染了Carbon应用程序,声称他们“不是原生”那被称为偏执仅仅因为碳开发商没有利用可可并不意味着他们没有利用Mac OS X.; Cocoa is a part of the OS, not the OS itself.

Stone和其他Cocoa开发人员可以通过这种反碳偏见来摆脱它,因为“原生”不是技术描述“可可”是一种技术描述,“mach-o binary”也是如此。这个应用程序是一个Cocoa应用程序。这是一个可以证明是真是假的陈述。此应用程序是Mac OS X的原生应用程序。这是一个取决于你的“本土”含义的陈述Stone Design显然认为“本土”意味着“可可”。

大多数Mac用户很少或根本不了解“Cocoa”或“mach-o”或其他什么的实际技术定义,他们也不需要因此,通过将Cocoa与形容词“native”等同起来 - 这个词的意思看似显而易见,但实际上含糊不清 - Stone给人的印象是除了Cocoa以外的任何东西本质上都是劣等的,而不是真实的,伪造它。你不想使用非本地申请,好吗?

小开发者

安德鲁·斯通显然对Cocoa的优势充满热情和知识我再说一遍:他应该感到自由促进这些优势明显和突出正如“因为我们的应用程序是Cocoa,你可以做到这个,和这个,和这个这些功能使我们的应用程序更加出色。“不是,”我们的应用程序之所以优越,只是因为它们是Cocoa。

苹果公司的某些高管在这方面并没有提供帮助,过去曾暗示碳是在通往全可可未来的道路上的一个权宜之计。许多Mac用户仍然认为这是真的,但事实并非如此Carbon is not just a compatibility layer for old applications; it’s a deep chunk of the OS.

让我们退一步,想象一下我错了,Andrew Stone是对的:Cocoa应用本质上优于Carbon应用程序如果这是真的,那是什么意思?

Why, for example, have none of the major Mac applications been rewritten in Cocoa? Microsoft Office is Carbon从Adobe也是如此和Macromedia无论何时发货,QuarkXPress 6都将成为Carbon。的BBEdit脚本调试器是碳。

这些都是来自顶级Mac开发人员的流行且长期存在的Mac应用程序如果Stone是对的,为什么他们都通过运送不合标准的应用程序对他们的客户造成这样的伤害?

What is a plausible explanation? That Mac developers are stupid (too stupid to understand Cocoa, or too stupid to recognize its superiority)? Are they lazy? Are they spiteful? If you accept as fact that Carbon applications are inherently inferior to Cocoa ones, you must therefore accept that Mac developers shipping Carbon applications are either incompetent or are knowingly shipping inferior products to their customers.

Do you see how this is insulting? Not just insulting to established Mac developers (although it is), but also to Mac users in general, who are being sold a bill of goods on the assumption that they lack the technical expertise to see through these claims of “nativeness”.

那么呢?

事实真的很无聊可可是一个应用程序框架这是一个优秀的开发系统,但是,它只是一个框架应用程序框架处理所有应用程序通用的所有通用内容 - 窗口,菜单,按钮,鼠标单击,事件循环等如果您打开项目构建器并创建一个新的默认Cocoa项目,您可以从一个正在运行的应用程序开始 - 您可以编译它并获得一个带有菜单栏,关于框等的双击应用程序作为一名开发人员,可可处理很多东西“免费”。

但是默认的Cocoa应用程序实际上并没有什么如果您正在开发矢量绘图应用程序,您仍然需要编写代码来完成所有矢量绘图工作如果您正在编写会计软件包,则需要编写所有会计逻辑和功能Makes sense, right? Using an application framework like Cocoa to manage the generic details frees developers to concentrate on what it is their apps are supposed to do.

但无论Cocoa有多好,它都有点狭隘,认为它是Mac OS X唯一的合法应用程序框架首先,许多长期的Mac开发人员拥有他们的拥有框架,从头开始编写,以满足他们的特定需求例如我们可能认为,Adobe有一个针对图形密集型应用程序优化的应用程序框架Adobe applications share a similar and distinctive human interface; for example, Adobe’s tabbed palettes are an innovative (and专利)该公司明确认为具有竞争优势的特征Could Adobe re-implement tabbed palettes in Cocoa? Of course —但是他们已经在现有的框架中实现了它们

或者注意:可可有一些重大的缺点它对AppleScript的支持充其量只是平庸Bare Bones的BBEdit和Mailsmith不仅可以完全编写脚本,而且还可以录制Cocoa确实提供了一些AppleScript支持,但与BBEdit相比,它显得相形见绌。

所以关键在于:Cocoa的许多优点都适用于此项目毫无疑问,开发人员编写自己的应用程序框架的工作量更大,但如果他们已经完成并且多年来一直在使用它,那么切换现在几乎没有优势。

Shouldn’t we safely assume that top Mac developers know more about the internal structure and framework of their applications than we do? Shouldn’t we decide which applications to use — like, say, whether to use Adobe Illustrator or Stone Design’s Create — based on what they do, rather than how they’re made?

Postscript, Delivered with a Satisfied Smirk

And by the way, isn’t Cocoa’s standard Font Panel palette supposed to obsolete the old-fashioned Font menu? Just curious.

以前: 容纳
下一个: RTF到纯文本翻译器