Was würden Sie für die OS X-Entwicklung einer grafischen Anwendung, wie sie in WPF möglich ist, empfehlen?Rich GUI OS X-Frameworks?
Mein spezifischer Hintergrund ist in Smalltalk & Java, aber ich arbeite zur Zeit hauptsächlich in DHTML/.NET (ASP.NET/C#).
Kakao. Von vielen als das beste Anwendungs-Framework aller Zeiten angesehen. Die Sprache ist Objective-C, SmallTalk-ähnliche Sprache, die die Schöpfer von Java inspiriert hat.
Wirklich, es gibt keine vernünftige Alternative zu Cocoa für OS X-Entwicklung, es sei denn, Sie haben spezifische Bedürfnisse wie plattformübergreifend sein wollen.
Ich bin mir nicht sicher, was WPF ist, aber die meisten Entwicklung für die OSX-Plattform ist in Objective-C mit Cocoa getan. Sie können die veralteten Carbon APIs mit anderen Sprachen wie Java verwenden, aber neue Anwendungen für OSX sollten wirklich in Objective-C entwickelt werden. Sie können mit Apple's guide mit XCode als Ihre IDE beginnen.
Cocoa ist das primäre Framework für Mac OS X. Es ist das, was Apple verwendet, es ist das, was die meisten neuen Entwicklungen verwenden, und hier werden hauptsächlich neue Funktionen hinzugefügt.
Wenn Sie von WPF kommen, denke ich, dass Sie einige der Konzepte in Cocoa vertraut finden können. (Trotz der Tatsache, dass Cocoa nur ein bisschen älter ist.) Es wurde komplett um MVC herum gebaut, es gibt Benachrichtigungen und Bindungen zur Eigenschaftsänderung, es gibt Animation-Unterstützung, es gibt ein Persistenz- und Objekt-Graph-Management-Framework und so weiter.
(Auch möchten Sie vielleicht "mac", um die Tags hinzuzufügen.)
Abgesehen von Interface Builder, die als Teil der Xcode-Tools enthalten ist, können Sie auch QT, GTK +, AWT & SWING (für deinen Java-Hintergrund), Tk, Squeak (für deinen Smalltalk-Hintergrund), Schuhe (sehr cooles kleines Ruby-GUI-Toolkit), FXRuby (mehr Ruby), wxWidgets, XULRunner und andere, ich bin mir sicher, dass ich es vergessen habe. Für die meisten nativen Apps ist der Interface Builder jedoch die beste Wahl.
Mit Ihrem Java-Hintergrund, lassen Sie sich nicht von der jetzt veralteten Cocoa-Java-Bridge ablenken. Zu Beginn der OS X-Geschichte stellte Apple eine (mühsam in der Hand gehaltene) Java-Schnittstelle für die Cocoa-Bibliotheken bereit. Aufgrund der semantischen Unterschiede zwischen Java und Objective-C sind viele der leistungsstärksten Funktionen von Cocoa, einschließlich der Schlüssel-Wert-Bindung (auf der viele andere Features basieren), sehr schwierig, was zu einer Divergenz der Objetive-C- und Java-Fähigkeiten führt die eventuelle Abwertung der Brücke. Die gesamte Cocoa-Entwicklung erfolgt am besten mit Objective-C oder einer der vielen (automatisch generierten) Brücken zu dynamischen Sprachen wie Python oder Ruby.
Mit Ihrem Hintergrund in Smalltalk würde ich erwarten, dass Sie Objective-C in ein oder zwei Tagen aufheben könnten.
Um es anders auszudrücken als frühere Poster: Wenn Sie Ihre Schnittstelle nicht in InterfaceBuilder entwerfen und mit Objective-C manipulieren, dann werden Sie mit einer Anwendung enden, die nicht aussieht, fühlt, handelt, Oder arbeiten Sie so, wie es bei einer Macintosh-Anwendung der Fall ist. Es wird eine unangenehme Erfahrung für den Benutzer im Vergleich zu anderen Anwendungen sein, und sie werden wahrscheinlich eine andere Anwendung aufgrund davon wünschen.
Toolkits wie QT sind akzeptabel, wenn Ihre Anwendung bereits QT verwendet und Sie sie schnell portieren möchten, aber wenn Sie eine neue Anwendung (oder eine separate GUI) schreiben, schreiben Sie sie in Cocoa mit ObjC oder ObjC++.
Sie können einen Blick auf PyObjc werfen, die eine Brücke zwischen der Python-Programmiersprache und Objective-C ist, einschließlich Bindungen für Mac OS X-Komponenten, einschließlich Cocoa.
Mit einem Smalltalk-Hintergrund, würde ich gerade Cocoa und Objective-C empfehlen. Wenn Sie jedoch eine dynamische Sprache bevorzugen, können Sie mit RubyCocoa Ruby verwenden, was Sie leichter finden als Python.