Xcode-Projecte mit Python realsieren (OSX)

[maccy]

Hallo zusammen,

ich bin auf der Suche nach Informationen zum Thema: "Xcode-Projekte mit Python realisieren".

Die Möglichkeiten von Xcode Ich möchte voll nutzen und Python "nur" als Sprache einstzen. Hinweise auf Python unterm Mac außerhalb von Xcode, sind durchaus willkomen, sollten jedoch nicht der ausschließliche Gegenstand dieses Threads sein.

Hinweis:

das Projekt muss eine .xcodeproj Datei einhalten, welche per Doppelklick direkt Xcode öffnet.


Speziell für Beispielprojekte in diese Richtung wären sehr interessant.

Viele Grüße

[sma]

Starte XCode. Schließe das Willkommensfenster.

Wähle "File|New Project...". Es öffnet sich ein Dialog "New Project". Wähle auf der rechten Seite unter "Mac OS X" die Rubrik "Application" aus. Wähle dann auf der linken Seite "Cocoa-Python Application" aus. Klicke "Choose...".

Gibt Namen "counter" ein. Where zeigt bei mir auf "Dokumente". Klicke "Save". Es öffnet sich der Project Explorer.

Doppelkicke "MainMenu.xib" im Project Explorer. Es startet der Interface Builder. Schließe "MainMenu".

Füge nun in "Window" ein Eingabefeld und zwei Knöpfe hinzu. Ändere die Titel der Knöpfe auf "+" und "-". Ändere den Inhalt des Eingabefelds auf "0". Das ganze könnte so aussehen:

Code: Alles auswählen

+------------------+
|      Window      |
+------------------+
|                  |
|  [    0] [+][-]  |
|                  |
+------------------+

Wähle im Fenster "MainMenu.xib (English)" den blauen Wüfel "counterAppDelegate" aus und drücke Shift+Cmd+I um den Inspector zu öffnen. Wähle im Inspector den Reiter mit dem "i" aus. Füge "add:" und "sub:" mit 2x Klicken auf "+" als Aktionen hinzu. Füge "counterField" mit 1x Klicken auf "+" als Outlet hinzu.

Wähle "File|Write Class Files...". Es öffnet sich ein Dialog "Save". Name sollte "counterAppDelegate" sein, Where sollte "counter" sein und bei Language muss Python ausgewählt sein. Da die Datei schon existiert, muss sie mit Klick auf "Replace" überschrieben werden.

Es entsteht dieser Quelltext:

Code: Alles auswählen

from Foundation import *
from AppKit import *
import objc
class todoAppDelegate (NSObject):
    counterField = objc.IBOutlet()

    @objc.IBAction
    def add_(self, sender):

    @objc.IBAction
    def sub_(self, sender):

Wähle im Inspector (counterAppDelegate muss immer noch ausgewählt sein) den Reiter mit dem Pfeil aus. Du siehst du dort gerade definierten Outlets und Actions. Klicke auf den kleinen Kreis neben "counterField", lasse die Maustaste gedrückt und ziehe die Linie auf das Eingabefeld. Klicke dann auf den Kreis neben add: und ziehe die Linie auf den (+)-Knopf. Mache dann das selbe für sub: und den (-)-Knopf.

Speichere das UI und beende den InterfaceBuilder.

Schreibe nun den Code für die beiden Methoden. Der InterfaceBuilder generiert leider fehlerhaften Code wo die Rümpfe fehlen. Da hätte man ja noch mal ein "pass" spendieren können...

Code: Alles auswählen

    def add_(self, sender):
        self.counterField.setIntValue_(self.counterField.intValue() + 1)
    
    def sub_(self, sender):
		self.counterField.setIntValue_(self.counterField.intValue() - 1)

Klicke "Build and Go". Das eigene Fenster sollte sich öffnen, die Knöpfe sollten funktionieren.

