On Dec 20, 2004, at 3:52 PM, Jordan Krushen wrote:
> On Mon, 20 Dec 2004 06:08:10 -0500, Bob Ippolito <bob@...>
>> Since so much of your code is going to be written in Objective-C and
>> not Python, why not just write a plugin that contains your model
> You'd mentioned previously that the plugin handling was kinda hackish,
> so I didn't think it was deployable yet. Are we talking about the
> same plugin procedure? embed_tutorial or the __plugin_hack__ (sic?)
It's perfectly deployable, and it's not hackish. There is one hack
present that works around a NSBundle misfeature for exactly one class
per plugin, which is sufficient for just about anything, if necessary
>> Interface Builder and Xcode probably don't integrate as much as you
>> think they do.
> I understand that it's all superficial, but I'm trying to give the
> client something they can hire someone else to modify (at least the
> UI), using standard tools.
Well, standard tools in this case is Python with a setup.py.
>>> It would also allow for an easier time with regards to bindings and a
>>> few other things in a certain future OS that may not be wrapped yet..
>> That doesn't really have anything at all to do with Xcode.
> No, but KVO/KVC aren't exactly seamless yet when being passed across
> the bridge -- it has to do with ObjC v. Python, and if I'm writing in
> ObjC, why not use Xcode? To be honest, I don't really care what the
> editor is. All I want is a way to compile the ObjC and the PyObjC
> stuff together into an app that works, and all I hear is that plugins
> are a hack, that it can only handle one class, or that Xcode is
> deprecated.. please correct me if I'm wrong :)
KVO / KVC works just fine across the bridge if you follow the same
constraints as you would from Objective-C, namely, don't touch instance
variables directly. Yes, if you define accessor methods, you will have
to use @objc.accessor (or longer non-decorator equivalent).
You are wrong, plugins are not a hack. The only aspect of plugins that
are a hack is the fact that it's only possible to have one class "do
the right thing" with +[NSBundle bundleForClass:]. This is only really
applicable to your NSPrincipalClass, if even then, unless you introduce
code that uses it internally. So, you don't need more than one class
to respond "correctly" from NSBundle.
Xcode projects are more or less deprecated for deployment. They don't
work any better or worse than they did before. py2app based
applications work much better.