Ja, ich sehr wahrscheinlich bald.

Also ich mache ab und an noch Qt... also bei Fragen

Ich mache kein Qt und werde er auch nie machen..

Chris

Niemals nie sagen So doof ist Qt ja nun auch wieder nicht...

Ich sag's mal so. Aus sicht eines Mac-Programmierers ist Qt ein Krampf und nicht wirklich "toll".

Aber wenn man von Windows/Linux kommt ist Qt eines der besten Libraries die man kriegen kann.

Original von Objcler
Niemals nie sagen So doof ist Qt ja nun auch wieder nicht...

Doch. Genau so doof ist Qt.

Aber ich wolle diese Section ja gar nicht lesen ...

Alex

Original von Objcler
Niemals nie sagen So doof ist Qt ja nun auch wieder nicht...

Wenn man mich dazu zwingt, mit viel viel Geld, werde ich natürlich alle meine Prinzipien über den Haufen werfen
Aber wenn es sich vermeiden lässt....

Chris

Hier sind meine Probleme mit Qt, in keiner speziellen Reihenfolge:

- Qt ist der kleinste gemeinsame Nenner. Wenn man irgendwelche Spezialsachen machen will (Beispiel: Schreiben auf CD) ist man dann ohnehin wieder auf platformabhängigen Code angewiesen

- Das Interface stimmt auf dem Mac nicht: Hier gibt es einen Menubar, und nicht einen pro Fenster. Damit das alles wieder stimmig wird, muss ich auch hier wieder Platformspezifisch arbeiten.

- Das Lizenzmodell stimmt für professionelle Coder wie mich nicht, es sei denn man macht sehr viel mehr mit Qt. Aber ich kann einer Firma ja nur guten Gewissens meinen Code geben, wenn ich sie darauf hinweise, dass sie auch eine Qt Professional Version (oder so) kaufen müssen. Das mögen viele Firmen nicht.

- Wie man auch bei Fragen hier im Forum gesehen hat, scheint die Umstellung auf Intel nicht ganz so einfach zu sein.

- Qt Programme schleppen schonmal so 20 MB an Frameworks mit sich rum. Bei grossen Sachen sicher kein Ding, aber für kleine Sachen finde ich das unakzeptabel

Hab ich noch was vergessen?

Wenn man als Zielgruppe echte Mac-User im Auge hat denke ich, dass die Nachteile klar überwiegen.

Alex

- Qt ist der kleinste gemeinsame Nenner. Wenn man irgendwelche Spezialsachen machen will (Beispiel: Schreiben auf CD) ist man dann ohnehin wieder auf platformabhängigen Code angewiesen

Ja sicher. Aber das macht Qt doch nicht automatisch schlecht. Es gibt Programmierer, die sich mit dem kleinsten gemeinsamen Nenner gut anfreunden können. Es sind doch viele Fälle bekannt, bei denen es Sinn macht etwas platformunabhängig zu implementieren.

Außerdem gab es mal Ansätze mit der QDS lib (Qt Desktop Service Library) platformabhängige Dinge (brennen, standardbrowser öffnen) für den Programmierer platformunabhängig zu lösen - mittels plugins für jede Desktopumgebung. Ich fand den Ansatz damals sehr interessant. Es wurde auch eine Version veröffentlicht. Aber der Entwickler hat glaube ich das Projekt eingestellt. Geben wir Trolltech einfach noch ein wenig zeit.

- Das Interface stimmt auf dem Mac nicht: Hier gibt es einen Menubar, und nicht einen pro Fenster. Damit das alles wieder stimmig wird, muss ich auch hier wieder Platformspezifisch arbeiten.

Jede Qt/Mac Anwendung hat standardmäsig so wie jede Cocoaanwendung auch eine Menubar. Aber richtig: Hier und da stimmt das "interface" nicht. Aber es wird ja immer besser. Neuerdings kann Qt sogar mit Sheets und Drawer umgehen...

Qt zeichnet halt alles selbst... vorteil: wenig platformabhängiger Code in Qt selbst - dafür viel Arbeit alles so zu treffen, wie es die jeweilige Platform vorsieht.

- Das Lizenzmodell stimmt für professionelle Coder wie mich nicht, es sei denn man macht sehr viel mehr mit Qt. Aber ich kann einer Firma ja nur guten Gewissens meinen Code geben, wenn ich sie darauf hinweise, dass sie auch eine Qt Professional Version (oder so) kaufen müssen. Das mögen viele Firmen nicht.

