Für mich war XCode immer sehr umständlich.

Um XCode 3 wird ja derzeit ein kleiner Hype betrieben. Ist es wirklich besser?
Kann ich wie in RealBasic einfach nur ein Button an sein Ziel ziehen und per doppelklick auf den Button dann die Befehle für diesen festlegen?

Oder ist die grosse Neuerung nur die Punkt-Notation in Obj-C 2.0?

Netter Chef

nein - es läuft nicht so wie bei RealBasic. Der Interface Builder funktioniert genau so wie bisher - und das ist auch gut so!

bin ich denn der einzige, der das umständlich findet, wie der Interface Builder funktioniert?

Was meinst Du denn genau?

das umständlichen ziehen der striche mit ctrl-klick von den controls zu den buttons.

Netter Chef

Der Interface Builder funktioniert genau so wie er sollte! Es kann sein, dass das Workflow nicht ganz perfekt ist, aber die Funktionsweise des IB hat mit Cocoa zu tun.
Nun weiß ich nicht genau wie es in RB funktioniert, aber die meisten Java Interface Builder Äquivalente generieren Code, der beim Start des Programms die UI Objekte erzeugt und einstellt.
Nicht so der IB: Dort erstellt der IB wenn du einen neuen Button in ein Fenster ziehst auch wirklich ein NSButton Objekt, fügt es dem contentView des NSWindow hinzu, usw. Wenn du das NIB file dann speicherst wird kein Code generiert, sondern den Objekten wird -encodeWithCoder: gesendet. Die Daten werden ins NIB geschrieben und beim Start des echten Programms werden die Objekte mit all ihren Eigenschaften dekodiert!

Das mag das Workflow stellenweise umständlich erscheinen lassen, doch es ist wirklich sehr elegant! Nur deswegen kann man die UIs aus IB heraus testen, ohne kompilieren zu müssen und nur deshalb kann man so leicht IB Paletten erstellen!

Haben die NSButtons irgendeine Eigenschaft, die einen Schnipsel Code enthält, der beim Klick ausgeführt wird?! Nein! Weil es absolut unlogisch ist und überhaupt nicht in den Model-View-Controller-Pattern passt! (Controller-Code im View)
Stattdessen haben NSButtons ein target und eine action. Das ist logisch und genau das setzt du beim Ziehen der Striche.

Wenn XCode so funktionieren würde wie RB, dann wäre der Punkt erreicht, an dem ich von XCode die Finger lasse. Für Sekretärinnen und andere RADler gibt es genug Zeug.

hmm, aber wenn ich etwas nachträglich an der gui des programms ändere ist das doch recht umständlich, oder?

bei realbasic kann ich mit suchen und ändern, z.b. alle buttons "hallo" auf "welt" in z.b. 25 fenstern ändern, danach mit suchen & ändern dann die befehle, die damit ausgelöst werden.

in interfacebuilder müsste ich doch bestimmt, alle 25 fenster per hand anpassen?

Wenn du 25 Fenstern Buttons ändern musst, dann spricht das nicht umbedingt für die gute Planung des Programms.:-y

RB scheint das Datenbank ähnlich zu machen. Erst alle Datensätze mit title=Hallo suchen und dann Operationen drauf anwenden.

So läuft das nicht in IB. Das sind echte Objekte. Das hat nichts damit zu tun, dass ein solches Feature nicht implementierbar sei, sondern es passt einfach nicht in die Philosophie des IB. Das ist kein Datensatz, der einen Button darstellt, das ist der Button!

Es ist schwer das zu beschreiben.

Aber der IB in Leopard wird doch einiges einfacher zu bedienen sein. Ich bin jedenfalls ganz gut damit zufrieden - so ein RealBasic Kram kommt mir nicht auf die Festplatte.

Netter "Chef"

Du hast XCode nicht mal ansatzweise begriffen.

