For example, http://developer.apple.com/cocoa/pyobjc.html is still for OS X 10.4 Tiger, not 10.5 Leopard.. And that's the official Apple documentation for it..
例如,http://developer.apple.com/cocoa/pyobjc.html仍然适用于OS X 10.4 Tiger,而不是10.5 Leopard ..而且这是Apple的官方文档..
The official PyObjC page is equally bad, http://pyobjc.sourceforge.net/
官方的PyObjC页面同样糟糕,http://pyobjc.sourceforge.net/
It's so bad it's baffling.. I'm considering learning Ruby primarily because the RubyCocoa stuff is so much better documented, and there's lots of decent tutorials (http://www.rubycocoa.com/ for example), and because of the Shoes GUI toolkit..
这太糟糕了,令人费解......我正在考虑学习Ruby主要是因为RubyCocoa的东西有更好的文档记录,并且有很多不错的教程(例如http://www.rubycocoa.com/),并且因为鞋子GUI工具包..
Even this badly-auto-translated Japanese tutorial is more useful than the rest of the documentation I could find..
即使是这个非常自动翻译的日语教程比我能找到的其他文档更有用..
All I want to do is create fairly simple Python applications with Cocoa GUI's..
Can anyone shed light on the horrible documentation, or point me at some tutorials that don't just give you huge blocks of code and assume you know what NSThread.detachNewThreadSelector_toTarget_withObject_("queryController", self, None) does..?
我想要做的就是使用Cocoa GUI创建相当简单的Python应用程序。任何人都可以了解可怕的文档,或者指出一些不只是给你大量代码的教程,并假设你知道NSThread.detachNewThreadSelector_toTarget_withObject_ (“queryController”,self,None)有..?
9 个解决方案
#1
21
I agree that that tutorial is flawed, throwing random, unexplained code right in front of your eyes. It introduces concepts such as the autorelease pool and user defaults without explaining why you would want them ("Autorelease pool for memory management" is hardly an explanation).
我同意该教程存在缺陷,在您面前抛出随机,无法解释的代码。它引入了自动释放池和用户默认值等概念,但没有解释为什么你会想要它们(“内存管理的自动释放池”几乎不是解释)。
That said…
basically all I want to do is write Cocoa applications without having to learn ObjC.
基本上我想做的就是编写Cocoa应用程序而无需学习ObjC。
I'm afraid that for the time being, you will need a basic grasp of ObjC in order to benefit from any language that uses Cocoa. PyObjC, RubyCocoa, Nu and others are niches at best, and all of them were developed by people intimately familiar with the ins and outs of ObjC and Cocoa.
我担心目前你需要对ObjC有一个基本的把握,以便从任何使用Cocoa的语言中受益。 PyObjC,RubyCocoa,Nu和其他人都是最好的利基,所有这些都是由熟悉ObjC和Cocoa的细节的人开发的。
For now, you will benefit the most if you realistically see those bridges as useful where scripting languages truly shine, rather than trying to build a whole application with them. While this has been done (with LimeChat, I'm using a RubyCocoa-written app right now), it is rare and likely will be for a while.
现在,如果您真实地看到这些桥接在脚本语言真正发挥作用时非常有用,而不是尝试使用它们构建整个应用程序,那么您将受益最多。虽然已经完成了(使用LimeChat,我现在正在使用RubyCocoa编写的应用程序),但它很少见,很可能会持续一段时间。
#2
28
The main reason for the lack of documentation for PyObjC is that there is one developer (me), and as most developers I don't particularly like writing documentation. Because PyObjC is a side project for me I tend to focus on working on features and bugfixes, because that's more interesting for me.
PyObjC缺乏文档的主要原因是有一个开发人员(我),而且大多数开发人员我并不特别喜欢编写文档。因为PyObjC对我来说是一个侧面项目,所以我倾向于专注于功能和错误修正,因为这对我来说更有趣。
The best way to improve the documentation is to volunteer to help on the pyobjc-dev mailing list.
改进文档的最佳方法是自愿提供pyobjc-dev邮件列表方面的帮助。
As an aside: the pythonmac-sig mailinglist (see google) is an excelent resource for getting help on Python on MacOSX (not just PyObjC).
顺便说一句:pythonmac-sig邮件列表(请参阅google)是在MacOSX(而不仅仅是PyObjC)上获取Python帮助的优秀资源。
#3
21
To be blunt:
直言不讳:
If you want to be an effective Cocoa programmer, you must learn Objective-C. End of story.
如果你想成为一名有效的Cocoa程序员,你必须学习Objective-C。故事结局。
Neither Python or Ruby are a substitute for Objective-C via their respective bridges. You still have to understand the Objective-C APIs, the behaviors inherent to NSObject derived classes, and many other details of Cocoa.
Python或Ruby都不能通过各自的桥梁替代Objective-C。您仍然需要了解Objective-C API,NSObject派生类固有的行为以及Cocoa的许多其他细节。
PyObjC and RubyCocoa are a great way to access Python or Ruby functionality from a Cocoa application, including building a Cocoa application mostly -- if not entirely -- in Python or Ruby. But success therein is founded upon a thorough understanding of Cocoa and the Objective-C APIs it is composed of.
PyObjC和RubyCocoa是从Cocoa应用程序访问Python或Ruby功能的好方法,包括在Python或Ruby中构建Cocoa应用程序 - 如果不是全部的话 - 。但其中的成功建立在对Cocoa及其组成的Objective-C API的透彻理解之上。
#4
7
Tom's and Martin's response are definitely true (in just about any open source project, you'll find that most contributors are particularly interested in, well, developing; not so much in semi-related matters such as documentation), but I don't think your particular question at the end would fit well inside PyObjC documentation.
汤姆和马丁的回答绝对是真的(在任何开源项目中,你会发现大多数贡献者特别感兴趣,好吧,开发;而不是在半相关的事情,如文档),但我不认为你最后的特定问题很适合PyObjC文档。
NSThread.detachNewThreadSelector_toTarget_withObject_("queryController", self, None)
NSThread is part of the Cocoa API, and as such documented over at Apple, including the particular method + detachNewThreadSelector:toTarget:withObject: (I'd link there, but apparently * has bugs with parsing it). The CocoaDev wiki also has an article.
NSThread是Cocoa API的一部分,因此在Apple上有记录,包括特定方法+ detachNewThreadSelector:toTarget:withObject :(我在那里链接,但显然*有解析它的bug)。 CocoaDev wiki也有一篇文章。
I don't think it would be a good idea for PyObjC to attempt to document Cocoa, other than a few basic examples of how to use it from within Python. Explaining selectors is also likely outside the scope of PyObjC, as those, too, are a feature of Objective-C, not PyObjC specifically.
我不认为PyObjC尝试记录Cocoa是个好主意,除了一些如何在Python中使用它的基本示例。解释选择器也可能超出PyObjC的范围,因为它们也是Objective-C的一个特性,而不是PyObjC的特征。
#5
7
I stumbled across a good tutorial on PyObjC/Cocoa:
我偶然发现了一个关于PyObjC / Cocoa的好教程:
http://lethain.com/entry/2008/aug/22/an-epic-introduction-to-pyobjc-and-cocoa/
#6
5
All I want to do is create fairly simple Python applications with Cocoa GUI's.. Can anyone shed light on the horrible documentation, or point me at some tutorials that don't just give you huge blocks of code and assume you know what NSThread.detachNewThreadSelector_toTarget_withObject_("queryController", self, None) does..?
我想要做的就是使用Cocoa GUI创建相当简单的Python应用程序。任何人都可以了解可怕的文档,或者指出一些不只是给你大量代码的教程,并假设你知道NSThread.detachNewThreadSelector_toTarget_withObject_ (“queryController”,self,None)有..?
[...]
basically all I want to do is write Cocoa applications without having to learn ObjC.
基本上我想做的就是编写Cocoa应用程序而无需学习ObjC。
Although I basically agree with Soeren's response, I'd take it even further:
虽然我基本同意Soeren的回应,但我会更进一步:
It will be a long time, if ever, before you can use Cocoa without some understanding of Objective C. Cocoa isn't an abstraction built independently from Objective C, it is explicitly tied to it. You can see this in the example line of code you quoted above:
如果有的话,在你可以使用Cocoa而不了解Objective C之前,这将是一段很长的时间.Cocoa不是一个独立于Objective C构建的抽象,它与它明确地联系在一起。您可以在上面引用的示例代码行中看到这一点:
NSThread.detachNewThreadSelector_toTarget_withObject_("queryController", self, None)
This is the Python way of writing the Objective C line:
这是编写Objective C行的Python方法:
[NSThread detachNewThreadSelector:@selector(queryController:) toTarget:self withObject:nil];
Now, it's important to notice here that this line can be seen in two ways: (1) as a line of Objective C, or (2) as an invocation of the Cocoa frameworks. We see it as (1) by the syntax. We see it as (2) by recognizing that NSThread is a Cocoa framework which provides a set of handy features. In this case, this particular Cocoa framework is making it easy for us to have an object start doing something on a new thread.
现在,重要的是要注意这一行可以用两种方式看出:(1)作为一行Objective C,或(2)作为Cocoa框架的调用。我们通过语法将其视为(1)。我们将其视为(2)通过认识到NSThread是一个Cocoa框架,它提供了一组方便的功能。在这种情况下,这个特定的Cocoa框架使我们很容易让对象开始在新线程上做某事。
But the kicker is this: The Cocoa framework here (NSThread) is providing us this handy service in a way that is explicitly tied to the language the framework has been written in. Namely, NSThread gave us a feature that explicitly refers to "selectors". Selectors are, in point of fact, the name for something fundamental about how Objective C works.
但是踢球者是这样的:这里的Cocoa框架(NSThread)以一种与框架语言明确联系的方式为我们提供这种方便的服务。也就是说,NSThread为我们提供了一个明确指代“选择器”的功能。 。事实上,选择器是关于Objective C如何工作的基本名称。
So there's the rub. Cocoa is fundamentally an Objective-C creation, and its creators have built it with Objective C in mind. I'm not claiming that it's impossible to translate the interface to the Cocoa features into a form more natural for other languages. It's just that as soon as you change the Cocoa framework to stop referring to "selectors", it's not really the Cocoa framework any more. It's a translated version. And once you start going down that road, I'm guessing things get really messy. You're trying to keep up with Apple as they update Cocoa, maybe you hit some parts of Cocoa that just don't translate well into the new language, whatever. So instead, things like PyObjC opt to expose Cocoa directly, in a way that has a very clear and simple correlation. As they say in the documentation:
所以有一点问题。 Cocoa从根本上说是一个Objective-C创建,它的创建者在构建它时考虑了Objective C.我并不是说不可能将Cocoa功能的界面翻译成其他语言更自然的形式。只是当你改变Cocoa框架以停止引用“选择器”时,它就不再是Cocoa框架了。这是一个翻译版本。一旦你开始走这条路,我猜测事情变得非常混乱。你正在努力跟上苹果公司,因为他们更新了Cocoa,也许你会碰到Cocoa的某些部分,而这些部分只是不能很好地翻译成新语言,无论如何。因此,像PyObjC这样的东西选择直接暴露Cocoa,其方式具有非常清晰和简单的相关性。正如他们在文档中所说:
In order to have a lossless and unambiguous translation between Objective-C messages and Python methods, the Python method name equivalent is simply the selector with colons replaced by underscores.
为了在Objective-C消息和Python方法之间进行无损且无歧义的转换,Python方法名称等价物只是选择器,冒号由下划线替换。
Sure, it's a bit ugly, and it does mean you need to know something about Objective-C, but that's because the alternative, if one truly exists, is not necessarily better.
当然,它有点难看,它确实意味着你需要了解一些关于Objective-C的东西,但那是因为如果一个真正存在的替代品不一定更好。
#7
4
I didn't know anything at all about Objective C or Cocoa (but plenty about Python), but I am now writing a rather complex application in PyObjc. How did I learn? I picked up Cocoa Programming for OSX and went through the whole book (a pretty quick process) using PyObjC. Just ignore anything about memory management and you'll pretty much be fine. The only caveat is that very occasionally you have to use a decorator like endSheetMethod (actually I think that's the only one I've hit):
我对Objective C或Cocoa一无所知(但有很多关于Python的东西),但我现在正在PyObjc中编写一个相当复杂的应用程序。我是如何学习的?我为OSX选择了Cocoa Programming并使用PyObjC完成了整本书(一个非常快速的过程)。只要忽略有关内存管理的任何内容,你就会很好。唯一需要注意的是,偶尔你必须使用像endSheetMethod这样的装饰器(实际上我认为这是我唯一能够击中的装饰器):
@PyObjcTools.AppHelper.endSheetMethod
def alertEnded_code_context_(self, alert, choice, context):
pass
#8
3
This answer isn't going to be very helpful but, as a developer I hate doing documentation. This being a opensource project, it's hard to find people to do documentation.
这个答案不是很有帮助,但作为开发人员,我讨厌做文档。这是一个开源项目,很难找人做文档。
#9
3
Tom says it all really. Lots of open source projects have dedicated developers and few who are interested in documenting. It isn't helped by the fact that goalposts can shift on a daily basis which means documentation not only has to be created, but maintained.
汤姆说的都是真的。许多开源项目都有专门的开发人员,很少有人对文档感兴趣。球门柱可以每天转移,这意味着文件不仅必须创建,而且必须维护。
#1
21
I agree that that tutorial is flawed, throwing random, unexplained code right in front of your eyes. It introduces concepts such as the autorelease pool and user defaults without explaining why you would want them ("Autorelease pool for memory management" is hardly an explanation).
我同意该教程存在缺陷,在您面前抛出随机,无法解释的代码。它引入了自动释放池和用户默认值等概念,但没有解释为什么你会想要它们(“内存管理的自动释放池”几乎不是解释)。
That said…
basically all I want to do is write Cocoa applications without having to learn ObjC.
基本上我想做的就是编写Cocoa应用程序而无需学习ObjC。
I'm afraid that for the time being, you will need a basic grasp of ObjC in order to benefit from any language that uses Cocoa. PyObjC, RubyCocoa, Nu and others are niches at best, and all of them were developed by people intimately familiar with the ins and outs of ObjC and Cocoa.
我担心目前你需要对ObjC有一个基本的把握,以便从任何使用Cocoa的语言中受益。 PyObjC,RubyCocoa,Nu和其他人都是最好的利基,所有这些都是由熟悉ObjC和Cocoa的细节的人开发的。
For now, you will benefit the most if you realistically see those bridges as useful where scripting languages truly shine, rather than trying to build a whole application with them. While this has been done (with LimeChat, I'm using a RubyCocoa-written app right now), it is rare and likely will be for a while.
现在,如果您真实地看到这些桥接在脚本语言真正发挥作用时非常有用,而不是尝试使用它们构建整个应用程序,那么您将受益最多。虽然已经完成了(使用LimeChat,我现在正在使用RubyCocoa编写的应用程序),但它很少见,很可能会持续一段时间。
#2
28
The main reason for the lack of documentation for PyObjC is that there is one developer (me), and as most developers I don't particularly like writing documentation. Because PyObjC is a side project for me I tend to focus on working on features and bugfixes, because that's more interesting for me.
PyObjC缺乏文档的主要原因是有一个开发人员(我),而且大多数开发人员我并不特别喜欢编写文档。因为PyObjC对我来说是一个侧面项目,所以我倾向于专注于功能和错误修正,因为这对我来说更有趣。
The best way to improve the documentation is to volunteer to help on the pyobjc-dev mailing list.
改进文档的最佳方法是自愿提供pyobjc-dev邮件列表方面的帮助。
As an aside: the pythonmac-sig mailinglist (see google) is an excelent resource for getting help on Python on MacOSX (not just PyObjC).
顺便说一句:pythonmac-sig邮件列表(请参阅google)是在MacOSX(而不仅仅是PyObjC)上获取Python帮助的优秀资源。
#3
21
To be blunt:
直言不讳:
If you want to be an effective Cocoa programmer, you must learn Objective-C. End of story.
如果你想成为一名有效的Cocoa程序员,你必须学习Objective-C。故事结局。
Neither Python or Ruby are a substitute for Objective-C via their respective bridges. You still have to understand the Objective-C APIs, the behaviors inherent to NSObject derived classes, and many other details of Cocoa.
Python或Ruby都不能通过各自的桥梁替代Objective-C。您仍然需要了解Objective-C API,NSObject派生类固有的行为以及Cocoa的许多其他细节。
PyObjC and RubyCocoa are a great way to access Python or Ruby functionality from a Cocoa application, including building a Cocoa application mostly -- if not entirely -- in Python or Ruby. But success therein is founded upon a thorough understanding of Cocoa and the Objective-C APIs it is composed of.
PyObjC和RubyCocoa是从Cocoa应用程序访问Python或Ruby功能的好方法,包括在Python或Ruby中构建Cocoa应用程序 - 如果不是全部的话 - 。但其中的成功建立在对Cocoa及其组成的Objective-C API的透彻理解之上。
#4
7
Tom's and Martin's response are definitely true (in just about any open source project, you'll find that most contributors are particularly interested in, well, developing; not so much in semi-related matters such as documentation), but I don't think your particular question at the end would fit well inside PyObjC documentation.
汤姆和马丁的回答绝对是真的(在任何开源项目中,你会发现大多数贡献者特别感兴趣,好吧,开发;而不是在半相关的事情,如文档),但我不认为你最后的特定问题很适合PyObjC文档。
NSThread.detachNewThreadSelector_toTarget_withObject_("queryController", self, None)
NSThread is part of the Cocoa API, and as such documented over at Apple, including the particular method + detachNewThreadSelector:toTarget:withObject: (I'd link there, but apparently * has bugs with parsing it). The CocoaDev wiki also has an article.
NSThread是Cocoa API的一部分,因此在Apple上有记录,包括特定方法+ detachNewThreadSelector:toTarget:withObject :(我在那里链接,但显然*有解析它的bug)。 CocoaDev wiki也有一篇文章。
I don't think it would be a good idea for PyObjC to attempt to document Cocoa, other than a few basic examples of how to use it from within Python. Explaining selectors is also likely outside the scope of PyObjC, as those, too, are a feature of Objective-C, not PyObjC specifically.
我不认为PyObjC尝试记录Cocoa是个好主意,除了一些如何在Python中使用它的基本示例。解释选择器也可能超出PyObjC的范围,因为它们也是Objective-C的一个特性,而不是PyObjC的特征。
#5
7
I stumbled across a good tutorial on PyObjC/Cocoa:
我偶然发现了一个关于PyObjC / Cocoa的好教程:
http://lethain.com/entry/2008/aug/22/an-epic-introduction-to-pyobjc-and-cocoa/
#6
5
All I want to do is create fairly simple Python applications with Cocoa GUI's.. Can anyone shed light on the horrible documentation, or point me at some tutorials that don't just give you huge blocks of code and assume you know what NSThread.detachNewThreadSelector_toTarget_withObject_("queryController", self, None) does..?
我想要做的就是使用Cocoa GUI创建相当简单的Python应用程序。任何人都可以了解可怕的文档,或者指出一些不只是给你大量代码的教程,并假设你知道NSThread.detachNewThreadSelector_toTarget_withObject_ (“queryController”,self,None)有..?
[...]
basically all I want to do is write Cocoa applications without having to learn ObjC.
基本上我想做的就是编写Cocoa应用程序而无需学习ObjC。
Although I basically agree with Soeren's response, I'd take it even further:
虽然我基本同意Soeren的回应,但我会更进一步:
It will be a long time, if ever, before you can use Cocoa without some understanding of Objective C. Cocoa isn't an abstraction built independently from Objective C, it is explicitly tied to it. You can see this in the example line of code you quoted above:
如果有的话,在你可以使用Cocoa而不了解Objective C之前,这将是一段很长的时间.Cocoa不是一个独立于Objective C构建的抽象,它与它明确地联系在一起。您可以在上面引用的示例代码行中看到这一点:
NSThread.detachNewThreadSelector_toTarget_withObject_("queryController", self, None)
This is the Python way of writing the Objective C line:
这是编写Objective C行的Python方法:
[NSThread detachNewThreadSelector:@selector(queryController:) toTarget:self withObject:nil];
Now, it's important to notice here that this line can be seen in two ways: (1) as a line of Objective C, or (2) as an invocation of the Cocoa frameworks. We see it as (1) by the syntax. We see it as (2) by recognizing that NSThread is a Cocoa framework which provides a set of handy features. In this case, this particular Cocoa framework is making it easy for us to have an object start doing something on a new thread.
现在,重要的是要注意这一行可以用两种方式看出:(1)作为一行Objective C,或(2)作为Cocoa框架的调用。我们通过语法将其视为(1)。我们将其视为(2)通过认识到NSThread是一个Cocoa框架,它提供了一组方便的功能。在这种情况下,这个特定的Cocoa框架使我们很容易让对象开始在新线程上做某事。
But the kicker is this: The Cocoa framework here (NSThread) is providing us this handy service in a way that is explicitly tied to the language the framework has been written in. Namely, NSThread gave us a feature that explicitly refers to "selectors". Selectors are, in point of fact, the name for something fundamental about how Objective C works.
但是踢球者是这样的:这里的Cocoa框架(NSThread)以一种与框架语言明确联系的方式为我们提供这种方便的服务。也就是说,NSThread为我们提供了一个明确指代“选择器”的功能。 。事实上,选择器是关于Objective C如何工作的基本名称。
So there's the rub. Cocoa is fundamentally an Objective-C creation, and its creators have built it with Objective C in mind. I'm not claiming that it's impossible to translate the interface to the Cocoa features into a form more natural for other languages. It's just that as soon as you change the Cocoa framework to stop referring to "selectors", it's not really the Cocoa framework any more. It's a translated version. And once you start going down that road, I'm guessing things get really messy. You're trying to keep up with Apple as they update Cocoa, maybe you hit some parts of Cocoa that just don't translate well into the new language, whatever. So instead, things like PyObjC opt to expose Cocoa directly, in a way that has a very clear and simple correlation. As they say in the documentation:
所以有一点问题。 Cocoa从根本上说是一个Objective-C创建,它的创建者在构建它时考虑了Objective C.我并不是说不可能将Cocoa功能的界面翻译成其他语言更自然的形式。只是当你改变Cocoa框架以停止引用“选择器”时,它就不再是Cocoa框架了。这是一个翻译版本。一旦你开始走这条路,我猜测事情变得非常混乱。你正在努力跟上苹果公司,因为他们更新了Cocoa,也许你会碰到Cocoa的某些部分,而这些部分只是不能很好地翻译成新语言,无论如何。因此,像PyObjC这样的东西选择直接暴露Cocoa,其方式具有非常清晰和简单的相关性。正如他们在文档中所说:
In order to have a lossless and unambiguous translation between Objective-C messages and Python methods, the Python method name equivalent is simply the selector with colons replaced by underscores.
为了在Objective-C消息和Python方法之间进行无损且无歧义的转换,Python方法名称等价物只是选择器,冒号由下划线替换。
Sure, it's a bit ugly, and it does mean you need to know something about Objective-C, but that's because the alternative, if one truly exists, is not necessarily better.
当然,它有点难看,它确实意味着你需要了解一些关于Objective-C的东西,但那是因为如果一个真正存在的替代品不一定更好。
#7
4
I didn't know anything at all about Objective C or Cocoa (but plenty about Python), but I am now writing a rather complex application in PyObjc. How did I learn? I picked up Cocoa Programming for OSX and went through the whole book (a pretty quick process) using PyObjC. Just ignore anything about memory management and you'll pretty much be fine. The only caveat is that very occasionally you have to use a decorator like endSheetMethod (actually I think that's the only one I've hit):
我对Objective C或Cocoa一无所知(但有很多关于Python的东西),但我现在正在PyObjc中编写一个相当复杂的应用程序。我是如何学习的?我为OSX选择了Cocoa Programming并使用PyObjC完成了整本书(一个非常快速的过程)。只要忽略有关内存管理的任何内容,你就会很好。唯一需要注意的是,偶尔你必须使用像endSheetMethod这样的装饰器(实际上我认为这是我唯一能够击中的装饰器):
@PyObjcTools.AppHelper.endSheetMethod
def alertEnded_code_context_(self, alert, choice, context):
pass
#8
3
This answer isn't going to be very helpful but, as a developer I hate doing documentation. This being a opensource project, it's hard to find people to do documentation.
这个答案不是很有帮助,但作为开发人员,我讨厌做文档。这是一个开源项目,很难找人做文档。
#9
3
Tom says it all really. Lots of open source projects have dedicated developers and few who are interested in documenting. It isn't helped by the fact that goalposts can shift on a daily basis which means documentation not only has to be created, but maintained.
汤姆说的都是真的。许多开源项目都有专门的开发人员,很少有人对文档感兴趣。球门柱可以每天转移,这意味着文件不仅必须创建,而且必须维护。