QT4 oder gtk+ ?

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 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.

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/

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.

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.

>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.

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. ;)

@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.

> 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!

@ 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 ....

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.

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.

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:
>>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.