@Rantan"plan": kann sein , daher warte ich ja auf ein xcode, dass dem realbasic, delphi, kylix, vb, etc. ähnlicher wird.

Netter "Chef"

Nein, nein, nein und nochmals nein! Wenn das was ich geschrieben habe zu subtil für dich ist, dann sag ichs mal deftiger: XCode ist ein Entwicklungssystem für professionelle Softwareentwickler, die zumindest meistens recht gut wissen was sie tun. RB, Delphi, Kylix sind hauptsächlich RAD-Tools zum Quick'n'dirty-Draufloshacken - da können auch Profis dran sitzen, aber auch eben Sekretärinnen. An VB sitzen sowieso nur Sekretärinnen und Schmalhirne. Wenn XCode diesen Mist-Systemen ähnlicher wird, verliere ich meinen Glauben an die Welt. Man darf sich doch nicht immer nur nach dem Bodensatz richten. Lerne mal ein gescheites System zu beherrschen und orientiere dich nicht immer an dem Bodensatz der Entwicklungswerkzeuge.

Lieber Rantan-"plan",

ich bin leider schon zu alt, um noch nächtelang mit Pizza und Cola mich in umständliches Guru-Programmdings einzudenken.

Was für mich zählt, ist das schnelle Ergebnis. Warum 100 Stunden opfern, wenns auch in 10 geht? Es muss auch bezahlbar bleiben.

Netter Chef<br>
Das ist ein Argument.

Netter Chef

Xcode ist nun halt kein RAD-tool. Wenn man sich auskennt, kann man sehr schnell und effizient halbwegs performante Applikationen in Cocoa/ObjC/Xcode erstellen. Wenn man nur Basic kann und auch keine lust/zeit hat sich in irgendwas reinzudenken, dann ist sicher RealBasic die bessere wahl.

Netter Chef<br>
Dann nutze weiter RealBasic und den anderen Klicki-Bunti-Kram. Du bist dann eh kein Kandidat für IB, Xcode und Obj-C Programmierung.

ich würde sagen wir stoppen an der stelle den thread, es artet langsam in geflame aus. schade.

Netter Chef

Vielleicht möchtest Du mal einen Blick auf "Revolution" werfen?
http://www.runrev.com

Das ist auch eins der von Ranti so nett und liebevoll verschmähten RAD-Tools , mit dem ich schon seit fast 8 Jahren professionell und erfolgreich arbeite, siehe auch meine Website z.B. unter "Freeware"...

Das käme Deinem Wunsch nach: "Was für mich zählt, ist das schnelle Ergebnis. Warum 100 Stunden opfern, wenns auch in 10 geht? Es muss auch bezahlbar bleiben." sehr nahe

Für Fragen dazu stehe ich immer gerne zur Verfügung.


Gruß

Klaus

MacRabbitPro<br>
Aua!

Heute kein Zugang zum Club der "Elitären Cocoa/ObjC/XCode-Hardcore-Programmierer"? Noch nicht mal als Gast? Das ist hart

Sonnigen Sonntag noch...


Gruß

Klaus

Klaus Major

...das Leben ist halt manchmal hart.

Dann schaue ich mich lieber mal bei Revolution um, da scheint die Welt noch in Ordnung und nicht versnobbt zu sein

Netter Chef

Nicht beleidigt sein! Wir sind nur nicht gut auf Leute zu sprechen, die sich Xcode als RAD-Tool wünschen. Jetzt ist ja klar, dass Xcode nicht das richtige für dich ist und nun ist gut. "Versnobben" will dich hier keiner!

Netter Chef:

es gibt Themen, die du in diesem Forum lieber gar nicht erwähnst...
du bekommst zu gewissen Themen jede Menge Einträge und Kommentare, aber hilfreiche Antworten sind sehr in der Unterzahl. Hauptsache jeder gibt seinen Senf dazu ab!

den Eindruck habe ich besondern von herrn "plan", die 21.000 einträge muss man ja irgendwie erreichen