ACHTUNG: Ich musste eben recht lange basteln, weil XCode darauf bestanden hat, Python 2.6.2 zu benutzen, was bei mir keinen Support für ObjC hat. Warum, das weiß ich nicht. Ich habe schließlich unter "Targets>counter", "Get Info" im Reiter "Build" in der Kategorie "Linking" unter "Other Linker Flags" ein "-lpython" eingegeben. Ich verstehe ehrlich gesagt aber nicht, warum die 2.6.2er-Version überhaupt aufgepickt wird.

Stefan

[maccy]

Vielen Dank für die ausführliche antwort.

Zitat:

"Wähle "File|Write Class Files...". Es öffnet sich ein Dialog "Save". Name sollte "counterAppDelegate" sein, Where sollte "counter" sein und bei Language muss Python ausgewählt sein. Da die Datei schon existiert, muss sie mit Klick auf "Replace" überschrieben werden."

Xcode / File / NewFile / unter Mac OSX cocoa oder Pure Python ?

wenn "Mac OSX cocoa" (wovon ich ausgehe, dann sicher Python NSObject subclass" oder etwa nicht?, hatte leider noch nicht die Möglichkeit die Sache komplett durch zugehen. grad kein Mac mit Xcode zur Hand)



entschuldige die späte Rückmeldung, muss noch arbeiten.

[Darii]

Xcode / File / NewFile / unter Mac OSX cocoa oder Pure Python ?

wenn "Mac OSX cocoa" (wovon ich ausgehe, dann sicher Python NSObject subclass" oder etwa nicht?, hatte leider noch nicht die Möglichkeit die Sache komplett durch zugehen. grad kein Mac mit Xcode zur Hand)

Dein Post war echt schwer zu verstehen, musste den dreimal lesen und kann trotzdem nur vermuten was du willst. Ich gehe davon aus du willst irgendwie eine neue Python-Datei erstellen, die Antwort auf deine Frage ist: Was willst du mit dieser Datei machen? Wozu brauchst du sie? Im Endeffekt bewirkt ändert diese Auswahl nur das Template nach der die Datei erstellt wird, das kannst du nachher alles noch umändern.

[maccy]

Nachtrag: Es gab ein erhebliches Missverständnis bei der Bedinenung. Write Class File / im InterfaceBuilder auswählen und nicht in Xcode. bin an dem wirrar leider nicht ganz unschuldig. wie es dazu kam hier:


meine Ausdrucksweise war sicherlich alles andere als optimal!

liegt darin begründet, dass ich persönlich noch nicht die möglichkeit hatte, mit Xcode die Sache selbst auszuprobieren.

habe versucht (mit geringem Erfolg, wie man sieht) einen Bekannten per Telefon dort durchzuführen. Der teilte mir mit, das die das "mit der neuen Datei" für Ihn nicht so klar ist. unter dem Filemenü in Xcode gibt es wohl mehrere Optionen.

sobald ich zuhause bin, werd ich mir das selbst anschauen.

kennst du eventuell einen Link der sich mit Python in Xcode befasst? wäre sehr hilfreich.

viele Grüße

[maccy]

Frage zur Bedienung des Editors: Wie gebe ich ein Code Tag korrekt ein? code markieren und und auf Highlighted Code???

ok habe das Beispiel jetzt selbstständig nachvollzogen.

counterAppdelegate.py:

Code: Alles auswählen

from Foundation import *
from AppKit import *
import objc
class counterAppDelegate (NSObject):
    counterField = objc.IBOutlet()
 
   @objc.IBAction
   def add_(self, sender):
       self.counterField.setIntValue_(self.counterField.intValue() + 1)

    @objc.IBAction
    def sub_(self, sender):
        self.counterField.setIntValue_(self.counterField.intValue() - 1)

der Debugger bricht allerdings den Startvorgang ab.

Was mache ich falsch?

Edit (Leonidas): BBCode aktiviert.

[Darii]

Frage zur Bedienung des Editors: Wie gebe ich ein Code Tag korrekt ein? code markieren und und auf Highlighted Code???

Hast du vielleicht den BBCode deaktiviert?

der Debugger bricht allerdings den Startvorgang ab.

Der der große Nachteil von Python in xcode ist, dass man das ganze nicht vernünftig debuggen kann.

Geh mal auf Run->Console, da taucht dann evtl. eine Python-Fehlermeldung auf.

An der Stelle vielleicht ein kleines Tutorial zum Thema Cocoa Bindings mit Python(falls das Beispiel vorher funktioniert). Füge der Klasse eine neue Variable hinzu. Und ändere die Methoden wie folgt ab.

Code: Alles auswählen

class counterAppDelegate(NSObject):
    counter = 0

    @objc.IBAction 
    def add_(self, sender):
        # Seltsamerweise geht es bei mir auch ohne ._. das ist aber nicht
        # dokumentiert
        self._.counter += 1

    @objc.IBAction 
    def sub_(self, sender):
        self._.counter -= 1

Dann klicke im Interface Builder das Eingabefeld an und klicke im Inspektor auf Bindings (grünes Symbol). Unter Value „Bind to“ anklicken und im Dropdown counterAppDelegate auswählen. Bei „Model Key Path“ „counter“ eingeben. Knöpfe sollten immer noch funktionieren.

[maccy]

vielen Dank

console sagte Line 7 => Grund Zeile musste eingerückt werden. Anwedung läuft jetzt. "Nicht debuggen in Xcode nicht möglich" hört sich nicht so toll an. gibt es eventuell möglichkeiten, das ausserhalb von Xcode zu machen und um den fertigen code dann zu importieren?

stellt sich allerdings die Frage, ob die IBActions (XIB) dann korrekt angesprochen werden.

wenn ich das also recht verstehe, ist "Xcode für Python" nicht die erste Wahl, um auf dem mac Programme mit Python zu schreiben. gibt es dort Alternativen, die ebenso mit den Interface Builder zusammen arbeiten? Ohne Debugger wär´ja nich so heiß.

Code test

Code: Alles auswählen

test

BBCode das war´s gewesen!

kurz noch gefragt: in objective c kann man alles zwischen /* .... und .... */ auskommentierten. wie macht man das bei Python?



PS: Bindings Beispiel funktioniert. wo finde ich mehr davon? besonders Interesse hätte ich an Core Animation Geschichten unter Python. wahrscheinlich jedoch, wird das etwas zu speziell sein. gibt es eventuell eine Möglichkeit, an Xcode oder andere Python-Beispielprojekte zu kommen? auch literatur oder ähnliches in diese würde mich interessieren. Ich weis, gabz schön viel auf einmal. aber was willste machen.

Vielen Dank im voraus

[Darii]

gibt es eventuell möglichkeiten, das ausserhalb von Xcode zu machen und um den fertigen code dann zu importieren?

Sicherlich, du musst die Anwendung halt „zu Fuß“ starten, sprich guck dir an, was die main.m macht und setz’ das in Python um. Dazu muss man allerdings wissen, wie unter OSX Programme gestartet werden -> Apple Doku.

wenn ich das also recht verstehe, ist "Xcode für Python" nicht die erste Wahl, um auf dem mac Programme mit Python zu schreiben. gibt es dort Alternativen, die ebenso mit den Interface Builder zusammen arbeiten? Ohne Debugger wär´ja nich so heiß.

Die erste Wahl, auf dem Mac Programme zu schreiben, ist nunmal Objective C.

kurz noch gefragt: in objective c kann man alles zwischen /* .... und .... */ auskommentierten. wie macht man das bei Python?

Gar nicht, nur Zeilenweise per #.

PS: Bindings Beispiel funktioniert. wo finde ich mehr davon? besonders Interesse hätte ich an Core Animation Geschichten unter Python. wahrscheinlich jedoch, wird das etwas zu speziell sein. gibt es eventuell eine Möglichkeit, an Xcode oder andere Python-Beispielprojekte zu kommen? auch literatur oder ähnliches in diese würde mich interessieren. Ich weis, gabz schön viel auf einmal. aber was willste machen.

Am besten auf der pyobjc-Seite stöbern, am ergiebigsten sind da zur Zeit die News. Ansonsten musst du einfach die normale Core-Animation Doku von Apple lesen, bei Python sollte es da nichts großartiges zu beachten geben.

[sma]

Ein paar Anmerkungen: Erste Wahl auf dem Mac ist IMHO bzw. wird sein MacRuby ;) Danach kommt lange Zeit nichts und dann Objective-C, was ich doch recht altbacken finde. Und dann wieder lange nichts und dann Python. Jscocoa klingt noch ganz interessant und man munkelt, ab 10.7 soll man auch mit AppleScript Cocoa-Anwendungen bauen können - wem's gefällt....

Debuggen von Python-Code geht nicht (allerdings auch nicht mit MacRuby) und die Namen der Methoden sind extrem hässlich (das ist bei MacRuby und Jscocoa besser). Hinzu kommt, dass es irgendwie Versionsprobleme mit 2.5.1 und 2.6.2 gibt. Außerdem ist der ganze Kram schlecht dokumentiert und ich habe das Gefühl, es gibt nur eine Handvoll Leute weltweit, die versuchen, mit Python Cocoa-Anwendungen zu schreiben.

Das ursprüngliche Problem, die counterAppDelegate-Datei zu generieren, hat sich ja wohl gelöst. Eine neue Datei musste man nicht anlegen.

Natürlich könnte man den Mac-Standardeditor Textmate benutzen, um sein Programm zu schreiben, doch arbeitet man quasi blind, denn man braucht letztlich wenigstens einmal XCode, um den kleinen Objective-C-Teil, der das Python startet zu übersetzen. Hier wären ein paar kleine Tools (wie es sie für MacRuby + Hotcocoa oder auch schon für RubyCococa gibt) hilfreich. Auch für eine fertige Anwendung (py2app) muss man wieder etwas manuell tun, was eigentlich IMHO alles automatisch gehen sollte.

Ich würde PyObjC nicht empfehlen.

Stefan

[Darii]

und die Namen der Methoden sind extrem hässlich (das ist bei MacRuby und Jscocoa besser).

Ich weiß nicht, ich habe lieber häßliche Methodennamen als eine verunstaltete Syntax. Ein ``dict.setObject(o, forKey:k)`` ist nichts Ganzes und nichts Halbes. Da wird bei naiver (und auch bei gründlicherer) Betrachtung die Methode setObject: aufgerufen, aber nicht setObject:forKey:. Dann lieber F-Script. Vielleicht wird ja auch LanguageKit mal was.

[sma]

Definitiv ist MacRuby nicht optional, aber man vergleiche:

Code: Alles auswählen

view.dragImage image, at: [10,20], offset: [0,0], event: event, pasteboard: pasteboard, source: source, slideBack: true

view.dragImage_at_offset_event_pasteboard_source_slideBack_(image, (10, 20), (0, 0), event, pasteboard, source, True)

Schön bei MacRuby wäre, wenn man auch hinter dem Methodennamen selbst noch ein ":" setzen könnte. Das wäre einheitlich und sollte eigentlich die Ruby-Grammatik nicht weiter ändern. Bei dem Python-Beispiel bin ich jedenfalls total durcheinander gekommen, was nun wo stehen muss und es ist schwer zu sehen, ob man schon alle Parameter hat.

F-Script als Smalltalk-Derivat ist natürlich nett, aber das dümpelt schon seit Jahren als Dauerbeta so vor sich hin und hat gefühlt noch mal eine Größenordnung weniger Anwender als PyObjC. Étoilé dümpelt doch auch seit Jahren, oder? Ich meine dem Projekt schon mal vor Jahren zusammen mit Self und Io begegnet zu sein.

Ein weiterer wichtiger Unterschied zwischen MacRuby und PyObjC (und RubyCocoa) ist, dass ersteres komplett auf der Objective-C-Runtime inklusive Objective-C-GC aufsetzt und keine Bridge-Lösung ist, die laut Aussagen von Ruby-Leuten eher langsam, brüchtig und umständlich ist.

Somit wäre ein MacPython, welches ebenfalls auf der Objective-C-Runtime fußt, eine interessante Alternative. Allerdings ist Ruby näher als Objective-C und Smalltalk dran als Python. Daher könnte es hier etwas schwieriger werden. In jeden Fall sollte man auch hier die Syntax anpassen, z.B.

Code: Alles auswählen

class MyDict(NSObject):
    def [at: key]:
        ...
    def [at: key put: value]:
        ...
    def [keysAndValuesDo: aBlock]:
        ...

d = MyDict()
d.at: 1 put: (d.at: 1)

Auf den ersten Blick würde ich sagen, dass das nicht zu Mehrdeutigkeiten in der Python-Grammatik führt. Die [] in einem "def" sind problemlos möglich. Wer ein explizites "self" haben will, kann ja auch `[self at: key]` als Pattern benutzen. Für die Methodenaufrufe a la Objective-C könnte man entweder `[d at: 1 put: 2]` benutzen, denn der Leerschritt zwischen "self" und "at:" zeigt, dass das kein Listen-Literal sein kann oder aber ohne Klammern wie oben gezeigt. Problem wäre hier ein `d.size`, dem man Klammern verpassen müsste, weil bei Python ja sonst das Methodenobjekt selbst wäre und kein Aufruf.

Stefan

[Darii]

Étoilé dümpelt doch auch seit Jahren, oder? Ich meine dem Projekt schon mal vor Jahren zusammen mit Self und Io begegnet zu sein.

Ich hatte eigentlich vom Lesen des Blogs her den Eindruck, dass die zur Zeit recht aktiv sind.

In jeden Fall sollte man auch hier die Syntax anpassen, z.B.

Code: Alles auswählen

d = MyDict()
d.at: 1 put: (d.at: 1)

Warum nicht einfach gleich

Code: Alles auswählen

d = MyDict()
a at: 1 put: (a at: 1)

Das sollte eigentlich keine Probleme geben.

Aber grundsätzlich bin ich dem Anpassen der Syntax eher negativ gegenüber eingestellt. Entweder ich nehme eine Sprache so wie sie ist oder ich überlege mir gleich etwas neues. Dass dein Beispiel so unübersichtlich ist, liegt aber auch am Methodennahmen.

Code: Alles auswählen

view.dragImage image, at: [10,20], offset: [0,0], event: event, pasteboard: pasteboard, source: source, slideBack: true 

ist auch nicht gerade übersichtlich.[/code]

[sma]

Warum nicht einfach gleich

Code: Alles auswählen

d = MyDict()
a at: 1 put: (a at: 1)

Das sollte eigentlich keine Probleme geben.

Ja, das könnte besser sein. Doch versteht man jetzt den subtilen Unterschied zwischen "a size" und "a.size"?

Aber grundsätzlich bin ich dem Anpassen der Syntax eher negativ gegenüber eingestellt. Entweder ich nehme eine Sprache so wie sie ist oder ich überlege mir gleich etwas neues.

Eine existierende Sprache bringt im Idealfall eine Community mit. Die eigene Sprache hat vielleicht nur dich als Anwender und ist außerdem auch gewaltiges Stück Arbeit.

Dass dein Beispiel so unübersichtlich ist, liegt aber auch am Methodennahmen.

Der aber nun nicht so ungewöhnlich ist, auch wenn ich natürlich den längsten von NSWindow rausgesucht habe, den ich finden konnte. Typischerweise haben Nachrichten meist 0-3 Argumente.

Stefan