GUI für OSX ohne ObjC?

[jefferson__]

Hallo ihr!

Für Java kann ich das Buch Java für Mac OS X empfehlen, es geht recht gut auf die Spezialitäten ein, die man beachten muss, wenn ein Java-Programm dann auch Mac-nativ aussehen soll, wie z.B. die Menüleiste usw. Mir hat es recht gut gefallen, habe aber pratisch noch kein wirkliches Projekt gebaut.

An den Threadersteller: Woher hast du die Info: "Nach 10.4 soll laut Apple ja auch noch der Java-Support für Cocoa eingestellt werden."? Würde mich mal wirklich brennen interessieren. Hoffentlich verwechsel ich da nicht was. Cocoa ist doch das "neue" Zeug?

Meine Meinung: Ich denke Java wird immer mehr auf den Macs in nächster Zeit, da ja dann auf die Universal Binaries verzicht werden kann, bzw. nur noch sehr wenige Teile "nativ und universal" compiliert werden müssen.

 

[wegus]

Der Sinn von Java ist doch Portabilität? Was also soll eine native Java-Implementierung bringen? Das hat sich mir noch nie erschlossen.

 

[jefferson__]

Der Sinn von Java ist doch Portabilität? Was also soll eine native Java-Implementierung bringen? Das hat sich mir noch nie erschlossen.

Na ja, es macht Sinn Teile eines Javaprogramms nativ zu halten, wenn es beispielsweise sehr zeitkritisch ist. Ich denke da hauptsächlich an die Nutzung von Core Image direkt oder so etwas, wenn man das braucht. Sauber gekapselt steht dann auch nix dagegen trotzdem portabel zu sein.

So richtig überzeugt hat mich das Konzept auch nie mit dem nativ Teil, aber gemacht wird es ja trotzdem recht fleißig. Beispiele wären z.B. Together (UML Tool mit VIEL Zeug Außenrum ) oder eben auch Eclpise, das sich so einfach auf den Intel-Macs nicht übersetzen lässt, bzw. gar nicht starten ließ ohne Modifikationen und anschließendem "Neubau".

 

[klausel]

Mindestens für Cocoa-Bücher gilt:
Es gibt zwei Arten: Die Guten und die Deutschen.

Von jemanden, der in einem C++ Buch dem Leser rät, C++-Sprachmerkmale den C-Sprachmerkmalen vorzuziehen, da diese "zuverlässiger" sind, habe ich auch keine differenzierte Kritik erwartet.

 

[klausel]

(Nein, das ist für PROGRAMMIEREINSTEIGER und nicht für SYSTEMADMINISTRATIONEN - und ja, es schadet doch, denn es verwirrt)

Da muss ich Dich korrigieren: Das Buch wendet sich nicht an Programmiereinsteiger, sondern an Einsteiger mit Programmiererfahrung, die Objc und Cocoa programmieren möchten.

quasi jedes Beispiel setzt auf mindestens 2 Beispiele davor auf - ich kann nicht einfach mal querlesen, sondern muss es nach der vorgegebenen Reihenfolge machen

Das stimmt definitiv nicht. Reden wir vom gleichen Buch?

die ersten Seiten sind quasi aus dem MacOS Handbuch kopiert

Mit solchen Äusserungen solltest Du besser vorsichtig sein.

 

[equalitynow]

Warum nicht python verwenden, mit der objc-bridge?

wunderschöne programmiersprache und erlaubt super zugriff auf objc-libraries.

näheres unter: http://pyobjc.sourceforge.net/

 

[-Nuke-]

An den Threadersteller: Woher hast du die Info: "Nach 10.4 soll laut Apple ja auch noch der Java-Support für Cocoa eingestellt werden."? Würde mich mal wirklich brennen interessieren. Hoffentlich verwechsel ich da nicht was. Cocoa ist doch das "neue" Zeug?

Guck in die Doku von Apple zu Java->Cocoa Bridge. Unter 10.4 ist es das letzte Release. Die Entwicklung dieser Bridge wird eingestellt.

Sie ist kompliziert, teuer und kaum einer benutzt sie.

