Hallo, ich habe angefangen, c++ zu erlernen und möchte bald anfangen, GUI Oberflächen unter Windows und vielleicht auch unter Linux zu erstellen. Ich bin am Übelegen, ob ich dazu mich in die QT4 Bibliothek oder besser gtk+ einarbeiten sollte. Was würdet Ihr mir empfehlen? Ich möchte hauptsächlich Oberflächen für Programme erstellen, die mathematische Berechnungen durchführen. Viele Grüße, Barbax
Das gab es schon viele Diskussionen hier. Ich würde sagen, das ist reine Geschmackssache. Meinem Geschmack enstpricht am ehesten GTK+ zusammen mit GTKmm (C++-API für GTK+).
Die Frage ist doch auch schon ewig alt und wurde tausendfach diskutiert, erst vor wenigen Wochen auch hier im Forum. In diesem Forum hier wird man eher zu QT raten, u.a. weil es bunter ist. Ich hatte mich dann vor gut einem Jahr allerdings doch dazu entschlossen, zunächst mit GTK anzufangen. Ganz kurz: QT passt etwas besser in das Microsoft System -- wer also vorwiegend dafür entwickeln will ist mit QT wohl etwas besser bedient. GTK+ ist in plain C implementiert, QT in C++ mit Erweiterungen. Aber auch für GTK+ gibt es Bindings für C++, Ruby, Python. Das plain C ist daher kein wirklicher Nachteil wie viele meinen, höchstens für die Entwickler selbst, denn objektorientierte Programmierung mit plain C ist etwas aufwendig. Hätte man den Kern von GTK gleich in C++ geschrieben mit dessen objectorientieten Funktionen, so gäbe es eventuell Überlappungen bei anderen objektorientierten Sprachen. Wenn Du Deine Anwendung auch in plain C schreibst, wird der Code etwas länglich/umständlich, dass ist schon war. Aber Du kannst ja die Bindings zu C++ nehmen. Oder die zu Ruby, da ist der Code sehr kompakt. Dann gibt es noch die Sache mit der Lizenz -- da war QT eher etwas restriktiv, aber das ist wohl auch gelockert worden. Fazit: Mir (als GNU/LINUX Menschen) sagt GTK von der Philosophie mehr zu, aber QT ist natürchlich auch sehr gut. Buch für GTK+: Andrew Krause, ist recht gut.
Bei QT sollte man erwähnen, das es neben den GUI Bibliotheken auch noch hunderte andere nützliche Libs gibt (Netzwerk, Datenbankenzugriff usw.).
Und man sollte erwähnen, dass die GLIB, die meistens mit GTK mitkommt, da GTK eben ihr Objekt-Konzept benutzt, ebendiese Funktionen auch bereitstellt. Und auch, dass QT ganz arg C++ verstümmelt, mit dem Meta-Objekt-Compiler und so weiter. Das haben andere eleganter gelöst (Libsigc++ bei GTKmm)...
Und dann war da noch wxWidgets: http://www.wxwidgets.org/ Damit wurde z.B. der bekannte Audio-Editor Audacity erstellt.
> Und auch, dass QT ganz arg C++ verstümmelt, mit dem Meta-Objekt- > Compiler und so weiter. Also "ganz arg verstümmelt" halte ich schon für sehr übertrieben. Es gibt ein paar kleine Erweiterungen. > Das haben andere eleganter gelöst (Libsigc++ bei GTKmm)... Das ist auch Geschmackssache.
QT hat halt das Problem das du nur Open Source programmieren darfst. Für kommerzielle Programme wird gleich ne teure Lizenz gefordert. Ich würde dir auch zu wxWidget raten.
Seit Nokia QT gekauft hat, ist das auch unter der LGPL verfügbar. d.h. du darfst auch kommerzielle closed-source Software damit schreiben.
> möchte bald anfangen, GUI > Oberflächen unter Windows und vielleicht auch unter Linux zu erstellen. Vom Satzinhalt her bedeutet das, du möchtest primär Windows Anwendungen erstellen und dafür würde ich weder QT noch gtk+ nehmen sondern das .NET Framework. Die Programmiesprache kannst du dir dann aussuchen und die freien Express-Editionen von MS erlauben sogar kommerziellen Programmcode zu erstellen. Ein umfangreicheres Framework wirst du wohl kaum finden http://openbook.galileocomputing.de/visual_csharp/
Bezüglich gtk+ fallen mir noch die folgenden Punkte ein: -Glade -GtkBuilder -OpenGL -GLib (!) (wurde schon genannt) Gruß und Kuss,
Andre I. schrieb: > QT hat halt das Problem das du nur Open Source programmieren darfst. Für > kommerzielle Programme wird gleich ne teure Lizenz gefordert. Ich würde > dir auch zu wxWidget raten. Nein. Qt steht seit der am 3. März 2009 veröffentlichten Version 4.5 unter der LGPL, d.h. auch nicht offene Programme dürfen gegen Qt linken. Gruß Axel
Wobei ich ganz ehrlich sagen muss: Wenn man/ich mal spaßeshalber so durch die GNU-Quelltexte durchgucke, also die coreutils (ls, rm, ..), die Quellen vom GCC, vom Linux-Kernel und so weiter, dann vergeht mir teilweise echt die Lust, den Kram noch einzusetzen.
Sven P. schrieb: > Wobei ich ganz ehrlich sagen muss: Wenn man/ich mal spaßeshalber so > durch die GNU-Quelltexte durchgucke, also die coreutils (ls, rm, ..), > die Quellen vom GCC, vom Linux-Kernel und so weiter, dann vergeht mir > teilweise echt die Lust, den Kram noch einzusetzen. Das wird dir genau so mit den Quelltexten von Windows oder MacOS gehen. (Ich arbeite mit und an NetBSD. Das sieht schon besser als Linux aus.) Wirklich "guten Code" wirst du bestenfalls bei akademischen Projekten finden. Aber was hat das mit der eigentlichen Frage zu tun? => Troll! Zum Thema QT vs. GTK: QT ist massive Bloatware. Wenn man mit QT programmiert, programmiert man für QT. Nicht für Linux, Windows oder MacOS sondern QT. QT ist mitlerweile zu einem "Meta-Betriebssytem" ausgeufert. GTK Anwendungen kommen mir immer irgendwie schlanker und schneller als QT Programme vor. Mal ein Blick auf die Quelltextpakete: -rw-rw-r-- 1 jkunz wsrc 18461964 May 31 2009 gtk+-2.16.2.tar.bz2 -rw-rw-r-- 1 jkunz wsrc 114667436 Apr 23 2009 qt-x11-opensource-src-4.5.1.tar.bz2 QT ist also mal grade eben so um den Faktor 6 fetter als GTK. Wenn es aber primär um Oberflächlichkeiten für numerische Berechnungen geht stellt sich mir die Frage ob da nicht etwas wie Matlab, Octave, Scilab, ... das geeignete Werkzeug ist.
GTK ist auch nicht alleine. Das will die GLib sehen, damits in C++ schön aussieht noch GTKmm, das wiederum braucht libsigc++. Zum Zeichnen noch Cairo und libpng (QT bringt ne eigene mit). gtkmm-2.18.2.tar.bz2 04-Oct-2009 07:03 12M pango-1.26.2.tar.bz2 14-Dec-2009 22:22 1.5M libiconv-1.13.tar.gz 30-Mar-2009 19:05 4.5M gettext-0.17.tar.gz 06-Nov-2007 22:14 11M libpng (hat QT dabei) ~800K cairo-1.8.8.tar.gz 16-Jun-2009 06:07 6.3M pixman-0.17.2.tar.gz 20-Nov-2009 03:02 520K ZLib 485K glib-2.22.3.tar.bz2 01-Dec-2009 16:12 4.8M gtkmm-2.18.2.tar.bz2 04-Oct-2009 07:03 12M libsigc++-2.2.4.2.tar.bz2 02-Sep-2009 17:57 3.4M atk-1.29.2.tar.gz 13-Nov-2009 05:11 1.0M Knappe 60MB sind das. Und da fehlen noch einige Formatbibliotheken. Die Liste ist ein Querschnitt aus den Abhängigkeiten, die mein Paketverwalter für Quellpakete ausspuckt, und den Angaben auf den Homepages von GTK(mm), Glib und so weiter.
> Vom Satzinhalt her bedeutet das, du möchtest primär Windows Anwendungen > erstellen und dafür würde ich weder QT noch gtk+ nehmen sondern das .NET > Framework. Die Programmiesprache kannst du dir dann aussuchen und die > freien Express-Editionen von MS erlauben sogar kommerziellen > Programmcode zu erstellen. Ein umfangreicheres Framework wirst du wohl > kaum finden Das setzt aber den Verzicht auf die Verwendung von C++ voraus. Die Microsoft-Perversion namens "Managed C++" hat vom Namen abgesehen nicht viel mit C++ zu tun. Das wars dann auch schon mit "Programmiersprache kannst Du Dir aussuchen", das geht eben nur sehr eingeschränkt. Außerdem setzt .Net das Vorhandensein der .Net-Umgebung voraus; das geht auf älteren Windows-Systemen mit einem etliche Megabyte großem Download-Klumpen einher und setzt auf anderen Systemen die Hoffnung voraus, daß Mono auch richtig installiert wurde. Außerdem ist nicht alles, was .Net unter Windows bietet, auch mit Mono nutzbar, und die MS-Dokumentation geht darauf natürlich ganz und gar nicht ein. Wer aber, der mit .Net-Geraffel anfängt, und das auf einem Windows-System tut, will das mit der Mono-Dokumentation tun? Eine mit echtem C++ nutzbare GUI-Klassenbibliothek, die auf etlichen Plattformen nutzbar ist und native GUI-Elemente verwendet, ist wxWidgets. wxwidgets.org Ein Beispiel für eine wxWidgets-basierende Anwendung ist das sogenannte* "Terminalprogramm" hterm von Tobi. *) Ein Terminalprogramm emuliert ein Terminal, also so etwas wie ein DEC VT100 oder ähnliches, hterm tut nichts dergleichen. Das ist nicht ehrabschneidend gemeint, hterm ist ein exzellentes Schnittstellenanalyse- und Testwerkzeug, aber eben kein Terminalprogramm. Das unsägliche Hyperterminal aber ist eines, genauso wie TeraTerm oder auch Putty.
>Eine mit echtem C++ nutzbare GUI-Klassenbibliothek, die auf etlichen >Plattformen nutzbar ist und native GUI-Elemente verwendet, ist >wxWidgets. "native GUI-Elemente" -- für Linux wird dann in der Regel wohl wiederum GTK+ verwendet. Ich weiss recht wenig über wxWidgets, mir war aber aufgefallen, dass es nicht sehr viel verwendet wird, und man auch nicht so viel Dokumentation wie für QT und GTK findet. KiCAD ist natürlich mit wxWidgets gemacht.
Rufus t. Firefly (rufus) (Moderator) wrote: Datum: 20.12.2009 11:16 >> Vom Satzinhalt her bedeutet das, du möchtest primär Windows Anwendungen >> erstellen und dafür würde ich weder QT noch gtk+ nehmen sondern das .NET >> Framework. Die Programmiesprache kannst du dir dann aussuchen und die >> freien Express-Editionen von MS erlauben sogar kommerziellen >> Programmcode zu erstellen. Ein umfangreicheres Framework wirst du wohl >> kaum finden > Das setzt aber den Verzicht auf die Verwendung von C++ voraus. Die > Microsoft-Perversion namens "Managed C++" hat vom Namen abgesehen nicht > viel mit C++ zu tun. Und bei QT ist das anders? Ob hier von der reinen C++ Lehre abgewichen wird oder nicht ist doch nicht das Maß der Entscheidung (es sei denn es geht darum akademisch vorzeigbaren Code abzuliefern. Aber wie hat hier einer gerade so schön festgestellt: > "Wobei ich ganz ehrlich sagen muss: Wenn man/ich mal spaßeshalber so > durch die GNU-Quelltexte durchgucke, also die coreutils (ls, rm, ..), > die Quellen vom GCC, vom Linux-Kernel und so weiter, dann vergeht mir > teilweise echt die Lust, den Kram noch einzusetzen." > Das wars dann auch schon mit "Programmiersprache > kannst Du Dir aussuchen", das geht eben nur sehr eingeschränkt. Das ist eine persönliche Sichtweise. Tatsache ist, .NET ist so aufgebaut, dass es nicht einer bestimmten Programmiersprache bedarf (lässt sich in allen Fachbüchern nachlesen). > Außerdem setzt .Net das Vorhandensein der .Net-Umgebung voraus; Ja sicher, das ist aber bei allen modernen Windows Installationen bereits der Fall und wer Programmcode für Windows 98 oder gar Windows 95 oder .. haben möchte, sollte das von vorneherein schon mitteilen. > das geht > auf älteren Windows-Systemen mit einem etliche Megabyte großem > Download-Klumpen einher Also das ist jetzt wirklich ein absolut lächerliches Argument und das weißt du als Insider auch selbst. 23 MB für eine .NET 2.0 Laufzeitumgebung ist mit jedem DSL Anschluss schneller gesaugt als es auf der Festplatte sein Zielverzeichnis gefunden hat. http://www.microsoft.com/downloads/details.aspx?FamilyID=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=de > und setzt auf anderen Systemen die Hoffnung > voraus, daß Mono auch richtig installiert wurde. > Außerdem ist nicht alles, was .Net unter Windows bietet, auch mit Mono > nutzbar, Da wird man bestimmt die ein- oder andere Schwierigkeit zu überwinden haben, aber ist das bei anderen Frameworks anders? Wieviel Schwierigkeiten hat Cadsoft mit der Portierung einer (QT) Windows-Anwendung auf Linux gehabt etc.?! > und die MS-Dokumentation geht darauf natürlich ganz und gar > nicht ein. Ist das deren Aufgabe sich darum zu kümmern wie das eigene Zeug auf nachgetrickten .NET Laufzeitumgebungen läuft? Noch dazu wenn solche "Meinungsführer" ideologische Kämpfe austragen: http://www.fsf.org/news/dont-depend-on-mono > Wer aber, der mit .Net-Geraffel anfängt, Kannst du mal bitte aufhören hier immer und immer wieder die gleiche Phrase zu dreschen? > und das auf einem > Windows-System tut, will das mit der Mono-Dokumentation tun? Verstehe ich jetzt nicht??
meine Meinung schrieb: > Da wird man bestimmt die ein- oder andere Schwierigkeit zu überwinden > haben, aber ist das bei anderen Frameworks anders? Wieviel > Schwierigkeiten hat Cadsoft mit der Portierung einer (QT) > Windows-Anwendung auf Linux gehabt etc.?! Wenn sie sauber und vollständig mit/für QT programmiert haben, dann idealerweise garkeine bzw. nur marginale, das ist der Sinn hinter QT. Die QT-API ist für Windows und Linux dieselbe. Sogar für Netzwerkkrams und Threads.
>> Das setzt aber den Verzicht auf die Verwendung von C++ voraus. Die >> Microsoft-Perversion namens "Managed C++" hat vom Namen abgesehen nicht >> viel mit C++ zu tun. > > Und bei QT ist das anders? Ja. Qt schreibt Dir nicht vor, daß Du keinen C++-Compiler verwenden darfst, das .Net-Geraffel aber tut genau das. > Ob hier von der reinen C++ Lehre abgewichen > wird oder nicht ist doch nicht das Maß der Entscheidung Das ist auch nicht der Unterschied. Qt ist mit C++-Compilern beliebiger Herkunft verwendbar, .Net überhaupt nicht. >> Das wars dann auch schon mit "Programmiersprache >> kannst Du Dir aussuchen", das geht eben nur sehr eingeschränkt. > > Das ist eine persönliche Sichtweise. Tatsache ist, .NET ist so > aufgebaut, dass es nicht einer bestimmten Programmiersprache bedarf > (lässt sich in allen Fachbüchern nachlesen). Das stimmt einfach nicht. Das .Net-Geraffel kann nicht mit C* verwendet werden, es kann nicht mit C++ verwendet werden - ich wiederhole es noch mal, "Managed C++" ist kein C++. Das kann kein C++-Compiler übersetzen. >> Außerdem setzt .Net das Vorhandensein der .Net-Umgebung voraus; > > Ja sicher, das ist aber bei allen modernen Windows Installationen > bereits der Fall und wer Programmcode für Windows 98 oder gar Windows 95 > oder .. haben möchte, sollte das von vorneherein schon mitteilen. Das mag zwar sein, aber was ist das für ein Argument? >> das geht >> auf älteren Windows-Systemen mit einem etliche Megabyte großem >> Download-Klumpen einher > > Also das ist jetzt wirklich ein absolut lächerliches Argument und das > weißt du als Insider auch selbst. 23 MB für eine .NET 2.0 > Laufzeitumgebung ist mit jedem DSL Anschluss schneller gesaugt als es > auf der Festplatte sein Zielverzeichnis gefunden hat. Mit der Einstellung verkaufen sich zumindest größere Festplatten und mehr Arbeitsspeicher recht gut. Außerdem wird mit jedem Unterwäschewechsel bei MS eine neue .Net-Laufzeitumgebung fällig; 2.0 ist auch schon etwas angestaubt. Derzeit aktuell ist 3.5, 4.0 ist aber auch schon in der zweiten Beta. >> Außerdem ist nicht alles, was .Net unter Windows bietet, auch mit Mono >> nutzbar, > > Da wird man bestimmt die ein- oder andere Schwierigkeit zu überwinden > haben, aber ist das bei anderen Frameworks anders? Wieviel > Schwierigkeiten hat Cadsoft mit der Portierung einer (QT) > Windows-Anwendung auf Linux gehabt etc.?! Keine Ahnung, aber CadSoft bietet Eagle auch für Mac OS X an. Und wenn die Probleme mit der Portierung ihres Codes gehabt haben, dann muss das ja nun nicht ausschließlich am verwendeten Framework liegen, sondern könnte vielleicht auch was mit dem Alter des Gesamtsystems sein; ich habe schon in der ersten Hälfte der 90er mit Eagle gearbeitet (das damals unter Garantie kein Qt verwendete). Dem Threadersteller geht es aber genau darum, GUI auch für nicht-Windows-Systeme entwickeln zu können. >> und die MS-Dokumentation geht darauf natürlich ganz und gar >> nicht ein. > > Ist das deren Aufgabe sich darum zu kümmern wie das eigene Zeug auf > nachgetrickten .NET Laufzeitumgebungen läuft? Das Argument hast Du nicht verstanden, scheint mir. Wenn man ein GUI-Toolkit erlernen möchte, um es plattformunabhängig zu verwenden, sollte man plattformunabhängige Dokumentation nutzen, oder zumindest welche, die auf Plattformabhängigkeiten hinweist. Und genau das tut die MS-Dokumentation nicht. Ich halte übrigens das "Nachtricksen" der MS-Laufzeitumgebung für einen ähnlich missgeleiteten Ansatz wie Cygwin, das eine Linux-Laufzeitumgebung unter Windows nachbildet. Auch ist fraglich, ob Mono beispielsweise unter ucLinux oder anderen kleinen Embedded-Systemen verwendbar ist - bei GTK+ oder auch Qt ist der Einsatz im Embedded-Bereich aber durchaus realistisch. > Kannst du mal bitte aufhören hier immer und immer wieder die gleiche > Phrase zu dreschen? Wieso sollte ich? Das Zeug wird davon nicht besser. >> und das auf einem >> Windows-System tut, will das mit der Mono-Dokumentation tun? > > Verstehe ich jetzt nicht?? Der Threadstarter schrieb: > (...) möchte bald anfangen, GUI Oberflächen unter Windows > und vielleicht auch unter Linux zu erstellen. Das lässt eine eindeutige Absicht erkennen, sich mit plattformübergreifender Entwicklung zu beschäftigen. Und wenn man so etwas tut, dann sollte man Werkzeuge nutzen, die ohne große Probleme auf allen möglichen Plattformen verfügbar sind. *) Klar, Qt lässt sich auch nicht mit C verwenden, aber das geht mit GTK+. Ob man das will, steht auf einem anderen Blatt.
Hallo, ich würde noch einen weiteren Punkt beachten, und zwar der Speicherverbrauch beim Ausführen der entsprechenden Umgebung. Hierbei vor allem, wenn mehrere Applicationen die gleiche Umgebung verwenden. Wenn ich da an Java denke wirds mir schon ganz anders, bei .Net ist das schon besser. Beim Start von gedit für Windose sind schon mind. 20MB in Benutzung ohne überhaupt eine Datei darin geöffnet zu haben, was mich auch nicht unbedingt überzeugt (Gimp benutze ich trotzdem tägl. unter Win). Für Qt weiß ich grad kein Beispiel, weil ich keinen ernstzunehmenden Win-PC da habe. (Opera und VLC-Player dürften hier reinfallen) mfG
>>> Das setzt aber den Verzicht auf die Verwendung von C++ voraus. Die >>> Microsoft-Perversion namens "Managed C++" hat vom Namen abgesehen nicht >>> viel mit C++ zu tun. >> >> Und bei QT ist das anders? > Ja. Qt schreibt Dir nicht vor, daß Du keinen C++-Compiler verwenden > darfst, das .Net-Geraffel aber tut genau das. Es gibt ein Visual C++ um .NET Code zu erstellen. Darüber hinaus hast du bei Qt lange nicht die Freiheit der Wahl der Programmiersprache wie bei .NET. >> Ob hier von der reinen C++ Lehre abgewichen >> wird oder nicht ist doch nicht das Maß der Entscheidung > Das ist auch nicht der Unterschied. Qt ist mit C++-Compilern beliebiger > Herkunft verwendbar, .Net überhaupt nicht. Es gibt genügend Möglichkeiten .NET Code zu erstellen. >>> Das wars dann auch schon mit "Programmiersprache >>> kannst Du Dir aussuchen", das geht eben nur sehr eingeschränkt. >> >> Das ist eine persönliche Sichtweise. Tatsache ist, .NET ist so >> aufgebaut, dass es nicht einer bestimmten Programmiersprache bedarf >> (lässt sich in allen Fachbüchern nachlesen). > Das stimmt einfach nicht. Das .Net-Geraffel kann nicht mit C* verwendet > werden, es kann nicht mit C++ verwendet werden - ich wiederhole es noch > mal, "Managed C++" ist kein C++. Das kann kein C++-Compiler übersetzen. Vielleicht liest du noch mal den Satz des Posters eingangs, er sagte, er habe mit C++ gerade angefangen. Wer sollte ihr daran hindern sich die Sprache auszusuchen mit der .NET idealerweise harmoniert? >>> Außerdem setzt .Net das Vorhandensein der .Net-Umgebung voraus; >> >> Ja sicher, das ist aber bei allen modernen Windows Installationen >> bereits der Fall und wer Programmcode für Windows 98 oder gar Windows 95 >> oder .. haben möchte, sollte das von vorneherein schon mitteilen. > Das mag zwar sein, aber was ist das für ein Argument? Das ist ein sehr gutes Argument, weil diese OS veraltert sind und es für ein Windows 95 noch nicht mal mehr eine USB Unterstützung geschweige denn sonstige gescheite Treiberunterstützung gibt. Alles was unterhalb W2k angesiedelt ist spielt keine Rolle mehr, so ist das einfach, das nennt sich Fortschritt. >>> das geht >>> auf älteren Windows-Systemen mit einem etliche Megabyte großem >>> Download-Klumpen einher >> >> Also das ist jetzt wirklich ein absolut lächerliches Argument und das >> weißt du als Insider auch selbst. 23 MB für eine .NET 2.0 >> Laufzeitumgebung ist mit jedem DSL Anschluss schneller gesaugt als es >> auf der Festplatte sein Zielverzeichnis gefunden hat. > Mit der Einstellung verkaufen sich zumindest größere Festplatten und > mehr Arbeitsspeicher recht gut. Und was kostet das Zeug heutzutage noch? Im Vergleich zur Hardware von vor 10 Jahren fast nichts mehr und auch Linux profitiert von schneller neuer Hardware genug, sonst würde keine der bunten Oberflächen wie KDE einen Sinn machen. > Außerdem wird mit jedem Unterwäschewechsel bei MS eine neue > .Net-Laufzeitumgebung fällig; 2.0 ist auch schon etwas angestaubt. > Derzeit aktuell ist 3.5, 4.0 ist aber auch schon in der zweiten Beta. Gut dass es Fortschritt gibt. So oft wie neue Linux-Versionen auf den Markt gespült werden, da ist MS vergleichsweise zurückhaltend. >>> Außerdem ist nicht alles, was .Net unter Windows bietet, auch mit Mono >>> nutzbar, >> >> Da wird man bestimmt die ein- oder andere Schwierigkeit zu überwinden >> haben, aber ist das bei anderen Frameworks anders? Wieviel >> Schwierigkeiten hat Cadsoft mit der Portierung einer (QT) >> Windows-Anwendung auf Linux gehabt etc.?! > Keine Ahnung, aber CadSoft bietet Eagle auch für Mac OS X an. Und wenn > die Probleme mit der Portierung ihres Codes gehabt haben, dann muss das > ja nun nicht ausschließlich am verwendeten Framework liegen, sondern > könnte vielleicht auch was mit dem Alter des Gesamtsystems sein; ich > habe schon in der ersten Hälfte der 90er mit Eagle gearbeitet (das > damals unter Garantie kein Qt verwendete). Genau das meinte ich doch. Als es eagle nur für Windows gab hatten sie noch kein Framework verwendet. Seit dem sie QT verwenden braucht es deutlich mehr Rechenleistung, damit die Arbeit noch Spass macht. Merkt man doch schon beim zoomen der 5er Version gegenüber noch den 4.x usw. > Dem Threadersteller geht es aber genau darum, GUI auch für > nicht-Windows-Systeme entwickeln zu können. Der Threadersteller schrieb Zitat ".. und vielleicht auch unter Linux zu erstellen." >>> und die MS-Dokumentation geht darauf natürlich ganz und gar >>> nicht ein. >> >> Ist das deren Aufgabe sich darum zu kümmern wie das eigene Zeug auf >> nachgetrickten .NET Laufzeitumgebungen läuft? > Das Argument hast Du nicht verstanden, scheint mir. Wenn man ein > GUI-Toolkit erlernen möchte, um es plattformunabhängig zu verwenden, > sollte man plattformunabhängige Dokumentation nutzen, oder zumindest > welche, die auf Plattformabhängigkeiten hinweist. > Und genau das tut die MS-Dokumentation nicht. Große Teile von .NET sind PLattform unabhängig, das ist eine Tatsache und man sollte bedenken, dass Mono sich auch noch stark in der Entwicklung befindet. > Ich halte übrigens das "Nachtricksen" der MS-Laufzeitumgebung für einen > ähnlich missgeleiteten Ansatz wie Cygwin, das eine > Linux-Laufzeitumgebung unter Windows nachbildet. > Auch ist fraglich, ob Mono beispielsweise unter ucLinux oder anderen > kleinen Embedded-Systemen verwendbar ist - Weiß ich nicht. Die Entwicklung von Mono (unter Linux) muss man auch wollen, siehe mein Beispiel der Äußerung von Stallman .. > bei GTK+ oder auch Qt ist der > Einsatz im Embedded-Bereich aber durchaus realistisch. Kann sein. >> Kannst du mal bitte aufhören hier immer und immer wieder die gleiche >> Phrase zu dreschen? > Wieso sollte ich? Das Zeug wird davon nicht besser. Weil man es irgendwann einfach nicht mehr lesen kann und du dich cem Verdacht aussetzt IDEOLOGISCH zu argumentieren. .NET ist ein sehr mächtiges Framework und unter WIndows mit Sicherheit durch nichts (MFC usw.) zu toppen. >>> und das auf einem >>> Windows-System tut, will das mit der Mono-Dokumentation tun? >> >> Verstehe ich jetzt nicht?? > Der Threadstarter schrieb: >> (...) möchte bald anfangen, GUI Oberflächen unter Windows >> und vielleicht auch unter Linux zu erstellen. > Das lässt eine eindeutige Absicht erkennen, sich mit > plattformübergreifender Entwicklung zu beschäftigen. > Und wenn man so etwas tut, dann sollte man Werkzeuge nutzen, die ohne > große Probleme auf allen möglichen Plattformen verfügbar sind. .NET IST ohne große Probleme auf Windows verfügbar und darüber hinaus gibt es eine breite Basis an guten Büchern und massig Unterstützung dafür im Netz. Was will man mehr? Und wenn der TE dann seinen Code noch Linux portieren möchte gibt es auch dafür Möglichkeiten. So what? > *) Klar, Qt lässt sich auch nicht mit C verwenden, aber das geht mit > GTK+. Ob man das will, steht auf einem anderen Blatt. Am besten einfach mal der Reihe nach schauen mit was man am schnellsten warm wird. Das muss jeder für sich selbst entscheiden. ;)
> Es gibt ein Visual C++ um .NET Code zu erstellen. Auch wenn Microsoft seine Compiler nennen darf, wie sie das wollen, der Compiler, der .Net-Code erzeugt, ist ein "Managed C++"-Compiler und kein C++-Compiler. Und es gibt gute Gründe, sich mit echtem C++ zu beschäftigen, und nicht mit einem nur sehr oberflächlich ähnlichem Dialekt, weil man damit einerseits Dinge wie boost oder STL nutzen kann, und andererseits auch die Chance hat, Code für kleine Embedded-Systeme zu schreiben. Auch wenn es nicht jedem sinnvoll erscheinen mag, ist es möglich, auf einem Microcontroller in C++ geschriebene Programme laufen zu lassen. Wer aber nicht C++, sondern "Managed C++" erlernt, der fällt beim Versuch, C++-Code zu verstehen, in ein ziemlich tiefes Loch. Wenn es wirklich nur darum ginge, Programme für Windows zu schreiben, bitte, soll man mit .Net machen, wenn's schee macht. Aber so erworbenes Wissen ist extrem Windows-zentrisch, und ich bezweifle stark, daß eine reine Windows-Fixierung eine sinnvolle Bereicherung der eigenen Fähigkeiten ist. Ich verdiene mir mein Geld seit Anfang der 90er Jahre mit der Softwareentwicklung unter Windows (angefangen beim Windows 3.0, mit schnellem Wechsel zu NT 3.1, noch während des Beta-Programmes, unter Auslassung von 95 & Co.) - und das mit recht vollständiger Abhängigkeit von MS-Compilern und der MFC. Aus dieser Erfahrung heraus empfehle ich Neulingen bewusst nicht, sich von MS-Compilern und MS-Klassenbibliotheken abhängig zu machen, schon gar nicht der MFC. Vielleicht auch dadurch begründet, daß ich mich bei privater Nutzung von Windows wegbewege (diese Zeilen schreibe ich auf einem kommerziellen Desktop-Unix), halte ich die Fähigkeit der plattformunabhängigen Entwicklung für wichtig. Und .Net ist zwar auch für andere Plattformen partiell verfügbar, aber das ist keine Plattformunabhängigkeit. Ganz und gar nicht, die Plattform heißt hier .Net und nicht mehr Windows. > Als es eagle nur für Windows gab hatten sie noch kein Framework > verwendet. Seit dem sie QT verwenden braucht es deutlich mehr > Rechenleistung, damit die Arbeit noch Spass macht. Auch das muss nicht primär dem Framework geschuldet sein. Eagle 2.6 war übrigens ein DOS-Programm, Windows kam später. Bei so alten Projekten kann es durchaus sein, daß die Firmenhistorie von Plattform zu Plattform zu Plattform geschleift wird und zwischen das Framework und den Projektkern nur noch mehr Ebenen eingezogen werden, die das Verhalten der vorherigen Umgebung nachbilden, auf daß der Kern nicht an die veränderten Umgebungsbedingungen angepasst werden muss. Ob das bei Eagle so ist, entzieht sich meiner Kenntnis, aber ich habe ausreichend viele große und vergleichbar alte Produkte gesehen, um es nicht für völlig ausgeschlossen zu halten. Also kann die Performance auch an den Verrenkungen liegen, die nötig sind, um das alte Modell in die neue Hülle des komplett anderen GUI-Toolkits zu zwängen.
@Stefan Salewski LOL > auch für GTK+ gibt es Bindings für C++, Ruby, Python. Das plain C ist > daher kein wirklicher Nachteil wie viele meinen, höchstens für die > Entwickler selbst, denn objektorientierte Programmierung mit plain C ist > etwas aufwendig. Hätte man den Kern von GTK gleich in C++ geschrieben > mit dessen objectorientieten Funktionen, so gäbe es eventuell Wer gerne mit MFC programmiert, sollte sich bei GTK+ wie zu Hause fühlen. Man kann GTK+ und QT nicht vergleichen ! Was M$ heute macht, mit C# usw., ist bei QT schon immer mit bei gewesen, nur hat man bei QT auch die Freiheiten von C++. Also, wenn hier verglichen wird dann eher: QT oder C# (und dem M$ GUI gedöhns) oder GTK+ und MFC.
> Ist das deren Aufgabe sich darum zu kümmern wie das eigene Zeug auf > nachgetrickten .NET Laufzeitumgebungen läuft? Noch dazu wenn solche > "Meinungsführer" ideologische Kämpfe austragen: > > http://www.fsf.org/news/dont-depend-on-mono Hast Du den Artikel denn auch gelesen? Dieser Thread ist ein ideologischer Kampf, der verlinkte Artikel eigentlich nicht. Es geht dort "nur" um die (nicht so abwegige) Befürchtung, dass Microsoft eines Tages andere .NET Implementierungen als ihre eigene nicht mehr dulden wird, womit Mono dann mehr oder weniger tot wäre.
@meine Meinung > Es gibt genügend Möglichkeiten .NET Code zu erstellen. Und zeig mir mal die Möglichkeiten der Lauffähigkeit. So einen Schwachsinn habe lange nicht mehr gehört. > Vielleicht liest du noch mal den Satz des Posters eingangs, er sagte, er > habe mit C++ gerade angefangen. Wer sollte ihr daran hindern sich die > Sprache auszusuchen mit der .NET idealerweise harmoniert? .NET harmonisiert nicht sondern bindet nur an ein System, das des Herstellers. > Das ist ein sehr gutes Argument, weil diese OS veraltert sind und es für > ein Windows 95 noch nicht mal mehr eine USB Unterstützung geschweige > denn sonstige gescheite Treiberunterstützung gibt. Alles was unterhalb > W2k angesiedelt ist spielt keine Rolle mehr, so ist das einfach, das > nennt sich Fortschritt. Mit .NET ist das genau so, da war nur vorher klar das das keiner mehr braucht. > Und was kostet das Zeug heutzutage noch? Das nennt sich Globalisierung ! > Im Vergleich zur Hardware von vor 10 Jahren fast nichts mehr und auch > Linux profitiert von schneller neuer Hardware genug, sonst würde keine > der bunten Oberflächen wie KDE einen Sinn machen. Aha, die gab es schon vor KDE und sogar vor DOS. Versteh grad nicht was dir vor 10 Jahren an Farbinformationen gefehlt hat. > Gut dass es Fortschritt gibt. So oft wie neue Linux-Versionen auf den > Markt gespült werden, da ist MS vergleichsweise zurückhaltend. OMG. Zum Glück spült M$ nur dein Hirn und deine Börse. Im Vergleich zu Linux bringt M$ auch bei jedem Update eine neue Version. Das nennt sich dann Patchworkday für die Admins. > Genau das meinte ich doch. Als es eagle nur für Windows gab hatten sie > noch kein Framework verwendet. Seit dem sie QT verwenden braucht es > deutlich mehr Rechenleistung, damit die Arbeit noch Spass macht. Merkt > man doch schon beim zoomen der 5er Version gegenüber noch den 4.x usw. Also ich und meine Schwanzverlängerung haben auch jeden Tag spass, das kann ich dir sagen !!!elfeins!!eleven!!11!11!! > Große Teile von .NET sind PLattform unabhängig, das ist eine Tatsache > und man sollte bedenken, dass Mono sich auch noch stark in der > Entwicklung befindet. Aha, danke für deinen Beitrag. > Weil man es irgendwann einfach nicht mehr lesen kann und du dich cem > Verdacht aussetzt IDEOLOGISCH zu argumentieren. .NET ist ein sehr > mächtiges Framework und unter WIndows mit Sicherheit durch nichts (MFC > usw.) zu toppen. MFC, .NET mhh mehr gibt es doch eh nicht oder ? > .NET IST ohne große Probleme auf Windows verfügbar und darüber hinaus > gibt es eine breite Basis an guten Büchern und massig Unterstützung > dafür im Netz. Was will man mehr? Und wenn der TE dann seinen Code noch > Linux portieren möchte gibt es auch dafür Möglichkeiten. So what? Aha, erzähl mal. Ich dachte es sind nur große Teile und nicht alles !?!?!? > Am besten einfach mal der Reihe nach schauen mit was man am schnellsten > warm wird. Das muss jeder für sich selbst entscheiden. ;) Where do you want to go tomorrow?
> Und es gibt gute Gründe, sich mit echtem C++ zu beschäftigen, Die Frage ist nur, ob diese Gründe für den Thread Ersteller zutreffen. > Wer aber nicht C++, sondern "Managed C++" erlernt, der fällt beim > Versuch, C++-Code zu verstehen, in ein ziemlich tiefes Loch. Na jetzt mal keine Angstkampagne. ;-) Wie man sieht geht es durchaus auch ohne C++, da braucht man nur mal an den Erfolg von Java erinnern. Und was embedded betrifft, da mal ein ganz aktuelles Beispiel. War gestern wegen Weihnachtsgeschenken bei Toys R us (oder wie die sich schreiben). Dort bei den Spielkonsolen WII, Nintendo etc. war ein etwa zwei Schokoladentafeln großes Gerätchen in zartem rosa Platik, das meine Aufmerksamkeit erregte. Aus ein paar Meter Entfernung dachte ich, ah - wieder eines dieser Notebook Imitate, mit den schlechtem grauen, pixeligen Display für 39 Euro ö.ä., sprich pädagogisch Müll etc. Dann mal draufgeschaut und oha, ein schönes klares Display mit einer vollkommenen Windows-Oberfläche. Es lief ein Windows CE drauf. http://de.wikipedia.org/wiki/Microsoft_Windows_CE Kleines Touchpad war vorhanden. Mal schnell bisschen rumgespielt, lief alles auf Anhieb schön. Hätte mir persönlich sogar gefallen (bis auf das rosa Gehäuse ;)). Nur der Preis auf Nachfrage war mit 200 Eur doch etwas zu hoch für mal eben .. Will damit nur sagen, so ein Windows CE wäre mir allemal lieber als was neues wie PalmOS, weil man es kennt und sofort damit arbeiten kann (für viele ist das wichtiger als sich unbedingt von MS abgrenzen zu wollen). Aber jeder kann gerne wie er will ..
@ Karl Heinz (Gast) Auf deinen Schwachsinn und deine Fäkalausdrücke hier einzugehen ist verlorene Zeit, da unterhalte ich mich lieber mit einer Strassenlaterne.
Barbax schrieb: > Hallo, > > ich habe angefangen, c++ zu erlernen und möchte bald anfangen, GUI > Oberflächen unter Windows und vielleicht auch unter Linux zu erstellen. @meine Meinung: Nachdem nun jeder weiß, daß du .NET toll findest, reicht es damit auch. Mit dem Wunsch des TE, evtl auch etwas anderes als Windows machen zu wollen und das noch in C++, hat das mit .NET nun leider ZUMINDEST IN DIESEM FALL nicht viel Sinn. Es wäre schön, wenn du es dabei belassen könntest und nicht noch seitenweise .NET anpreisen würdest, es reicht. > ...
> Es wäre schön, wenn du es dabei belassen könntest und nicht noch > seitenweise .NET anpreisen würdest, es reicht. Ich habe gar nichts "angepriesen". Ich habe darauf hingewiesen das .NET Framework für Windows Programmierung in Betracht zu ziehen, das macht auch für eine Linux-Portierung Sinn, sonst gäbe es kein MONO. Insofern ist dein Einwand fachlich Unsinn. Und mal abgesehen davon, wenn du schon mir diesen Vorwurf machst, dann schau mal wer hier GTK usw. "angespriesen" hat. Der TE wollte IN ERSTER LINIE Software für Windows entwickeln, das solltest du mal beachten bei dem was du mit DEINER gefärbten Brille hier anderen unterstellst. Schönen Abend noch!
Rufus t. Firefly schrieb: >> Es gibt ein Visual C++ um .NET Code zu erstellen. > > Auch wenn Microsoft seine Compiler nennen darf, wie sie das wollen, der > Compiler, der .Net-Code erzeugt, ist ein "Managed C++"-Compiler und kein > C++-Compiler. Falsch! Es gibt keinen Managed-C++-Compiler mehr, nur noch C++/CLI! Zum Nachlesen http://www.gotw.ca/publications/C++CLIRationale.pdf "2.1 Compiling an ISO C++ Program to Metadata An ISO C++ program doesn’t have any CLI types in it, so compiling any ISO C++ program to target CLI basically involves just emitting CLI instructions. An ISO C++ program can be compiled as-is to CLI instruc-tions, including full use of all C++ features including the standard library, multiple inheritance, templates, optional garbage collection for the C++ heap, and other features." oder selbst ausprobieren (zur Not geht auch C++/CLI und ISO-C++ in einer Datei...) > Wer aber nicht C++, sondern "Managed C++" erlernt, der fällt beim > Versuch, C++-Code zu verstehen, in ein ziemlich tiefes Loch. s.o. > Wenn es wirklich nur darum ginge, Programme für Windows zu schreiben, > bitte, soll man mit .Net machen, wenn's schee macht. Aber so erworbenes > Wissen ist extrem Windows-zentrisch, und ich bezweifle stark, daß eine > reine Windows-Fixierung eine sinnvolle Bereicherung der eigenen > Fähigkeiten ist. Die Frage ist, was mittel- und langfristig überhaupt noch von Bedeutung ist. Qt, GTK, wxWidgets jedenfalls nicht. > Vielleicht auch dadurch begründet, daß ich mich bei privater Nutzung von > Windows wegbewege (diese Zeilen schreibe ich auf einem kommerziellen > Desktop-Unix), halte ich die Fähigkeit der plattformunabhängigen > Entwicklung für wichtig. Der Client geht Richtung HTML/JavaScript und .NET, der Backend/Server Richtung Java + .NET, das OS spielt dort nur eine untergeordnete Rolle. KKarl Heinz schrieb: > @meine Meinung > >> Es gibt genügend Möglichkeiten .NET Code zu erstellen. > Und zeig mir mal die Möglichkeiten der Lauffähigkeit. So einen > Schwachsinn habe lange nicht mehr gehört. Eine Liste der Sprachen gibt's z.B. hier http://en.wikipedia.org/wiki/CLI_languages >> Vielleicht liest du noch mal den Satz des Posters eingangs, er sagte, er >> habe mit C++ gerade angefangen. Wer sollte ihr daran hindern sich die >> Sprache auszusuchen mit der .NET idealerweise harmoniert? > .NET harmonisiert nicht sondern bindet nur an ein System, das des > Herstellers. Tolles Argument. Oder portiert hier jemand irgendwas von Qt -> GTK -> wxWidgets -> FLTK -> TK oder anders herum? Diese Bindung existiert immer.
jetzt fängt der nächste damit an! Was hat das bitte mit der Frage zu tun? Ist das hier der Spielplatz für Arbeitslose mit zuviel Zeit?
@ meine Meinung > Auf deinen Schwachsinn und deine Fäkalausdrücke hier einzugehen ist > verlorene Zeit, da unterhalte ich mich lieber mit einer Strassenlaterne. Da du nur Marktetinggeschwätz von dir gibst, könnte ich das das gleiche sagen. Die Realität (Einarbeitungszeit, Schulungen, Softwareprobleme, Teamprobleme etc.) werden von dir einfach nicht beachtet. Du bist ein kleiner dummer Schwätzer. Heut zu Tage ist es doch etwa so: 70% aller Arbeitnehmer werden nach 8h (wenn überhaupt) am Tag den Job an den Nagel hängen, 28% "versuchen" nach der Arbeit noch etwas zu "cheaten", um auf Arbeit gut da zu stehen und 2% haben einen Plan. Und da man nur von Idioten umgeben ist, ist das .NET bei einigen wie eine Droge, die man auch ohne fachliches Wissen einsetzen darf, der Rest macht es ja auch. NEIN DANKE !!!! Und auf deine Rosa-.NET-Geräte habe ich echt keine Bock. Deine Rede dazu habe ich übrigens schon vor einem Jahr gehört ... kannst du mal einen Link dazu schicken oder so ??? Ist offensichtlich nur den Goldständern zugänglich ....
Barbax schrieb: > Ich bin am Übelegen, ob ich dazu mich in die QT4 Bibliothek oder besser > gtk+ einarbeiten sollte. Was würdet Ihr mir empfehlen? Meine Meinung: Nimm Qt. Elegant, umfassende API, gute Dokumentation. Erlaubt strukturiertes und effizientes Programmieren. Jochen Kunz schrieb: > Zum Thema QT vs. GTK: QT ist massive Bloatware. Bloatware ist ein ebenso netter wie unfundierter Ausdruck. Ideologisches Geschwätz halt. Inzwischen ist Qt modular genug, um z.B. die QTL nutzen zu können, ohne die ganzen Klassen für GUI etc. mitnehmen zu müssen. Einen Vorteil von Qt sehe ich in der Abdeckung einer großen Zahl von Bereichen durch das Toolkit. Low-Level- und High-Level Netzwerk-I/O, Datenbankzugriff, usf. - alles unter einem Dach, mit einer konsistenten, interoperablen API, bei der man z.B. nicht überlegen muss, wie man jetzt die asynchronen Events eines speziellen DB-Layers mit dem irgendwie anders gearteten Event Handling einer anderen Bibliothek im Rahmen der verwendeten GUI-Bibliothek mit ihrem wieder eigenen Event-Schema verheiraten kann. > Wenn man mit QT > programmiert, programmiert man für QT. Nicht für Linux, Windows oder > MacOS sondern QT. Und das Problem dabei ist was? > QT ist mitlerweile zu einem "Meta-Betriebssytem" > ausgeufert. Und daraus ergeben sich welche Vor- und Nachteile? Sven P. schrieb: > Und auch, dass QT ganz arg C++ verstümmelt, mit dem Meta-Objekt-Compiler > und so weiter. Oh weiah. Dieses "Argument" gibt es seit vielen Jahren, es ist einfach nicht totzukriegen. Ich kenn C++ jetzt auch schon einige Zeit und als ich Qt noch nicht kannte (aber Java), hab ich mich immer gefragt, warum es kein standadisiertes C++-Pendant zur Java Reflection API gibt. Qt hat doch mit MOC und dem Signals/Slots-Konzept einen Teil dieser Lücke ganz elegant gefüllt. Was ist nun tatsächlich Argument dagegen? Klar, im Lehrbuch steht, dass man in C++ Callbacks über Interfaces regelt usw. Und jetzt??? Iiiiih, dank MOC kennt C++ auf einmal wieder das Feature, einzelne Funktionen (bzw. Methoden) als Callbacks verwenden zu können, so wie im "dummen alten C", so völlig ohne Polymorphie.... Tja, in der Java-Welt hat man das z.B. bei SWT ja nun konsequent vom Lehrbuch abgeschrieben. Und weisst was? Mir geht es jedes mal auf den Keks, wenn ich selbst einfachste Strukturen in zig Klassen zerfasern muss, weil ich für irgendwelch schimmlige Event-Handler wieder irgendein Extra-Objekt benötige. (Gut, es gäbe schon noch andere Möglichkeiten, aber die sind halt auch nicht eleganter.) Ich empfinde Qt incl. MOC als erhebliche Vereinfachung meines Arbeitsalltags. Und ich bin mir sehr sicher, dass ich aus guten Gründen mit dieser meiner Meinung nicht alleine bin. Stephan
PS: Ich finde .NET im Grunde nicht übel. Es ist eine gute Lösung innerhalb der Windowswelt und nach dem ganzen Gemurkse mit Windows-API und Win32-API und MFC endlich mal etwas mit Hand und Fuß. Aber es ist halt exakt auf Windows zugeschnitten. Die Variante mit Mono ist interessant, aber die gleiche Totgeburt als wenn ich die Win-API unter Linux oder OS-X unbedingt nehmen wollte. Wer .NET nimmt, muß wissen, daß er alles nur noch für Windows lernt. Wenn das gewünscht ist, dann ist .NET in Ordnung. Mit Qt kann man unter Windows genauso gut arbeiten (mal mit Vor- oder Nachteilen für das eine oder andere, aber beides wird gut gehen). Nur halt mir dem Unterschied, daß ich bei Qt genau 0.0 auf Windows festgelegt bin.
Stephan M. schrieb: > Sven P. schrieb: >> Und auch, dass QT ganz arg C++ verstümmelt, mit dem Meta-Objekt-Compiler >> und so weiter. > > Oh weiah. Dieses "Argument" gibt es seit vielen Jahren, es ist einfach > nicht totzukriegen. Ich hab persönlich kein Problem mit QT und dem MOC. Meiner Erfahrung nach isses immer etwas ungünstig, wenn irgendwo Quelltext automatisch erzeugt und versteckt wird, auf den man 'idealerweise' keinen Einfluss hat. Normalerweise soll man die Metaobjekte als Entwickler ja garnicht zu Gesicht kriegen. Insofern finde ichs ein wenig schade, dass man den Kram so gelöst hat; ich muss aber ehrlich sagen, dass ich spontan auch keine bessere Idee dazu hätte. Könnte bestenfalls wieder in GUIDs und Fensterklassen und IDL und so nem Kram ausarten, aber das wäre dann auch wieder hässlich.
Sven P. schrieb: > Meiner Erfahrung > nach isses immer etwas ungünstig, wenn irgendwo Quelltext automatisch > erzeugt und versteckt wird, auf den man 'idealerweise' keinen Einfluss > hat. Das ist jetzt keine Kritik an Dir, aber: Früher, in meiner Anfangszeit, hab ich über Codegeneratoren das selbe gedacht. Generierter Code? Neeeeeeeeeeeein, da hab ich ja keine Handhabe! Und wie das wieder aussieht (am besten weil das Ganze Endprodukt irgendeiner wirklich hässlichen XSLT-Transformation ist, die von Codeformatierung keine Ahnung hat)... Und überhaupt und sowieso überlässt nur ein waschechtes Weichei die Codiererei den anderen! Codegenerator? Kann nicht sein, darf nicht sein, soll nicht sein, auf keinen Fall!!11!!!!!!11! lol Inzwischen hab ich so viel Programmcode geschrieben, dass ich sagen kann (und muss): Ich muss nicht unbedingt zum hundertsten mal den selben Mist implementieren. Ich traue mir zu, sagen zu können: Hey, Du weisst dass Du das kannst, jetzt lass das mal jemand anders machen. Am besten also einen Codegenerator, denn der meckert nicht, wenn man ihm Arbeit aufhalst. Ganz Anspruchslos bin ich da allerdings auch nicht. Codegeneratoren müssen funktionierenden Code erzeugen, der eine (dokumentierte) Schnittstelle hat, deren (sauber dokumentierte) Semantiken präzise eingehalten werden. Daneben muss der Codegenerator flexibel und korrekt auf meinen jeweiligen Anwendungsfall reagieren können (bzw. die Unzulänglichkeiten sauber dokumentiert sein). Hier ists halt wie mit einem menschlichen Programmierer: Wenn "er" (also der Codegenerator oder der Mensch) das nicht kann, dann taugt er nix. Und Qt's MOC hat in dieser Richtung bisher immer das gehalten, was Qt versprochen hat und was ich von so einem Tool erwarte. Schaun wir doch mal über den Tellerrand. Was passiert denn seit Jahren im Java-Bereich? Da erzeugt manches Toolkit oder Framework sogar Code zur Laufzeit. (Ganz wie in den schönen alten Zeiten, als Assemblercode noch zur Laufzeit Maschineninstruktionen in den Hauptspeicher schrieb...:-) Und ich muss Dir sagen - was besseres kann Dir eigentlich nicht passieren. Ein Teil der Drecksarbeit - Mediatoren/Adapter/schlagmichtot - geht auf einmal automatisch, ohne dass ich dafür auch nur den kleinen Finger krumm machen müsste. Es geht ja noch weiter: Dämliche, überfrachtete Interfaces implementieren, so dass zig leere Methoden in meinen Klassen rumfliegen, nur weil es das Interface so will? Nein, noch nicht mal das ist mehr notwendig. Die Idee heißt bei Java POJO-Programming, sie hat eine Reihe von Vorteile und kaum tücken. Was will man denn mehr? (Ok, ich wüsst noch was: Umfängliches Reflection, standardisiert, für C++! Und nochwas am Rande: So gesehen hat Qt die Idee des POJO-Programming aufgegriffen; mindestens der Erfolg dieser Idee im Java-Bereich gibt dem ganzen ein gewisses Recht.) Klar, alles hat natürlich auch seine Nachteile, aber ich seh das ganz klar so: Die Vorteile überwiegen deutlich. > Normalerweise soll man die Metaobjekte als Entwickler ja garnicht > zu Gesicht kriegen. Insofern finde ichs ein wenig schade, dass man den > Kram so gelöst hat; ich muss aber ehrlich sagen, dass ich spontan auch > keine bessere Idee dazu hätte. Aha ;-) Na ja im Ernst: Der SW-Entwickler, weder der Profi noch der Amateur, lebt nicht davon, jede einzelne Zeile der Software, die auf einem Computer läuft, selbst angefasst zu haben. In dem Bereich, um den es hier geht, ist (fast) alles eine Frage der Modularität, der Interoperabilität von Modulen sowie der Schnittstellen und ihrer Semantiken. Und da ist es doch wurscht, ob eine Schnittstelle aus einer .so (.dll) kommt, oder ins Codeartefakt des "selbstgemachten" Programmteils über einen Codegenerator reinkommt. > Könnte bestenfalls wieder in GUIDs und Fensterklassen und IDL und so nem > Kram ausarten, aber das wäre dann auch wieder hässlich. Oh bitteschön, das haben wir doch hoffentlich endlich mal hinter uns. Stephan
Vor drei Monaten habe ich mit Qt angefangen. Seitdem habe ich damit eine grafische Netzwerkanwendung mit über 40 kommunizierenden Threads geschrieben. Insgesamt umfasst der Quelltext jetzt ca. 15k Zeilen. Meine Eindrücke: - Der QtCreator bietet eine aufgeräumte, produktive Entwicklungsumgebung. - Eine grosse Auswahl an Beispielimplementierungen kann direkt in den Creator geladen werden. Der Benutzer kann Änderungen an den Beispielen vornehmen und diese sofort testen. - Der integrierte GUI Designer hilft Anfängern beim Erstellen von Eingabemasken. - Nach ein paar Wochen Einarbeitung bin ich dann dazu übergegangen Teile der GUI dynamisch per Programmcode zu erstellen. Auch ein gemischter GUI-Aufbau automatisch generiert und programmgesteuert ist einfach möglich. - Das Signalkonzept ist praktisch, weil es weniger aufwendig ist eine Slotmethode zu erstellen und mit dem Signal einer beliebigen Klasse zu verbinden als den C++ Ansatz von Interfaces zu gehen. - Unter Linux kann der Kompiliervorgang per Skript einfach automatisiert werden. Für Windows werden oft noch zusätzliche Umgebungen wie z.B. Cygwin gebraucht. - Für alle Probleme habe ich Lösungen im Netz gefunden. Soweit meine Eindrücke.
Ich habe auch vor nicht allzu langer Zeit mit C++ angefangen und stand / stehe vor der gleichen Frage. Meine Gedanken dazu, Portierbarkeit , braucht man die? Eigentlich nur für MS und MAC wenn dann. Linux ist als Serverdistri zu betrachten, Marktanteile im CLient Bereich gen 0 . Mac ist das schon was anderes. Was gibt es alles so. MFC, GTK, QT, Wx, (.net) und die OS Apis selbst. Ohne Toolset da mit der Win 32 Api zu arbeiten ist echt müßig. Wx finde ich die Doku mal nicht so toll, alleine die Installation läßt auch jemanden wie mich ( MCSE w2k3/w2k8 update, Linuc Lpic ) , an seinem Talent zweifelln. QT finde ich gut Dokumentiert, Installtion problemlos unter MS sowie unter Linux aus den normalen repros. MFC Super Doku Installation einfach leider etwas altbacken und nicht portierbar. Kosten ca 200,. Euronen .Net Ist ein eigenes Framework ähnlich Jave , Programm läuft in Verwalteter aber sicherer Umgebung. Mann muß sagen es geht kaum schneller und einfacher zu Programmieren. Wenn man c++ kann dauert die Einarbeitung 1-2 Wochen. C++Cli also die MS C++ Option um mit dem .Net zu arbeiten erfordert einen etwas anderen Syntax und ist eigentlich kein C++ . !! Aber was man sagen muß der MS Visuall C++ Compiler Compiliert auch jeden Ansi C++ Code , schluckt auch Boost beinhaltet Tr1 und in der 2010 Version schon die angedachten Änderungen für den neuen C++ Standart. Und man kann in einem Assembly mischen, also Managed Code ans .Net und C++ Standart und auch zwichen den Heaps verschieben. Was einem die eine oder andere Möglichkeit eröffnet. Für reines .Net währe allerdings c# besser zum empfehlen da besser Dokumentiert. VB fürs .net, wer damit klar kommt Ok, nix für mich. Zur .Net Zukunftsicherheit kann man nur sagen , MS hat einfach die Macht ein Produkt in den Markt zu intregrieren. Client Marktanteil über 90 % und im Serverbereich über 70 %. ( Es gibt im Serverbereich mehr als Webserver ). Gut das ganze .net ist nur bedingt Portierbar. aber wehn interessieren Linux Client Benutzer? Mich nicht, Wochenlange Arbeit in etwas zu stecken für ein OS wo Open Source eigentlich voraussetzung ist bei weniger 1 % Marktanteil, nein Danke. Und wozu überhaupt Gui unter Linux ? Da tuts auch Console wenn dann. Mac müßte man bedenken. Also ich für meinen Teil werde mich in QT einarbeiten und mir die Option füs .Net mit CLI offenhalten für reine MS Projekte.
mdmr schrieb: > Gut das ganze .net ist nur bedingt Portierbar. aber wehn interessieren > Linux Client Benutzer? Zum Glück interessieren die schon ab und zu. Viele Betriebe haben sich inzwischen mit Linux angefreundet und sind froh, sich auf diesem Wege Lizenz- und Betriebskosten zu sparen. Ein Produkt sowohl für Windows als auch für Linux anzubieten kann daher ein Wettbewerbsvorteil sein, da Linuxtauglichkeit gelegentlich einen ernst zu nehmenden Sparfaktor für den Kunden darstellt. Trotzdem hast Du recht: In vielen Bereichen ist Linux-Clientsoftware schlicht und ergreifend (höchstens) eine Nische. > Wochenlange Arbeit in etwas zu stecken für ein OS wo Open > Source eigentlich voraussetzung ist bei weniger 1 % Marktanteil, nein > Danke. Und wozu überhaupt Gui unter Linux ? Da tuts auch Console wenn > dann. Manchmal ist auch die Windows-Version einer Applikation das Abfallprodukt der Entwicklung, nicht die Linux-Version - nämlich dann, wenn auf Grund der reichhaltig vorhandenen Tools und Utilities der Entwicklungsprozess unter Linux läuft. Stephan
Es gibt in der Tat einige wenige Firmen die auf Linux umstellen, wohl doch eher aber im Server als im Client Bereich. In beiden Fällen ist es eher eine Politische als Finazielle Entscheidung. Was man an Lizenzkosten sparrt geht für Administrationskosten also Planung/Umsetzung und Pflege doppelt drauf. Lizenzen kann mann allerdings wieder verkaufen, kosten für Arbeit nicht. Und meist steht der Exchange dann doch im Regal weil es quasi keine Alternative gibt und mann Lizensiert dann nochmal zu den Adminkosten dazu ^^.Hauptsache Linux -> Verstand auschalten. Mal angesehen davon sind "Echte Stable" Distris, also Security Testet Code, Suse Enterprise und RH nicht umsonst übersteigen die Kosten für MS Produkte. Dann muß dafür Certifizierte Hardware angeschaft werden, oder wieder selbst Treiber compilieren, dann machen die Distris auch keinen Sinn wenn mann selber Treiber compiliert. Das Produkte unter Linux entwickeld werden für MS Einsatz aufgrund besser verfügbarer Tools ist eher warscheinlich auf den Geschmack des Entwicklers zurückzuführen. Gibt selbst Vi schon für Windows und auch wenn ich in der Lage bin in der Bash ein GZip "zu behandeln" schätze ich den Comfort eines MS Desktop bzw Server OS als Client. Aber um mal Back to Topic zu kommen, bevor man sich den Aufwand für Portierbarkeit macht sollte man Prüfen was man entwickelt und ob überhaupt Portierbarkeit Sinn macht. Was entwickelt man für welchen User ?
> Aber um mal Back to Topic zu kommen, bevor man sich den Aufwand für > Portierbarkeit macht sollte man Prüfen was man entwickelt und ob > überhaupt Portierbarkeit Sinn macht. Was entwickelt man für welchen > User > ? Wenn man ein GUI-Toolkit lernen will, muß man dabei aber auch schon vorher überlegen, ob man nicht vielleicht später (und sei es in ein paar Jahren) doch mal was portables wollen könnte. Wenn man dann nachträglich alles nochmal neu machen und zusätzlich noch ein neues Toolkit lernen muß, weil man vorher nicht an Portabilität gedacht hat, ist das sehr ärgerlich und im kommerziellen Umfeld auch teuer. (und ja, in meinem Umfeld gab es diesen Fall auch schon) Wenn dazu der Aufwand der portablen Lösung praktisch gleich dem der unportablen ist, sollte man sich dann wirklich für die Zukunft den Weg auf andere Plattformen verbauen, nur weil man das im Moment vielleicht nicht braucht?
Stephan M. schrieb: > Manchmal ist auch die Windows-Version einer Applikation das > > Abfallprodukt der Entwicklung, nicht die Linux-Version - nämlich dann, > > wenn auf Grund der reichhaltig vorhandenen Tools und Utilities der > > Entwicklungsprozess unter Linux läuft. Reichhaltiger Tools und Utilitis unter Linux ? Es gibt ne Menge was es unter MS gibt , aber nicht unter Linux , aber eigentlich nix was es unter Linux gibt was es nicht unter MS gibt ^^. Um mal einiges zu nennen: Windows NT = 100% Possix kompatibel wenn das Unix Subsystem installiert ist. Linux läst noch auf sich warten mit der Posix certifizierung. Dementsprechend gibt es die C shell, BSD Korn Shell und System 5 Korn Shell, bleibt nur noch zu erwähnen das es auch alle Shell Tools bietet , sowie Shell Kompiler nach Posix Standart. Da MS auch das einzigste System ist was Posix und Win32 sowie Os2 Api bietet , ist es auch das beste OS für Entwickler. Mag natürlich immer welche geben die über 99 % Marktanteil ignorieren und unter Linux entwickeln, ja Linux hat im Clientbereich unter 1 % Marktanteil der Rest teilt sich unter MS und anderen UNIX wie MAC oder System 5 auf. Mal abgesehen davon, wenn Linux als Client nur halb so stabil und schnell wie der Flame VS MS aus der währe, dann währe Linux schon um einiges weiter. Von 9 Mio Zeilen Code die Privelegiert laufen als Monolytischer Kernel und den Sicherheitsproblemen die sich daraus ergeben will ich gar nicht erst anfangen. Lustig ist nur das gerade die Linux Kom den Redmondern Backdors unterstellt wenn Linux gerade wieder Rootkit geplagt ist , welche meist auch aus den jeweiligen Distri Repos kommen. Und Und und. Ich kann den Linux Quark echt nicht mehr höhren.
Rolf Magnus schrieb: > Wenn dazu der Aufwand der portablen Lösung praktisch gleich dem der > > unportablen ist, sollte man sich dann wirklich für die Zukunft den Weg > > auf andere Plattformen verbauen, nur weil man das im Moment vielleicht > > nicht braucht? Der Aufwand der Portablen Lösung ist nicht gleich, mal abgesehen von Performance gegenüber Win 32 Api, MFC oder auch .Net im vergleich zut GTK( Is schon komisch das Managed Code performanter seien kann als Unmanaged, aber Gnome/KDE User sind anscheinend schlechte Performance gewöhnt ). Auch der Umfang der Toolsets kommt nicht mit denen aus Redmond mit, teuer erkaufte Portabilität. Sowas macht Sinn wenn mann dicke Projekte hat wie Firefox, Skype oder Chrome. Dafür entscheidet man sich in großen Projekten für das eine oder andere Toolset bzw wird dafür eines entwickelt.
@Quarks
> ...will ich gar nicht erst anfangen.
Vielen Dank das ist sehr nett von dir, mehr hätten hier auch niemand
ertragen.
>Wobei ich ganz ehrlich sagen muss: Wenn man/ich mal spaßeshalber so >durch die GNU-Quelltexte durchgucke, also die coreutils (ls, rm, ..), >die Quellen vom GCC, vom Linux-Kernel und so weiter, dann vergeht mir >teilweise echt die Lust, den Kram noch einzusetzen. Da haben die close source Projekte eindeutig einen Vorteil ;-)
Bei solchen Diskussionen ist für mich immer wieder interessant zu sehen, dass für die allermeisten Computernutzer Windows selbstverständlich bis zum jüngsten Tag über 95% Marktanteil haben wird, und alle anderen Systeme ein klägliches Nischendasein führen werden. Ich kann mir das nicht vorstellen.
High Performer schrieb: > Bei solchen Diskussionen ist für mich immer wieder > interessant zu sehen, dass für die allermeisten Computernutzer > Windows selbstverständlich bis zum jüngsten Tag über > 95% Marktanteil haben wird, und alle anderen Systeme ein klägliches > Nischendasein führen werden. Ich kann mir das nicht vorstellen. Genau, die Menschheit entwickelt sich schließlich weiter und wird immer klüger ;-)
Иван S. schrieb: > JFTR: Eine Stimme für WxWindows, > > Iwan Und eine Stimme für dessen endgültige Umbenennung zu wxWidgets mfgkw
High Performer schrieb: >>Wobei ich ganz ehrlich sagen muss: Wenn man/ich mal spaßeshalber so >>durch die GNU-Quelltexte durchgucke, also die coreutils (ls, rm, ..), >>die Quellen vom GCC, vom Linux-Kernel und so weiter, dann vergeht mir >>teilweise echt die Lust, den Kram noch einzusetzen. > > Da haben die close source Projekte eindeutig einen Vorteil ;-) Der ist aber rein psychologischer Natur. Klaus Wachtler schrieb: > Иван S. schrieb: >> JFTR: Eine Stimme für WxWindows, >> >> Iwan > > Und eine Stimme für dessen endgültige Umbenennung zu wxWidgets Eine Stimme gegen die Möglichkeit, sich gewöhnliche Begriffe aus dem täglichen Leben schützen lassen zu können.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.