Bücher über Qt sind doch mittlerweile völlig für die Tonne. Kaum ist das Buch auf dem Markt, gibt es schon wieder eine neue Version. Zudem gehen die Bücher alle nicht sehr in die Tiefe, bewegen sich auf dem Level der mitgelieferten Doku/Tutorials von Qt, da brauch ich kein Buch mehr.
Dies ist bei vielen Büchern so, sobald man einen gewissen Technikstand erreicht hat, deswegen sind die Bücher aber nicht schlecht, da sie sich vorallem für Einsteiger eignen.
Für Erfahrene Programmierer gibt es nunmal nicht soviele und sinnvolle Bücher, da reicht meist die Dokumentation der Sprachen/Frameworks aus.
Bei Qt ist es aber besonders krass, sieht man ja hier auch: Kaum ist das Buch fertig ist schon die nächte Version (4.2) draussen die nicht mehr berücksichtigt werden konnte. Da das Buch nicht sonderlich in die Tiefe geht und auch nicht besonders in die Breite kann man es sich völlig sparen. Ich sehe deshalb weder für Anfänger noch für Fortgeschrittene als Zielgruppe für dieses Buch und damit ist es völlig überflüssig.
Die neuen Features von Qt 4.2 werden wohl nicht berücksichtigt, richtig. Aber die Grundlagen haben sich nicht geändert, und alles was im Buch steht funktioniert auch noch mit 4.2. Die Funktionalität von 4.1 sollte alles enthalten, was ein Anfänger am Anfang benötigt. Wer sich dann auskennt, kann sich die neuen Features von 4.2 ja immer noch über die Online-Doku informieren.
Von Kevin Krammer am Di, 10. Oktober 2006 um 10:25 #
Das Qt4.2 nicht berücksichtig werden konnte, ist nicht so problematisch. Das Buch enthält damit nur keine Informationen über Qt/D-Bus Bindings und QGraphicsView, beides Technologien, die ein Anfänger vermutlich eher nicht gleich brauchen wird.
Nachdem der Titel "Einführung in die Applikationsentwicklung" ist, dürfte der Fokus mehr auf Richtung Qt Basiswissen und übliche Vorgehensweisen liegen. Praktisch eine Art gedrucktes Tutorial, wobei mehr Erklärungen als bei einem Onlinetutorial vorhanden sind.
Nicht nur binär denken! Dokumentationen in Deutsch sind im Regelfall einfacher zu verstehen. Zumindest empfinde ich es als wesentlich angenehmer. Bin allerdings auch Amateur.
Glaubst Du im Ernst der "Entwickler" ist wirklich einer? Das ist vermutlich ein frustiertes Kleinkind das zuwenig Zuwendung findet und deshalb hier den Großkotzt spielt! :))
Komisch, ich scheine keine Deiner Ansichten zu teilen... Zwar sprichst Du (bekannte) Probleme an, aber ich teile weder Deine Aussage "für die Tonne", noch dass Entwickler wirklich nur mit flüssigem Englisch eine Chance haben...
Mag sein, dass es für Dich "für die Tonne" ist, es Dir zu oberflächlich ist - und sicher ist es so, dass Englisch-Kenntnisse bei Programmentwicklungen helfen. Aber Du schreibst in einem Forum, wo es sehr wahrscheinlich ist, dass sich die Welt nicht nur um Dich dreht
> Wer kein Englisch kann sollte das Entwicklen > besser ganz bleiben lassen.
Gäbe es keine deutschsprachigen Bücher übers Entwickeln, dann hätte ich kaum mit 14 angefangen zu programmieren sondern erst viel später oder nie. Jemand, der beruflich Software entwickelt, sollte wohl ausreichend Englisch können (und auch da bevorzugen manche die deutsche Übersetzung, einfach weil es für sie weniger anstrengend ist), aber vergiss nicht die ganzen Schüler und andere Hobbyisten, die nicht ständig mit englischer Dokumentation konfrontiert sind.
> Wen interessiert was irgendwelche Kinder wollen?
1. Aus Kindern werden evtl. irgendwann professionelle Entwickler. 2. Open-Source-Bibliotheken bieten sich für die ersten Gehversuche an. 3. Jedes Buch hat eine andere Zielgruppe, nicht alle können den C++-Profi mit 10 Jahre Berufserfahrung in UI-Entwicklung ansprechen.
> Die sind nicht die Zielgruppe von Qt sondern professionelle Entwickler.
Die Zielgruppe der Open-Source-Version sind alle OSS-Entwickler, was die komplette Bandbreite von Jugendlichen, Hobbyisten, Studenten und "Profis" enthält.
> Zudem gehen die Bücher alle nicht sehr in die > Tiefe, bewegen sich auf dem Level der > mitgelieferten Doku/Tutorials > von Qt, da brauch ich kein Buch mehr.
Ich habe durch das Blanchette-Buch immerhin gelernt, dass man signals mit signals connecten kann. Das wusste ich bis dahin noch nicht ;-)
Dann gibt es noch ein Buch mit Tricks für den "Profi" (von Dahlheimer, Faure oder so), das wird Sachen enthalten, die man nicht in der Online-Doku findet.
Fox hat (leider) keine Zukunft. Es ist zwar in dr Tat schnell und leistungsfähig aber eben zu sehr Nische. Dave Durham, der eine der grössten Foxapps bisher geschrieben hat, ist gerade dabei, diese nach naaaaaa..... -> tatsächlich QT zu portieren. Rezound lief/läuft wirklich gut und gefühlt tatsächlich flüssiger als vergleichbare QT/GTK-Programme aber auf die Dauer immer sein eigenesSüppchen kochen und die Anwender ein ganzes Toolkit nur für eine einzige Applikation installieren zu lassen...
Es gibt schon einen Markt für leichgewichtige Toolkits. Das dumme ist nur, dass dieser Markt ebenfalls zersplittert ist. Es gibt fltk, fltk2, efltk (wird von EDE benutzt) und eben auch das Fox Toolkit wobei bei diesem ebenfalls Versions-Inkompatibilitäten bestehen (versucht mal xfe 0.88 mit Fox 1.6 zu kompilieren). Andere, aus heutiger Sicht leichgewichtige, Toolkits sind Athena (Xaw) und Motif (lesstif), die leider kaum noch benutzt werden.
Hier wäre tatsächlich eine Bündelung der Kräfte angesagt. Es gibt einzelne interessante Apps für die verschiedenen Toolkits, aber leider zu wenige für ein einziges. Qt und GTK2, die heutigen Standard-Toolkits, sind leider Bloat.
> und Motif (lesstif), die leider kaum noch benutzt > werden.
Das "leider" würde ich durch "glücklicherweise" ersetzen. Motif erzeugt beim Benutzer Augenkrebs und beim Entwickler Nervosität und Brechreiz. Manchem grottigen Toolkit muss man wirklich keine Träne nachweinen.
Wenn Du Rezound als eine der groessten Fox Apps bezeichnest, dann weist Du nicht wovon Du sprichst. Du solltest Dir vielleicht die Referenzen, die der Autor des C++ Toolkits auf seiner Seite auflistet, ein wenig genauer anschauen. Und wie gesagt, Du vergleichst Aepfel mit Birnen. Fox ist ein C++ Toolkit das seiner Bezeichnung gerecht wird. Hingegen ist QT ein Framework, das versucht allen gerecht zu werden. Das dabei Einfachheit und Geschwindigkeit auf der Strecke bleiben ist nicht zu vermeiden. Das heisst man muss vorher wissen was man braucht.
"eine der grössten" ist sicher nicht sehr exakt, allerdings ist Rezound neben xfe nicht nur die grösste, sondern so ziemlich die einzige Fox-Applikation, die sich in einem durchschnittlichen Linux-Reository finden wird. Insofern ist es schon das grösste, was unter Linux normalerweise von Fox bekannt sein dürfte.
Ansonsten hast Du sicher recht, QT versucht viel mehr zu sein, als Fox und da ist es nicht verwunderlich, das es nicht so schlank sein kann, wie Fox. Wer nun den Umgang mit einem Toolkit erlernen will, wird sich häufig fragen "Wie weit komme ich damit?" und auch "Was gibt es an Literatur, wie gross ist die Nutzergemeinde, wie gross ist die chance, das mir in Mailinglisten etc geholfen wird, wenn ich Fragen habe?" etc und da sind einfach GTK und QT die nacheliegendsten Möglichkeiten. Zumal viele Distributoren Wert darauf legen, das auf ihren Desktops alle Applikationen irgendwie gleich aussehen. Zur Zeit wird zum Beispiel jede Menge Entwicklerpower darauf verwendet, einen mittelmässigen Audioeditor zu entwickeln, dessen einziger Vorteil es wohl sein wird, das er wie eine moderne GNOME-App aussieht. Nur weil existierende gute Software wie Audacity oder eben Rezound optisch nicht ins Desktopkonzept von Ubuntu passt...
Das Problem von Fox ist der Entwickler desselben. Der macht das mehr oder weniger alleine und lässt sich auch nicht reinquatschen, manche sagen auch er wäre ein Idiot, weil er sich immer wie der Chef aufspielt. Ahnung hat er ja, Fox finde ich sehr gelungen und hat auch professionelle Features drin, wo sich andere Toolkits auf Kinderkram fixieren oder auf hundert Hochzeiten tanzen (wollen) aber nichts richtig gebacken bekommen. Aber solche Zustände führen früher oder später zu einem Sterben des Projekts oder es dümpelt in der Bedeutungslosigkeit vor sich hin. Ab einer gewissen Grösse und Komplexität kann man so ein Projekt eben nicht mehr als Ein-Mann-Projekt druchziehen und wenn der Chef des ganzen ein Egomane ist, dann siehe oben.
Der Entwickler laesst sich nicht "reinquatschen" das stimmt. Das hat aber sein gutes - das ganze Toolkit ist sehr konstistent und durchdacht. Da das Tooklkit unter LGPL steht (was manche gerne vergessen) ist es jedem vorbehalten es nach seinen Vorstellungen zu veraendern (auch Firmen). Bei Problemen reicht eine private mail, in der er einem SEHR detailiert und ausfuerlich (und FREUNDLICH) weiterhilft. Ich weiss von was ich rede da wir FOX schon 4 Jahre im produktiven Einsatz verwenden und die Software auch verkaufen.
PS: Auch Linus laesst sich nicht "reinquatschen", was ihm nicht gefaellt kommt NICHT in den kernel
> Da das Tooklkit unter LGPL steht (was manche > gerne vergessen) ist es jedem vorbehalten es nach > seinen Vorstellungen zu veraendern (auch Firmen).
Bevor ich als Firma selbst am Toolkit rumbasteln würde (es ist ja nicht mit kleinen Änderungen getan), würde ich dann doch lieber Qt-Lizenzen kaufen oder Gtk+ nehmen. Kommt beides billiger.
>>Toolkit rumbasteln würde (es ist ja nicht mit kleinen Änderungen getan)
Wenn Du programmieren als rumbasteln bezeichnest, solltest Du Dich aufs Mausklicken beschraenken. Wie weisst Du das es nicht mit kleineren Aenderungen getan ist ? Ein Beispiel ? Noch einmal, es ist ein C++ Toolkit, und diesen Namen wird es gerecht. Wir haben unserer Application ein anderes Theme verpasst, das war nicht mehr als 2 Tage Arbeit. Wenn ich schaue wieviel Mitarbeiter in manchen Firmen in Pausen verbringen, geradezu laecherlich wenig :)
PS: Das kaufen einer QT Lizenz, schuetzt Dich nicht davor dass Du ab und zu Dinge benoetigst das QT so wie Du es brauchst nicht zu Verfuegung stellt.
> Wenn Du programmieren als rumbasteln > bezeichnest, solltest Du Dich aufs > Mausklicken beschraenken.
Nein, mit "rumbasteln" meine ich: Ein Toolkit schreiben, wenn ich eigentlich eine Anwendung schreiben wollte. Wenn die Erweiterung des Toolkits mehr Zeit in Anspruch nimmt als die eigentliche Anwendung, sollte man sich Gedanken machen, ob das noch effektiv ist, oder ob nicht vielleicht ein anderes Toolkit geeigneter gewesen wäre (selbst wenn es Geld kostet, werden die Lizenzen selten teurer als die Eigenentwicklung sein).
> Wir haben unserer Application ein anderes > Theme verpasst, das war nicht mehr als 2 > Tage Arbeit.
Hört sich nicht so an, als würde sich die Anwendung gut in den jeweiligen Desktop einfügen. Wenn ich unter Windows arbeite, sollte die Anwendung aussehen wie eine Windows-Anwendung, wenn unter Gnome/KDE wie eine Gnome- bzw. KDE-Anwendung usw. Wenn ich als Entwickler selbst Themes schreibe, läuft irgendwas falsch :-)
> PS: Das kaufen einer QT Lizenz, schuetzt > Dich nicht davor dass Du ab und zu Dinge > benoetigst das QT so wie Du es brauchst > nicht zu Verfuegung stellt.
Habe ich nie behauptet. Die Frage ist nur, wie oft kommt der Fall vor, wie oft komme ich mit dem vorhandenen aus. Wenn das Toolkit gut ist, ist die Erweiterung einfach und elegant, wenn nicht, nunja.
Seit wann integriert sich eine reine QT application vom theme her alleine in KDE oder GNOME ? Schon mal Opera unter Linux ausprobiert ? Firefox (kein Qt) integriert sich ins KDE theme ? Das man sich vorher Gedanken machen muss ob man ein Toolkit oder ein Framework braucht habe ich ja schon zuvor angemerkt, nur zu behaupten man nimmt Qt und alles wird gut ist ein bisschen naiv. Da Qt ja deiner Meinung nach alles an "Board" hat und man nicht mehr "basteln" muss, warum haben die Firefox Entwickler nicht einfach Qt genomen, das hat ja schon von Haus aus ein HTML widget dabei. Da laeuft doch was falsch wenn man als "Entwickler" selbst seine HTML engine schreiben muss
aber irgendeine Kooperation der _fox geschädigten_ wäre hilfreich. Warum muss jede seine eigene taborder Funktionalität schreiben. Vieleicht auch nur, in dem man benötigte (gewünschte) Dinge zusammenträgt und auch finanziel Jeroen unterstützt.
> Da Qt ja deiner Meinung nach alles an "Board" hat > und man nicht mehr "basteln" muss, warum haben die > Firefox Entwickler nicht einfach Qt genomen, das > hat ja schon von Haus aus ein HTML widget dabei.
Ich habe nie behauptet, dass Qt alles perfekt und allen Ansprüchen gerechtwerdend löst. Wenn man einen dedicated HTML Browser schreiben will, braucht man natürlich etwas fortgeschritteneres. Wenn ich ein bisschen Richtext anzeigen oder einfaches HTML rendern will, komme ich mit den Qt-Boardmitteln aber wunderbar aus.
> Da laeuft doch was falsch wenn man als "Entwickler" > selbst seine HTML engine schreiben muss:)
Für eine normale Anwendung, die kein Browser ist: Ja. Da nehme ich gecko, KHTML, was auch immer. Ich erfinde bestimmt nicht das Rad neu und schreibe noch eine HTML-Engine.
...wie oft kommt der Fall vor, wie oft komme ich mit dem vorhandenen aus ...
wenn man _ernsthaft_ der Kundschaft einen Mehrwert bieten möchte, kommt man mit keinem Werkzeug aus. Sowas können sich nur grosse Firmen erlauben, die haben dafür Teams von hauseigenen Philosophen, die unendliche Spezifikationen generieren können, wobei der Hauptaugenmerk auf _nicht später schuld sein_ liegt. Rest erledigt die Rechtsabteilung, wenn die Kunden meinen sollten, das irgendetwas zum Stand der Technik gehört. Wir kleine Buden müssen tricksen.
Sorry, ich kann die hier nicht folgen. Worüber sprichst du?
> wenn man _ernsthaft_ der Kundschaft einen Mehrwert > bieten möchte, kommt man mit keinem Werkzeug aus.
Was für ein Mehrwert gegenüber wem, was für ein Werkzeug? Und welche Konsequenz hat diese Feststellung für dich? Alles selber entwickeln und natürlich besser als alle anderen? Oder willst du nur sagen, dass man überall mal eigene Anpassungen und Erweiterungen vornehmen muss? Das würde ich nicht bestreiten. Die Frage ist nur, wieviel Aufwand sind solche Änderungen, und ist das Resultat wirklich besser als evtl. bereits vorhandene Lösungen.
> Rest erledigt die Rechtsabteilung, wenn die Kunden > meinen sollten, das irgendetwas zum Stand der > Technik gehört. Wir kleine Buden müssen tricksen.
Also ich hab' selten ein Buch gesehen das eine so dermassen extreme Verspaetung hatte wie dieses Qt-Buch. Urspruenglich sollte das Buch schon vor einem Jahr draussen sein und wurde darauf hin Monat fuer Monat verschoben.
Echt krass - so eine Verspaetung habe ich bei noch keinem anderen Buch erlebt.
Naja, mal schauen, ob sich die extreme Wartezeit gelohnt hat...
Von Anonymous Coward am Di, 10. Oktober 2006 um 12:55 #
Qt hat gegenüber GTK erhebliche Vorteile: - bessere Lizenz (wer unfreie Software entwickeln will zahlt) - besssere Singal-System (Signale und Slots, im Gegensatz zu libsigc++ - komplettes Framework zur portablen Applikationsentwicklung, nicht nur GUI-Kram sondern auch Netzwerk usw. - kein alter C-Müll sondern nur astreines, objektorientiertes C++ - schneller (z. B. der Datei-öffnen-Dialog. Schonmal probiert, /usr/bin mit dem GTK-Datei-öffnen-Dialog zu betrachten?) Früher, als Qt noch nicht frei war, gab es Gründe für GTK, aber das ist vorbei. Spätestens seit Qt4 ist Qt das Maß aller Dinge.
Von Der Entwickler am Di, 10. Oktober 2006 um 13:57 #
Beide tool-kits sind sehr einfach zu benutzen und haben ihre Vor- und Nachteile. Die Verbesserung des einen ist immmer Ansporn für die Entwicklergemeinde des "Konkurrenz"-Produktes sich stärker anzustrengen und alle profitieren davon. Die Nihilisierung der Bemühungen einer Entwicklerschaft ist zutiefst unfair, da einige fähige Leute ihre Zeit und Fähigkeiten dafür aufwenden und der Allgemeinheit zur Verfügung stellen. Bitte etwas mehr Respekt!
Genau, auch Gtk hat seine Vorteile. Man braucht zum Beispiel nur einen C- aber keinen C++ Compiler dafür. Den Unterschied mögen manche nicht verstehen, aber es gibt Plattformen, für die schlicht noch kein C++ Compiler existiert, für C aber schon. Und wenn es doch einen gibt, dann ist er häufig nicht auf dem Stand der Dinge, letzte Änderungsdaten aus dem vorigen Jahrtausend sind da keine Seltenheit. Dann gibt es Probleme mit Templates bzw. sie fehlen und Qt ist Geschichte. Und nein, der gcc ist nicht immer die Lösung, auch wenn man durch crossen das meiste erschlagen kann. Schließlich gibt es auch noch andere Betriebssysteme als nur Linux und BSD.
Die Gnome (und damit die meisten GTK Nutzer) Leute entwickeln hauptsächlich für Linux..... und das sieht man wenn man die Software auf anderen Plattformen einsetzt. Bei QT hab ich schon deutlich mehr Software auf anderen Plattformen gesehen. Ich glaube jedoch die Diskussion geht hier ein bisschen am Kernproblem vorbei. In Bereichen wie Wartbarkeit, Entwicklungsdauer, Stabilität, Portierbarkeit kann man sowohl C also auch C++ im Vergleich zu moderneren Technologien getrost vergessen. C und C++ haben in geschwindigkeitsrelevanten und in sehr tiefen Systembereichen eine Daseinberechtigung. Aber in den meisten Anwendungen die darauf aufsetzen sollte man zeitgemäße Technologien des Software Engineerings verwenden wie Java oder C# mit Net. Ein grafisches Administrationswerkzeug für Endanwender in C zu programmieren ist der wohl größte Blödsinn den es gibt.
Von Trollmeister am Di, 10. Oktober 2006 um 19:56 #
Aber in den meisten Anwendungen die darauf aufsetzen sollte man zeitgemäße Technologien des Software Engineerings verwenden wie Java oder C# mit Net. Ein grafisches Administrationswerkzeug für Endanwender in C zu programmieren ist der wohl größte Blödsinn den es gibt.
Ich programmiere in der Arbeit unter .NET und meiner Meinung nach ist das keinesfalls produktiver als C++ mit Qt. Das Layout-Management unter .NET ist beispielsweise deutlich schlechter als das von Qt. Visual Studio ist zwar ganz nett, hat aber auch jede Menge Bugs, mit denen man sich dauernd rumschlagen muß. Ich jedenfalls wäre froh, wenn ich in der Arbeit C++ und Qt statt diesem .NET Kram verwenden könnte.
> Aber in den meisten Anwendungen die darauf > aufsetzen sollte man zeitgemäße Technologien des > Software Engineerings verwenden wie Java oder C# > mit Net.
Prinzipiell stimme ich dir zu, dass High-Level-Sprachen für die meisten Anwendungsgebiete vorzuziehen sind, aber gerade Java ist für Desktop-Anwendungen bisher nur schlecht geeignet, Swing ist sowohl von der Oberfläche als auch von der API her eine Katastrophe. SWT sieht besser aus und integriert sich besser, aber wirklich nativ ist es immer noch nicht (über die API von SWT kann ich nicht viel sagen, da habe ich keine Erfahrungen). Dazu kommen die langen Ladezeiten für die VM, was bei kleineren Anwendungen schon eine Rolle spielt.
Ich bin auf Jambi gespannt, evtl. macht dann UI-Entwicklung unter Java endlich Spaß und das Ergebnis fügt sich dazu noch gut in den Desktop ein.
bessere Lizenz (wer unfreie Software entwickeln will zahlt)
Das ist doch eigentlich ein Problem der Entwickler, wenn sie ihr Zeugs umsonst hergeben. Wenn sie das so wollen, warum ist das dann schlecht?
kein alter C-Müll sondern nur astreines, objektorientiertes C++
Und für was gibt es den moc, wenn es nur 'astreines, objektorientiertes C++' ist. Abgesehen davon, gibt es für GTK auch noch gtkmm als C++-Binding.
Früher, als Qt noch nicht frei war, gab es Gründe für GTK, aber das ist vorbei. Spätestens seit Qt4 ist Qt das Maß aller Dinge.
Ich will hier QT bestimmt nicht schlecht reden. QT mag toll sein, aber man kann nicht sagen, dass es sämtliche gute Eigenschaften aller Frameworks und Toolkits in sich vereint, so dass alle anderen nutzlos wären.
> Das ist doch eigentlich ein Problem der > Entwickler, wenn sie ihr Zeugs umsonst hergeben. > Wenn sie das so wollen, warum ist das dann > schlecht?
Richtig, "moralisch" ist es Sache der Entwickler (ich hasse Leute, die dem Entwickler die Lizenz vorschreiben wollen - wenn z.B. jemand seinen Code unter BSD-Lizenz veröffentlichen möchte, ist das sein gutes Recht). Von der "praktischen" Seite her ist es für ein Toolkit (eigentlich für jede Software) von Vorteil, wenn ausreichend Entwickler Vollzeit und gut bezahlt daran arbeiten können.
> Und für was gibt es den moc, wenn es > nur 'astreines, objektorientiertes C++' ist.
Der moc erzeugt astreines objektorientiertes C++. Nur macht man es eben nicht manuell sondern der Cod wird generiert.
> Abgesehen davon, gibt es für GTK auch noch gtkmm > als C++-Binding.
...das immer vollständig und auf dem neuesten Stand mit dem aktuellen Gtk+-Release sein muss. Hier ist Qt im Vorteil, da kann ein derartiges Lag gar nicht erst entstehen.
> QT mag toll sein, aber man kann nicht sagen, dass > es sämtliche gute Eigenschaften aller Frameworks > und Toolkits in sich vereint, so dass alle > anderen nutzlos wären.
Gut, ich mag Qt lieber als Gtk, aber trotzdem finde ich das mit dem C-Müll nicht richtig, weil man das Signal-Slot-System auch mit C++-Templates hätte realisieren können, aber zu der Zeit waren die Templates von einigen Compilern nicht unterstützt und daher hatte Trolltech sich den moc ausgedacht. moc ist auch nur ein Überbleibsel aus alten Zeiten. Außerdem ist Gtk ein GUI-only-Toolkit, wofür es auch entwickelt worden ist. Qt ist da zwar komplettierter, aber man erwartet ja z. B. nicht von einer Kuh, dass sie nicht nur Milch gibt, sondern auch Eier legt. Dafür gibts ja die eierlegende Wollmilchsaukuh.
Kaum ist das Buch auf dem Markt, gibt es schon wieder eine neue
Version. Zudem gehen die Bücher alle nicht sehr in die Tiefe,
bewegen sich auf dem Level der mitgelieferten Doku/Tutorials
von Qt, da brauch ich kein Buch mehr.
Für Erfahrene Programmierer gibt es nunmal nicht soviele und sinnvolle Bücher, da reicht meist die Dokumentation der Sprachen/Frameworks aus.
Da das Buch nicht sonderlich in die Tiefe geht und auch nicht besonders in die Breite kann man es sich völlig sparen.
Ich sehe deshalb weder für Anfänger noch für Fortgeschrittene als Zielgruppe für dieses Buch und damit ist es völlig überflüssig.
Nachdem der Titel "Einführung in die Applikationsentwicklung" ist, dürfte der Fokus mehr auf Richtung Qt Basiswissen und übliche Vorgehensweisen liegen.
Praktisch eine Art gedrucktes Tutorial, wobei mehr Erklärungen als bei einem Onlinetutorial vorhanden sind.
Dokumentationen in Deutsch sind im Regelfall einfacher zu verstehen. Zumindest empfinde ich es als wesentlich angenehmer.
Bin allerdings auch Amateur.
Glaubst Du im Ernst der "Entwickler" ist wirklich einer?
Das ist vermutlich ein frustiertes Kleinkind das zuwenig Zuwendung findet und deshalb hier den Großkotzt spielt! :))
Zwar sprichst Du (bekannte) Probleme an, aber ich teile weder Deine Aussage "für die Tonne", noch dass Entwickler wirklich nur mit flüssigem Englisch eine Chance haben...
Mag sein, dass es für Dich "für die Tonne" ist, es Dir zu oberflächlich ist - und sicher ist es so, dass Englisch-Kenntnisse bei Programmentwicklungen helfen. Aber Du schreibst in einem Forum, wo es sehr wahrscheinlich ist, dass sich die Welt nicht nur um Dich dreht
> besser ganz bleiben lassen.
Gäbe es keine deutschsprachigen Bücher übers Entwickeln, dann hätte ich kaum mit 14 angefangen zu programmieren sondern erst viel später oder nie.
Jemand, der beruflich Software entwickelt, sollte wohl ausreichend Englisch können (und auch da bevorzugen manche die deutsche Übersetzung, einfach weil es für sie weniger anstrengend ist), aber vergiss nicht die ganzen Schüler und andere Hobbyisten, die nicht ständig mit englischer Dokumentation konfrontiert sind.
Die sind nicht die Zielgruppe von Qt sondern professionelle Entwickler.
Die Kommentare zeigen mir dass hier nur Hobbyisten und Kiddies unterwegs sind.
1. Aus Kindern werden evtl. irgendwann professionelle Entwickler.
2. Open-Source-Bibliotheken bieten sich für die ersten Gehversuche an.
3. Jedes Buch hat eine andere Zielgruppe, nicht alle können den C++-Profi mit 10 Jahre Berufserfahrung in UI-Entwicklung ansprechen.
> Die sind nicht die Zielgruppe von Qt sondern professionelle Entwickler.
Die Zielgruppe der Open-Source-Version sind alle OSS-Entwickler, was die komplette Bandbreite von Jugendlichen, Hobbyisten, Studenten und "Profis" enthält.
> Tiefe, bewegen sich auf dem Level der
> mitgelieferten Doku/Tutorials
> von Qt, da brauch ich kein Buch mehr.
Ich habe durch das Blanchette-Buch immerhin gelernt, dass man signals mit signals connecten kann. Das wusste ich bis dahin noch nicht ;-)
Dann gibt es noch ein Buch mit Tricks für den "Profi" (von Dahlheimer, Faure oder so), das wird Sachen enthalten, die man nicht in der Online-Doku findet.
Ein Buch kann ich in der Badewanne lesen! Bestelle ich mir gleich heute.
Evtl. ist der Markt für Qt-Bücher einfach größer als für Fox Toolkit.
Und für welche Anwendungsfälle ist Qt bitte zu langsam?
Dave Durham, der eine der grössten Foxapps bisher geschrieben hat, ist gerade dabei, diese nach naaaaaa..... -> tatsächlich QT zu portieren. Rezound lief/läuft wirklich gut und gefühlt tatsächlich flüssiger als vergleichbare QT/GTK-Programme aber auf die Dauer immer sein eigenesSüppchen kochen und die Anwender ein ganzes Toolkit nur für eine einzige Applikation installieren zu lassen...
Hier wäre tatsächlich eine Bündelung der Kräfte angesagt. Es gibt einzelne interessante Apps für die verschiedenen Toolkits, aber leider zu wenige für ein einziges. Qt und GTK2, die heutigen Standard-Toolkits, sind leider Bloat.
> werden.
Das "leider" würde ich durch "glücklicherweise" ersetzen. Motif erzeugt beim Benutzer Augenkrebs und beim Entwickler Nervosität und Brechreiz. Manchem grottigen Toolkit muss man wirklich keine Träne nachweinen.
Wenn Du Rezound als eine der groessten Fox Apps bezeichnest, dann weist Du nicht wovon Du sprichst. Du solltest Dir vielleicht die Referenzen, die der Autor des C++ Toolkits auf seiner Seite auflistet, ein wenig genauer anschauen. Und wie gesagt, Du vergleichst Aepfel mit Birnen. Fox ist ein C++ Toolkit das seiner Bezeichnung gerecht wird. Hingegen ist QT ein Framework, das versucht allen gerecht zu werden. Das dabei Einfachheit und Geschwindigkeit auf der Strecke bleiben ist nicht zu vermeiden. Das heisst man muss vorher wissen was man braucht.
Ansonsten hast Du sicher recht, QT versucht viel mehr zu sein, als Fox und da ist es nicht verwunderlich, das es nicht so schlank sein kann, wie Fox.
Wer nun den Umgang mit einem Toolkit erlernen will, wird sich häufig fragen "Wie weit komme ich damit?" und auch "Was gibt es an Literatur, wie gross ist die Nutzergemeinde, wie gross ist die chance, das mir in Mailinglisten etc geholfen wird, wenn ich Fragen habe?" etc und da sind einfach GTK und QT die nacheliegendsten Möglichkeiten.
Zumal viele Distributoren Wert darauf legen, das auf ihren Desktops alle Applikationen irgendwie gleich aussehen. Zur Zeit wird zum Beispiel jede Menge Entwicklerpower darauf verwendet, einen mittelmässigen Audioeditor zu entwickeln, dessen einziger Vorteil es wohl sein wird, das er wie eine moderne GNOME-App aussieht. Nur weil existierende gute Software wie Audacity oder eben Rezound optisch nicht ins Desktopkonzept von Ubuntu passt...
Ahnung hat er ja, Fox finde ich sehr gelungen und hat auch professionelle Features drin, wo sich andere Toolkits auf Kinderkram fixieren oder auf hundert Hochzeiten tanzen (wollen) aber nichts richtig gebacken bekommen. Aber solche Zustände führen früher oder später zu einem Sterben des Projekts oder es dümpelt in der Bedeutungslosigkeit vor sich hin. Ab einer gewissen Grösse und Komplexität kann man so ein Projekt eben nicht mehr als Ein-Mann-Projekt druchziehen und wenn der Chef des ganzen ein Egomane ist, dann siehe oben.
PS: Auch Linus laesst sich nicht "reinquatschen", was ihm nicht gefaellt kommt NICHT in den kernel
> gerne vergessen) ist es jedem vorbehalten es nach
> seinen Vorstellungen zu veraendern (auch Firmen).
Bevor ich als Firma selbst am Toolkit rumbasteln würde (es ist ja nicht mit kleinen Änderungen getan), würde ich dann doch lieber Qt-Lizenzen kaufen oder Gtk+ nehmen. Kommt beides billiger.
Wenn Du programmieren als rumbasteln bezeichnest, solltest Du Dich aufs Mausklicken beschraenken. Wie weisst Du das es nicht mit kleineren Aenderungen getan ist ? Ein Beispiel ? Noch einmal, es ist ein C++ Toolkit, und diesen Namen wird es gerecht. Wir haben unserer Application ein anderes Theme verpasst, das war nicht mehr als 2 Tage Arbeit. Wenn ich schaue wieviel Mitarbeiter in manchen Firmen in Pausen verbringen, geradezu laecherlich wenig :)
PS: Das kaufen einer QT Lizenz, schuetzt Dich nicht davor dass Du ab und zu Dinge benoetigst das QT so wie Du es brauchst nicht zu Verfuegung stellt.
> bezeichnest, solltest Du Dich aufs
> Mausklicken beschraenken.
Nein, mit "rumbasteln" meine ich: Ein Toolkit schreiben, wenn ich eigentlich eine Anwendung schreiben wollte. Wenn die Erweiterung des Toolkits mehr Zeit in Anspruch nimmt als die eigentliche Anwendung, sollte man sich Gedanken machen, ob das noch effektiv ist, oder ob nicht vielleicht ein anderes Toolkit geeigneter gewesen wäre (selbst wenn es Geld kostet, werden die Lizenzen selten teurer als die Eigenentwicklung sein).
> Wir haben unserer Application ein anderes
> Theme verpasst, das war nicht mehr als 2
> Tage Arbeit.
Hört sich nicht so an, als würde sich die Anwendung gut in den jeweiligen Desktop einfügen. Wenn ich unter Windows arbeite, sollte die Anwendung aussehen wie eine Windows-Anwendung, wenn unter Gnome/KDE wie eine Gnome- bzw. KDE-Anwendung usw.
Wenn ich als Entwickler selbst Themes schreibe, läuft irgendwas falsch :-)
> PS: Das kaufen einer QT Lizenz, schuetzt
> Dich nicht davor dass Du ab und zu Dinge
> benoetigst das QT so wie Du es brauchst
> nicht zu Verfuegung stellt.
Habe ich nie behauptet. Die Frage ist nur, wie oft kommt der Fall vor, wie oft komme ich mit dem vorhandenen aus. Wenn das Toolkit gut ist, ist die Erweiterung einfach und elegant, wenn nicht, nunja.
> und man nicht mehr "basteln" muss, warum haben die
> Firefox Entwickler nicht einfach Qt genomen, das
> hat ja schon von Haus aus ein HTML widget dabei.
Ich habe nie behauptet, dass Qt alles perfekt und allen Ansprüchen gerechtwerdend löst. Wenn man einen dedicated HTML Browser schreiben will, braucht man natürlich etwas fortgeschritteneres. Wenn ich ein bisschen Richtext anzeigen oder einfaches HTML rendern will, komme ich mit den Qt-Boardmitteln aber wunderbar aus.
> Da laeuft doch was falsch wenn man als "Entwickler"
> selbst seine HTML engine schreiben muss:)
Für eine normale Anwendung, die kein Browser ist: Ja. Da nehme ich gecko, KHTML, was auch immer. Ich erfinde bestimmt nicht das Rad neu und schreibe noch eine HTML-Engine.
wenn man _ernsthaft_ der Kundschaft einen Mehrwert bieten möchte, kommt man mit keinem Werkzeug aus. Sowas können sich nur grosse Firmen erlauben, die haben dafür Teams von hauseigenen Philosophen, die unendliche Spezifikationen generieren können, wobei der Hauptaugenmerk auf _nicht später schuld sein_ liegt. Rest erledigt die Rechtsabteilung, wenn die Kunden meinen sollten, das irgendetwas zum Stand der Technik gehört. Wir kleine Buden müssen tricksen.
> wenn man _ernsthaft_ der Kundschaft einen Mehrwert
> bieten möchte, kommt man mit keinem Werkzeug aus.
Was für ein Mehrwert gegenüber wem, was für ein Werkzeug? Und welche Konsequenz hat diese Feststellung für dich? Alles selber entwickeln und natürlich besser als alle anderen? Oder willst du nur sagen, dass man überall mal eigene Anpassungen und Erweiterungen vornehmen muss? Das würde ich nicht bestreiten. Die Frage ist nur, wieviel Aufwand sind solche Änderungen, und ist das Resultat wirklich besser als evtl. bereits vorhandene Lösungen.
> Rest erledigt die Rechtsabteilung, wenn die Kunden
> meinen sollten, das irgendetwas zum Stand der
> Technik gehört. Wir kleine Buden müssen tricksen.
Jetzt habe ich den Anschluss völlig verloren.
Echt krass - so eine Verspaetung habe ich bei noch keinem anderen Buch erlebt.
Naja, mal schauen, ob sich die extreme Wartezeit gelohnt hat...
- bessere Lizenz (wer unfreie Software entwickeln will zahlt)
- besssere Singal-System (Signale und Slots, im Gegensatz zu libsigc++
- komplettes Framework zur portablen Applikationsentwicklung, nicht nur GUI-Kram sondern auch Netzwerk usw.
- kein alter C-Müll sondern nur astreines, objektorientiertes C++
- schneller (z. B. der Datei-öffnen-Dialog. Schonmal probiert, /usr/bin mit dem GTK-Datei-öffnen-Dialog zu betrachten?)
Früher, als Qt noch nicht frei war, gab es Gründe für GTK, aber das ist vorbei. Spätestens seit Qt4 ist Qt das Maß aller Dinge.
Die Verbesserung des einen ist immmer Ansporn für die Entwicklergemeinde des
"Konkurrenz"-Produktes sich stärker anzustrengen und alle profitieren davon.
Die Nihilisierung der Bemühungen einer Entwicklerschaft ist zutiefst unfair, da
einige fähige Leute ihre Zeit und Fähigkeiten dafür aufwenden und der Allgemeinheit
zur Verfügung stellen. Bitte etwas mehr Respekt!
Ich glaube jedoch die Diskussion geht hier ein bisschen am Kernproblem vorbei. In Bereichen wie Wartbarkeit, Entwicklungsdauer, Stabilität, Portierbarkeit kann man sowohl C also auch C++ im Vergleich zu moderneren Technologien getrost vergessen. C und C++ haben in geschwindigkeitsrelevanten und in sehr tiefen Systembereichen eine Daseinberechtigung. Aber in den meisten Anwendungen die darauf aufsetzen sollte man zeitgemäße Technologien des Software Engineerings verwenden wie Java oder C# mit Net. Ein grafisches Administrationswerkzeug für Endanwender in C zu programmieren ist der wohl größte Blödsinn den es gibt.
Ich programmiere in der Arbeit unter .NET und meiner Meinung nach ist das keinesfalls produktiver als C++ mit Qt. Das Layout-Management unter .NET ist beispielsweise deutlich schlechter als das von Qt. Visual Studio ist zwar ganz nett, hat aber auch jede Menge Bugs, mit denen man sich dauernd rumschlagen muß. Ich jedenfalls wäre froh, wenn ich in der Arbeit C++ und Qt statt diesem .NET Kram verwenden könnte.
> aufsetzen sollte man zeitgemäße Technologien des
> Software Engineerings verwenden wie Java oder C#
> mit Net.
Prinzipiell stimme ich dir zu, dass High-Level-Sprachen für die meisten Anwendungsgebiete vorzuziehen sind, aber gerade Java ist für Desktop-Anwendungen bisher nur schlecht geeignet, Swing ist sowohl von der Oberfläche als auch von der API her eine Katastrophe. SWT sieht besser aus und integriert sich besser, aber wirklich nativ ist es immer noch nicht (über die API von SWT kann ich nicht viel sagen, da habe ich keine Erfahrungen). Dazu kommen die langen Ladezeiten für die VM, was bei kleineren Anwendungen schon eine Rolle spielt.
Ich bin auf Jambi gespannt, evtl. macht dann UI-Entwicklung unter Java endlich Spaß und das Ergebnis fügt sich dazu noch gut in den Desktop ein.
> Betriebssysteme als nur Linux und BSD.
Für welche Plattform, die auf dem Desktop auch nur irgendeine winzige Rolle spielt, gibt es denn bitte keinen brauchbaren C++-Compiler?
Signale
Slots
libsigc++: Introduction
MfG Maik
Das ist doch eigentlich ein Problem der Entwickler, wenn sie ihr Zeugs umsonst hergeben. Wenn sie das so wollen, warum ist das dann schlecht?
kein alter C-Müll sondern nur astreines, objektorientiertes C++
Und für was gibt es den moc, wenn es nur 'astreines, objektorientiertes C++' ist. Abgesehen davon, gibt es für GTK auch noch gtkmm als C++-Binding.
Früher, als Qt noch nicht frei war, gab es Gründe für GTK, aber das ist vorbei. Spätestens seit Qt4 ist Qt das Maß aller Dinge.
Ich will hier QT bestimmt nicht schlecht reden. QT mag toll sein, aber man kann nicht sagen, dass es sämtliche gute Eigenschaften aller Frameworks und Toolkits in sich vereint, so dass alle anderen nutzlos wären.
Jens
> Entwickler, wenn sie ihr Zeugs umsonst hergeben.
> Wenn sie das so wollen, warum ist das dann
> schlecht?
Richtig, "moralisch" ist es Sache der Entwickler (ich hasse Leute, die dem Entwickler die Lizenz vorschreiben wollen - wenn z.B. jemand seinen Code unter BSD-Lizenz veröffentlichen möchte, ist das sein gutes Recht). Von der "praktischen" Seite her ist es für ein Toolkit (eigentlich für jede Software) von Vorteil, wenn ausreichend Entwickler Vollzeit und gut bezahlt daran arbeiten können.
> Und für was gibt es den moc, wenn es
> nur 'astreines, objektorientiertes C++' ist.
Der moc erzeugt astreines objektorientiertes C++.
Nur macht man es eben nicht manuell sondern der Cod wird generiert.
> Abgesehen davon, gibt es für GTK auch noch gtkmm
> als C++-Binding.
...das immer vollständig und auf dem neuesten Stand mit dem aktuellen Gtk+-Release sein muss. Hier ist Qt im Vorteil, da kann ein derartiges Lag gar nicht erst entstehen.
> QT mag toll sein, aber man kann nicht sagen, dass
> es sämtliche gute Eigenschaften aller Frameworks
> und Toolkits in sich vereint, so dass alle
> anderen nutzlos wären.
Wäre ja auch langweilig
Das hört sich aufwendiger an als es ist. Der größte Teil der Arbeit wird durch ein perl-Skript dem m4 Makroprozessor erledigt.
MfG Maik
Außerdem ist Gtk ein GUI-only-Toolkit, wofür es auch entwickelt worden ist. Qt ist da zwar komplettierter, aber man erwartet ja z. B. nicht von einer Kuh, dass sie nicht nur Milch gibt, sondern auch Eier legt. Dafür gibts ja die eierlegende Wollmilchsaukuh.