Es gibt aber auch noch andere Java->Cocoa Bridges. Musst mal suchen...

 

[wegus]

oder eben auch Eclpise, das sich so einfach auf den Intel-Macs nicht übersetzen lässt, bzw. gar nicht starten ließ ohne Modifikationen und anschließendem "Neubau".

und eben da sehe ich den Sinn von Java untergraben!

 

[jefferson__]

und eben da sehe ich den Sinn von Java untergraben!

Sind wir sicher einer Meinung, doch leider sieht die Realität anders aus. Das hat was mit einer Klassenbibliothek zu tun, die für die Oberfläche verantwortlich ist (so habe ich das zumindest irgendwie verstanden ). Also an dem Punkt wird Java wohl immer "unrein" bleiben.

 

[Relampago]

Ich hatte auch nir Lust Objective-C zu lernen

Aber ein Fensterchen zu ertsellen ist ja erstmal kein Ding, da musst du nichtmal Objective-C können. Den Rest kannst du auch in C/C++ machen.

Kurzes Pseude Beispiel mit Win32 Style:

1. Applikation erstellen (Cocoa/Objective-C)
2. OnPaint überschrieben , wie das unter Cocoa ist, schaust du Bitte selber nach
3. Mit dem Pointerchen auf den Grafikkontext (CDC, HDC), wie das unter Cocoa ist, schaust du Bitte selber nach , kannst du dann ganz wie mit C/C++ arbeiten (CoreGraphics, .... )

Versteht jetzt wahrscheinlich eh keiner was ich sagen will....

Andi

 

[Sym]

Ich würde C++ in Verbindung mit Qt empfehlen. Das Framework ist von der Leichtigkeit her ungefähr mit Swing gleichzusetzen.

@wegus:
Java hat seine Berechtigung. Es handelt sich um eine leistungsstarke Hochsprache, die einfach zu bedienen ist.

Das es mit Eclipse Probleme gab (oder gibt) liegt nicht direkt an Java, sondern an SWT, welches auf C++ aufsetzt. Daher werden auch UBs benötigt.

Und plattformunabhängig bedeutet nicht, dass man nicht systemspezifische Routinen nutzen kann. Man muss halt entsprechend kapseln.

 

[wegus]

ch würde C++ in Verbindung mit Qt empfehlen. Das Framework ist von der Leichtigkeit her ungefähr mit Swing gleichzusetzen.

@wegus:
Java hat seine Berechtigung. Es handelt sich um eine leistungsstarke Hochsprache, die einfach zu bedienen ist.

Das es mit Eclipse Probleme gab (oder gibt) liegt nicht direkt an Java, sondern an SWT, welches auf C++ aufsetzt. Daher werden auch UBs benötigt.

Und plattformunabhängig bedeutet nicht, dass man nicht systemspezifische Routinen nutzen kann. Man muss halt entsprechend kapseln.

nimm Swing, dann gehts schon
ich seh halt den Sinn von Java in der Plattformunabhängigkeit. Mir ist klar, daß das Grenzen hat. Diese sollten aber soweit als möglich weg sein. SWT schafft eben eine Plattformabhängigkeit. Das man Swing auch performant nutzen kann zeigt z.B. netbeans - nicht in dem Sinne das man die IDE nehmen soll, sondern das damit performanter Code erzeugt werden kann!

 

[Sym]

nimm Swing, dann gehts schon
ich seh halt den Sinn von Java in der Plattformunabhängigkeit. Mir ist klar, daß das Grenzen hat. Diese sollten aber soweit als möglich weg sein. SWT schafft eben eine Plattformabhängigkeit. Das man Swing auch performant nutzen kann zeigt z.B. netbeans - nicht in dem Sinne das man die IDE nehmen soll, sondern das damit performanter Code erzeugt werden kann!

Das ist mir klar. Allerdings haben die Probleme mit Eclipse und den neuen Macs halt nichts mit Java zu tun. Deshalb mein Kommentar.

 

[wegus]

Das ist mir klar. Allerdings haben die Probleme mit Eclipse und den neuen Macs halt nichts mit Java zu tun. Deshalb mein Kommentar.

das hätt ich auch so nie behaupten wollen!