Netter Chef

In der Tat gibt es einige hier im Forum von denen man das manches Mal denken könnte. Rantanplan zählt definitiv nicht da zu!

Seine Beiträge zeichnen sich eigentlich immer durch kompetente und sachdienliche Antworten aus. Er engagiert sich im Forum u.a. durch die Durchführung der Themenwochen und der Kleinanzeigenthreads und genießt unter fast allen Lesern hoches Ansehen!

Bevor du Rantanplan kritisierst, solltest du lieber mal bei dir selber gucken.

"Wenn du 25 Fenstern Buttons ändern musst, dann spricht das nicht umbedingt für die gute Planung des Programms."

Die Welt ist größer als Deutschland (sollte man meinen).

EXAKT dieses Problem (ändern von Button Labels, Dialogitems x Mal dieselben) bekommt man im Zuge der Mehrsprachigkeit.

Resistance Doingk... Das ist nicht Dein Ernst, oder...? Dafür gibt es die Lokalisierung. Also wer für weitere Sprachen im Programm rumfummeln muss, sollte bei Windows XP bleiben...

gaspode

der Interdace Builder basiert aber darauf, dass die Nib Files für weitere Sprachen dupliziert werden. Insofern muß du da für weitere Sprachen "im Programm rumfummeln".

Und ganz im Ernst: Wenn man eine Lokalisierung/Internationalisierung richtig machen will und möchte das die Applikation in JEDER Sprache gut aussieht und richtig Funktniert, kommt man nicht darum auch programmiertechnisch einzugreifen.

MacRabbitPro OK, insofern hast Du recht. Aber ich muss dafür keine Verbindungen neu legen oder anfassen.

Stimmt auch, dass man manchmal am Layout basteln muss, dass es für alle Sprachen passt. Ich hab schon für einige Programme die Lokalisierung übernommen, das hat dann aber der eigentliche GUI Entwickler übernommen, denn da soll nicht der Übersetzer reinpfuschen.

"Dafür gibt es die Lokalisierung. Also wer für weitere Sprachen im Programm rumfummeln muss, sollte bei Windows XP bleiben..."

hmpf - die übliche MTN inhaltsleere Kampfansage.

Lokalisierung ist nur auf dem Papier schön, denn mit dem IB hat man die Wahl zwischen 2 Szenarien:

1) komplett lokalisierung, daher ein alle Interfaces bis auf den master löschen und dann eine komplett durch übersetzen. Hier wird das Interface selber nicht verändert nur übersetzt (jedenfalls wenn der Übersetzer genug skill hat - darf generell bezweifelt werden, für die Übersetzung ist also Entwickler Knowhow zwingend erforderlich, da sonst evtl. wichtige Verbindungen zerstört oder (schlimmer) verändert werden. Bindings ist hier ein Weg in die richtige Richtung um die Logik noch besser vom Interface zu trennen)

2) man paßt die aktuellen Änderungen am Interface in allen Sprachen an, die man benötigt.
Huch?! Das ist ja genau das, was OP zu recht bemängelt hat.

Die Lokalisierung ist nur auf technischer Ebene in Cocoa perfekt (wenn alles lokalisiert ist), die Durchführung der Lokalisierung ist bestenfalls mangelhaft da entweder mit extremen Aufwand (ALLE Diaglogelemente müssen übersetzt werden) oder stupide und gefährlich (das selbe Dialogelement muß in allen Dialogelementen "eingefaßt" werden, mit Verbindungen und co)

Und bevor der nächste Schlaumeier kommt und meint:
"Das muß man durch nur am Ende machen." - ja, für kleinklecker Programm "Vokabeltrainer 9.1.5.2.1" ist das so, andere Programme möchte man doch schon vorher testen. Je nach Qualitätsanspruch auch mehrsprachig - und schon hat man oben beschriebenes Problem, besonders wenn Programm xyz mehr Dialoge als der durchschnittliche Vokabeltrainer hat.