Es gibt unendlich viele Developertools, die was kosten. Trolltech ist eine Firma, die viel Geld in Qt steckt - verständlich, dass Trolltech auch was verdienen will. Immerhin ist Trolltech mittlerweile ein an der Börse gehandeltes Unternehmen...

- Wie man auch bei Fragen hier im Forum gesehen hat, scheint die Umstellung auf Intel nicht ganz so einfach zu sein.

Ich habe Qt ohne Probleme kompilieren können. Auch Universal Binaries kann man recht einfach mit Qt erzeugen...

- Qt Programme schleppen schonmal so 20 MB an Frameworks mit sich rum. Bei grossen Sachen sicher kein Ding, aber für kleine Sachen finde ich das unakzeptabel

Qt ist seit 4.0 aufgeplittet in mehrere kleine Frameworks. QtCore ist beispielsweise nur 1.5 mb groß...

Hab ich noch was vergessen?

Hoffentlich nicht

Wenn man als Zielgruppe echte Mac-User im Auge hat denke ich, dass die Nachteile klar überwiegen.

Ja klar... das ist ja auch der Grund, wieso ich Cocoa lerne... Mit Cocoa kann ich endlich mal all das, was ich mit Qt nicht so einfach konnte tun... das ist eine enorme Befreiung. Auch das deployen von Anwendungen ist mit xCode/Cocoa total simpel im Vergleich zu dem Deploymentmechanismus in Qt.

Original von freeskydiverAlso sagst Du damit mit Qt lässt sich etwas schwer implementieren?
Was meinst Du da z.B. im speziellen? Nur so aus Interesse

Ich meine damit nur was ich gesagt habe.

Qt hat auf Windows und Linux ein natives Look&Feel (unter Windows weil es halt meist dafür gemacht ist, und unter Linux wegen KDE) und ist im Gegensatz zu WinAPI/MFC und X11/GTK viel leichter zu programmieren.

Unter Mac hat es keines davon. 1) ist Cocoa leichter zu programmieren und 2) sehen Qt-Programme unter OS X recht scheiße aus.

Original von -Nuke-
2) sehen Qt-Programme unter OS X recht scheiße aus.

genau wie java-programme

Original von hanswurstgenau wie java-programme

Jups. Unter OS X sehen nur Carbon und Cocoa Programme "gut" aus.

Alles andere sind Windows-Oberflächen mit OS X "Grafik".

Oh das ist aber einer am Halbwahrheiten verbreiten. Ich hab ein paar Fragen:
- Gibt es in Cocoa eine API, um CDs zu schreiben?
- Woher kommen die 20 MB? Ich hab hier eine Anwendung, die ist im Diskimage komprimiert 2.8 MB, entpackt unter 6 MB. Dabei werden so einige Qt-Module benutzt.
- Wir hatten gerade das Problem, dass ein Kunde gerne einen roten Knopf haben wollte. Wie implementiere ich sowas mit Cocoa? Idealerweise würde ich ja nur das blau gegen Rot tauschen und das Shading macht Aqua.
- In welcher Qt-Version war die Aquabar plattformspezifisch zu implementieren?
- Was ist denn an dem Deployment mit Qt schwierig?

Original von axeljaeger
Oh das ist aber einer am Halbwahrheiten verbreiten. Ich hab ein paar Fragen:

Da ich den Eindruck habe, es handelt sich um rethorische Fragen sehe ich von einer Antwort ab.

Alex

Da die Fragen als rethorische Fragen interpretiert wurden, gehe ich davon aus, dass mir niemand wiedersprechen, bzw. mich "eines besseren" belehren möchte. Das ist auf der einen Seite vernünftig, auf der anderen Seite für den Zuschauer aber etwas langweilig.

Besonders diejenigen, die vorhin wild mit Zahlen um sich geworfen haben, würde ich aber doch zumindest bitten, Behauptungen in Zukunft mit Quellen zu belegen.

Die interessanteste Aussage in dem Thread ist aber meiner Meinung nach:



Im Punkt mit Windows gebe ich dir recht, auch mti X11/GTK. ABER:

Viele werden dir beim zweiten Punkt nicht recht geben. Zumal X11 eher equivalent mit einer niedrigeren GUI-Schicht, unter Windows würde ich GDI sagen, ist. Das Mac-Gegenstück wäre wohl Quartz. GTK ist auf X11 genauso aufgepfropft wie Qt, es ist kein Stück "nativer" als Qt. Besonders interessant ist, dass Gtk seit der letzten Version auch ein Quartzbackend gibt.

Das heißt auf der einen Seite, dass man mittelfristig für Gimp und Inkscape wohl kein X11 mehr braucht, auf der anderen Seite aber auch kleinere bis mittlere GTK-Anwendung auf den mac überschwappen.

