www.mikrocontroller.net

Forum: PC-Programmierung QT4 oder gtk+ ?


Autor: Barbax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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+).

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gast123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei QT sollte man erwähnen, das es neben den GUI Bibliotheken auch noch 
hunderte andere nützliche Libs gibt (Netzwerk, Datenbankenzugriff usw.).

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)...

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und dann war da noch wxWidgets: http://www.wxwidgets.org/

Damit wurde z.B. der bekannte Audio-Editor Audacity erstellt.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Andre I. (dex) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nicht-Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Seit Nokia QT gekauft hat, ist das auch unter der LGPL verfügbar.
d.h. du darfst auch kommerzielle closed-source Software damit schreiben.

Autor: meine Meinung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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/

Autor: Nil Arm stark (m_oin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bezüglich gtk+ fallen mir noch die folgenden Punkte ein:

-Glade
-GtkBuilder
-OpenGL
-GLib (!) (wurde schon genannt)

Gruß und Kuss,

Autor: Axel Gartner (axelg) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jochen Kunz (jkunz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: meine Meinung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?Fa...

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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: John Small (linux_80)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: meine Meinung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>> 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. ;)

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Karl Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Karl Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: meine Meinung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ..

Autor: meine Meinung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Karl Heinz (Gast)

Auf deinen Schwachsinn und deine Fäkalausdrücke hier einzugehen ist 
verlorene Zeit, da unterhalte ich mich lieber mit einer Strassenlaterne.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

> ...

Autor: meine Meinung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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!

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Karl Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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 ....

Autor: Stephan M. (stephanm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Exakt

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stephan M. (stephanm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gregor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mdmr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stephan M. (stephanm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mdmr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
?

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Quarks (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Quarks (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Quarks

> ...will ich gar nicht erst anfangen.

Vielen Dank das ist sehr nett von dir, mehr hätten hier auch niemand 
ertragen.

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JFTR: Eine Stimme für WxWindows,

Iwan

Autor: High Performer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ;-)

Autor: High Performer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван S. schrieb:
> JFTR: Eine Stimme für WxWindows,
>
> Iwan

Und eine Stimme für dessen endgültige Umbenennung zu wxWidgets

mfgkw

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.