"Hat jemand Jehova gesagt?"

XCode und Realbasic sind zwei völlig verschiedene Ansätze Software zu schreiben! Da ist es nicht hilfreich XCode als professioneller als Realbasic zu bezeichnen noch Realbasic als Umgebung für einfacheres Programmieren.

Man kann genauso effektiv in Realbasic programmieren wie in XCode. Das Problem liegt immer beim Wissen des Programmierers, was er daraus macht. Auch mit XCode kann ich Scheiße produzieren.

Abgesehen davon das XCode logischerweise Realbasic in der Unterstützung der OS-Funktionen immer voraus ist (ist ja schließlich vom Hersteller) und unter Realbasic fast jede Funktion per Plugin dazugekauft werden muß und Realsoftware es einfach nicht schafft weniger Funktionen dafür aber fehlerfrei(er) in Realbasic zu implementieren, gehen beide verschiedene Wege. Genauso wie es eine Daseinsberechtigung für andere Programmiersprachen gibt, so muß diese auch Realbasic zugestanden werden.

Seit doch mal ein wenig toleranter gegenüber anderen Meinungen.

XCode 3 leichter bedienbar,[...]
Etwas.

[...]ähnlich RealBasic?
Nein.

Für mich war XCode immer sehr umständlich.
Das mag für Dich wahrscheinlich daran liegen, dass es sich nicht wie Realbasic bedient. - Es hat auch nichts damit zu tun.

Um XCode 3 wird ja derzeit ein kleiner Hype betrieben. Ist es wirklich besser?
Ja. Keine Revolution, aber eine Evolution.

Kann ich wie in RealBasic einfach nur ein Button an sein Ziel ziehen und per doppelklick auf den Button dann die Befehle für diesen festlegen?
Zwangsläufig: Nein.
PS: Der Interface Builder ist nicht in Xcode.

Oder ist die grosse Neuerung nur die Punkt-Notation in Obj-C 2.0?
Die Punktnotation ist imho peripher. Obj-C 2.0 verfügt jetzt aber über ein teil-automatisches Thread-Management und eine optionale Garbage Collection. Und ein paar Nettigkeiten wie property accessors and fast enumeration.
PS: Obj-C ist nicht auch nicht Xcode.

Ich hätte vielleicht erst den Thread lesen sollen...


Die Bedienung der Dev Tools liegt an der Natur der Sache.

Im Prinzip hat jonny91 in seinen ersten beiden Postings bereits alles notwendige erkärt.

RetroAndy
[...]unter Realbasic fast jede Funktion per Plugin dazugekauft werden muß[...]
Kann man auch selbst machen, es gibt ein Xcode-Template für RB-PlugIns.

[...]Realsoftware es einfach nicht schafft weniger Funktionen, dafür aber fehlerfrei(er) in Realbasic zu implementieren[...]
Das ist imho der zentrale Punkt, weshalb es häufig nicht als "professionelle" Entwicklungsumgebung betrachtet wird.

iCode Klar, kann man sich das Plugin selber machen, aber es ist ja nicht Sinn einer Entwicklungsumgebung sich erst die grundlegenden Funktionen selber zu machen. Wer soll das bezahlen? Oder wer hat so viel Zeit?
Sinnvoller wäre z.B. die MBS-Plugins mit in RealBasic zu übernehmen. Dann hätte man mehr oder weniger einen schlanken Kern mit den erweiterungen, die man wirklich benötigt (so wie die Frameworks in XCode).

Ich würde Fehler nicht als Kriterium für professionell ansehen. Fehler können eher dazu führen, dass es System nicht alltagstauglich ist. XCode beinhaltet auch Fehler. Und man zieht ja keine Grenze bei z.B. 100 Fehlern.
Es sind meistens auch keine großen Dinge in Realbasic sondern Kleinigkeiten, die man schnell beheben könnte.