Bei Gimp und Inkscape sehe ich X11 im Moment als notwendiges Übel an. Wenn GTK aber erstmal nativ großflächiger eingesetzt wird, ist die Hürde GTK für Mac einzusetzen, bzw. halbherzige Ports rauszufeuern, viel größer.

Original von axeljaeger
gehe ich davon aus, dass mir niemand wiedersprechen

OK, OK, you got me.

Also, natürlich gibt es auf dem Mac ein gut dokumentiertes und funktionierendes CD Recording Framework. Auf Windows auch, das ist leider sehr viel schlechter Dokumentiert und insgesamt eine ziemliche Schinderei.
Qt nimmt einem da keine Arbeit ab. Das gleiche gilt für sehr viele andere Bereiche.

Die 20 MB hängen natürlich ganz davon ab, welche Qt Module Du verwendest. Mein Beispiel ist der last.fm Player.

Das der Aquabar platformspezifisch implementiert werden muss hab ich nie behauptet. Allerdings gibt es Qt Programme, die pro Fenster einen Menubar haben. Das sieht auf dem Mac sehr merkwürdig aus, wenn sich beim Wechsel von einem in das andere Fenster fast der gesamte Menubar verändert.

Aber was genau willst Du von mir hören? Ohhhh, ich bin soooo doof, weil ich die Superdupervorteile von Qt nicht sehe?
Klar, es gibt Anwendungsbereiche. Aber ich habe - schlechte - Erfahrungen mit Qt gemacht, und seitdem keine Anwendung in meiner Arbeit dafür gefunden.

Alex

das QT forum ist echt interessant

Original von below
Also, natürlich gibt es auf dem Mac ein gut dokumentiertes und funktionierendes CD Recording Framework. Auf Windows auch, das ist leider sehr viel schlechter Dokumentiert und insgesamt eine ziemliche Schinderei.
Qt nimmt einem da keine Arbeit ab. Das gleiche gilt für sehr viele andere Bereiche.

Richtig, aber ich zweifle immer noch daran, dass einem Cocoa hier Arbeit abnimmt. Ich hatte hier vor, eine saubere Grube für dich auszuheben, in die du dann reindappst, wenn du die API suchst. Ich war davon ausgegangen, dass CD-Recording auf Mac wie auf Linux mit Kommandozeilentools gelöst wird, was ich auch für vernünftig halte. Ich kann mir eine C-ApI vorstellen, aber an einen Cocoawrapper glaube ich noch nicht.

So ist das bei vielen Systemsachen. Cocoa verlässt mich ja schon, wenn ich einen Farbverlauf malen will. Dann muss ich wieder auf C und CG gehen. Das hab ich letztens gemacht, das war auch gar nicht so schlimm, CG ist für eine C-API gar nicht schlecht. Aber ob ich da jetzt Qt oder Cocoa drauf setze, ist mir relativ gleich. Ich hab zwei APIs. Das gleiche wird unter Windows so sein. Ich würde mich aber auch gerne eine besseren belehren lassen und mir die .net-Klasse fürs CD-Schreiben ansehen, wenn sie mir jemand zeigt.

Original von below
Die 20 MB hängen natürlich ganz davon ab, welche Qt Module Du verwendest. Mein Beispiel ist der last.fm Player.

Schauen wir uns den Player dochmal an:



In der Tat sehen wir die angesprochenen 20 MB. Da meint es jemand sehr gut und liefert die kompletten wiederverwertbaren Frameworks mit. Er meint es sogar so gut, dass er auch noch die Header mit reinpackt:



Dieses scheint mir auch für die Macwelt etwas unüblich zu sein. Die Frage nach irgendwelchen Optimierungen der Binary stellt sich mir dann gar nicht mehr.

Die Qt-Programme, die pro Fenster eine Menübar machen, verhalten sich in der Tat wie von dir geschildert. Das heist dann aber auch, dass die diese Menübar auch unter Windows und Linux haben und auch da finde ich es "merkwürdig". Hier muss man aber fairerweise zugeben, dass auch Apple ein Programm mit zwei Menüleisten im Angebot hat: Logic Pro.

Edit: Was ich besonders interessant finde: Der Player kommt bei mir gar nicht hoch, sondern kachelt mit einem "Bus error" ab. Wenn ich den dann mal im Debugger hochfahren lasse, bekomme ich beim Backtrace sogar noch einige Funktionsnamen in Qt. Ggf. sind auch noch Debugsymbole drinn.