Hallo alle, ich suche Nutzermeinungen zum "besten GUI-Framework" für C++, Open-Source und Crossplattform (mit der Wichtigkeit Win:40%, Linux: 40%, Mac: 10%, Sonstige: Rest). Der Ring ist freigegeben.
Qt ist schon nicht schlecht. Die Installation ist allerdings furchtbar. Außerdem gehört es ja jetzt der bösen Nokia ;-)
Moin,
> Die Installation ist allerdings furchtbar.
Das wäre mir neu. Die Installation aus dem Quellcode ist denkbar
einfach.
Gruss,
Tobi
Kenne Qt und gtk+. Qt ist wesentlich besser. Die Installation ist trivial. Default ist bei Windows allerdings für MinGW. Wer VS Unterstützung braucht muss halt einmal "configure" und "nmake" bemühen.
> Qt ist schon nicht schlecht. Die Installation ist allerdings furchtbar.
Huh? Unter Linux beschränkt es sich üblicherweise darauf, den
Packagemanger zu bemühen, sowas wie "apt-get install libqt4-dev". Unter
Windows lädt man sich das SDK runter, führt den Installer aus und
fertig. Mit dem Mac hab ich keine Erfahrung.
Alternativ falls es für Windows werden soll: http://www.microsoft.com/germany/express/download/webdownload.aspx
QT an sich ist gut. Das C++-Interface ist allerdings eine totale Katastrophe, wenn mans genau nimmt: Diese verborgene Metaobjekt-Erzeugung und so weiter, das hätte man irgendwie besser lösen sollen. GTK+ und wxwidgets sind auch beide nicht verkehrt. QT, GTK(+) und wxwidgets sind vollständig portiert.
Zugegeben das letzte mal, dass ich Qt verwendet habe ist schon ein paar jahre her, aber wie Sven schon sagt finde ich auch die Metaobjekt und Qt-Precompiler Geschichte ist echt furchtbar. Benutze jetzt schon länger wxWidgets und finde es super. Einfach inc- und lib-Pfad zum Projekt schreiben (bei mir VS) und loslegen. Ein Nachteil ist imho das es kein gutes freies GUI-Design Tool gibt (wxFormbuilder ist ein Anfang, aber hat auch seine Schwächen). Wie siehts da eigentlich bei Qt aus? GTK+ habe ich bisher noch nicht getestet.
Andre R. schrieb: > (wxFormbuilder ist ein Anfang, aber hat auch seine Schwächen). Wie > siehts da eigentlich bei Qt aus? Benutze Qt auf Windows mit Developer Studio. Für Qt gibt es den Designer. Der treibt mich regelmässig in den Wahnsinn, wenn er wieder mal Widgets in einem 'Dialog' partout nicht dort ablegt, wo ich sie hin haben will. Kann natürlich auch sein, dass ich das Ding nicht richtig bedienen kann. Mit der Zeit kennt man seine Pappenheimer und weiß, welcher Untergrund wie aufleuchten muss, damit welche Aktion passiert. Aber manchmal, wenn der Designer wieder nervt, ist es einfacher, das Widegt einfach im zugrundeliegenden XML zu verschieben.
Mit "furchtbarer" Installation meine ich, dass es -Fehler gibt (z.B. unter Windows sagt der Installer bei mir gegen Ende "could not write ini file") -Warnungen gibt -configure und make bzw. nmake mal locker 1-2 Stunden braucht -und auch hier gibt es Fehler und Warnungen. Also so wirklich 100% richtig durchgetestet für verschiedene Konfigurationen scheint mir das nicht zu sein. :-/
Fehler gibt es vorwiegend, wenn man den Basispfad ändert (also statt C:\Qt irgend etwas anderes nimmt). Da sind die Installationsroutinen sicher noch verbesserungswürdig.
Ja nun, hartkodierte Pfade sind doch wohl stümperhaft. Das kann ja sogar ich besser ;-)
ich nehme eher an, dass irgendwo die Abfrage auf eine Umgebungsvariable fehlt und deswegen auf den default-Pfad zurückgesprungen wird.
Ich verwende gerne GTK, das bei C++-Pogrammen aber erst in Verbindung mit GTKmm richtig Spaß macht. GTKmm ist ein C++-Wrapper um GTK herum, der leichter zu benutzen und auf Grund seiner durchgängigen Typsicherheit weniger fehleranfälliger als das C-API von GTK ist. Im Gegensatz zu Qt kommt GTKmm völlig ohne C++-Spracherweiterungen¹ und die damit verbundene Präkompilierung aus, was aber hauptsächlich für Sprachpuristen ein Argument darstellen dürfte. Qt ist aber auch nicht schlecht. In meinen Augen sind die Unterschiede zwischen GTK und Qt eher marginal bzw. persönliche Geschmackssache. wxWidgets hat den Vorteil, dass die damit erstellten GUIs das Look&Feel der Plattform haben, für die sie kompiliert werden, da die Bibliothek auf den jeweiligen nativen GUI-Bibliotheken aufsetzt. Karl heinz Buchegger schrieb: > Aber manchmal, wenn der Designer wieder nervt, ist es einfacher, das > Widegt einfach im zugrundeliegenden XML zu verschieben. Die GUI-Designer haben mit der Einführung automatischer Layouter in die GUI-Bibliotheken ohnehin etwas an Bedeutung verloren. Während man bei den MFC unter Windows ohne den GUI-Designer praktisch nicht ausgekommen ist, geht es mit den moderneren GUI-Bibliotheken ohne oft sogar noch etwas schneller. Vor allem hat man aber mehr Flexibilität, weil man bspw. mehrfach benutzte, ähnlich aussehende Gruppen von Eingabeelementen in eine parametrisierte C++-Klasse zusammenfassen kann, so dass das Layout änderungsfreundlicher wird.. ¹) Qt benötigt diese C++-Spracherweiterungen vor allem für das Signal- Slot-Konzept zur Verknüpfung von GUI-Elementen mit der Anwendung. GTKmm realisiert dieses Konzept in der libsigc++ mittels C++-Templates. Dass Qt diese an sich sauberere Lösung nicht ebenfalls benutzt, hängt wohl damit zusammen, dass Qt aus einer Zeit stammt, wo die C++-Templates noch nicht hinreichend standardisiert waren.
> Für Qt gibt es den Designer.
Probier doch mal den QtCreator aus, den Nokia hat eingeführt, bzw. er
kam kurz nach deren Übernahme.
Ansonsten ist es wie hier schon jemand geschrieben hat ->
Geschmackssache.
Ein Framework/Toolkit/wasWeißIch fällt mir noch ein, UPP (ultimate++).
Das ist aber eher ein Exot.
> GTKmm realisiert dieses Konzept in der libsigc++ mittels C++-Templates
Damit zählst du aber auch gleich was mit auf, was an GTK (und GTKmm)
nervt. Viele Dinge muss man sich zusätzlich dazu holen, über weitere
Libs. Das war auch für Nokia nervig (munkelt 'man'), bei Qt hat man fast
alles so dabei.
Bleibt aber alles trotzdem Geschmackssache. ;-)
yalu schrieb: > ¹) Qt benötigt diese C++-Spracherweiterungen vor allem für das Signal- > Slot-Konzept zur Verknüpfung von GUI-Elementen mit der Anwendung. GTKmm > realisiert dieses Konzept in der libsigc++ mittels C++-Templates. Dass > Qt diese an sich sauberere Lösung nicht ebenfalls benutzt, hängt wohl > damit zusammen, dass Qt aus einer Zeit stammt, wo die C++-Templates noch > nicht hinreichend standardisiert waren. Ja und nein. Qt erlaubt aber auch eine Art Reflektion -- das ist z.B. praktisch für den DBUS und so weiter, denn dadurch, dass die Signalnamen und Prototypen vom Qt-Präprozessor hinterlegt werden, kann man später zur Laufzeit auch so Dinger wie 'Zeige mir alle deine Slots' absetzen. Das geht halt mit sigc++ nur bedingt. (Oder hamse das mit sigc++ auch irgendwie hinbekommen? Bin nicht ganz aufm Laufenden)
dagger schrieb: >> GTKmm realisiert dieses Konzept in der libsigc++ mittels C++-Templates > Damit zählst du aber auch gleich was mit auf, was an GTK (und GTKmm) > nervt. Viele Dinge muss man sich zusätzlich dazu holen, über weitere > Libs. Das war auch für Nokia nervig (munkelt 'man'), bei Qt hat man fast > alles so dabei. > Bleibt aber alles trotzdem Geschmackssache. ;-) Ja, vorallem, da sigc++ damals extra für GTKmm entwickelt wurde und der Autor es extra in eine Bilbiothek verpackt hat, damit auch andere Leute Nutzen daraus ziehen können...
> Zugegeben das letzte mal, dass ich Qt verwendet habe ist schon ein > paar jahre her, aber wie Sven schon sagt finde ich auch die > Metaobjekt und Qt-Precompiler Geschichte ist echt furchtbar. Warum? > Für Qt gibt es den Designer. Der treibt mich regelmässig in den > Wahnsinn, wenn er wieder mal Widgets in einem 'Dialog' partout > nicht dort ablegt, wo ich sie hin haben will. Die steckt man doch eh in ein Layout, sodaß sie sich automatisch anpassen.
Da passt man mal einen Tag nicht auf und dann gleich das hier. Vielen Dank für die Hinweise. QT klingt mir immer noch so gruselig wie vor Jahren. Diese schreckliche Verhackstückung von C++, werde ich mich wahrscheinlich nicht dran gewöhnen können. Am besten wir streichen das C++ aus dem Betreff und suchen eine tolle, moderne Sprache, mit breiter Userbase und offenem GUI-Framework ;-) Gruß, Tom
Also ich finde, mit Qt kann man prima arbeiten, kommt zügig voran und hat Code, der leicht zwischen Linux+Windows portierbar ist. Ich arbeite gern damit. Alles Alternativen, die ich bisher gesehen habe, fand ich dagegen ziemlich schwach. Gestört hatte mich lange die schweineteure Lizenz fürt kommerzielle Nutzung, aber das ist ja Geschichte.
Naja, ich will ganz sicher nicht bestreiten, dass man mit QT gut vorankommt, gar keine Frage. Aber wenn man möchte, kommt man mit GTKmm genauso schnell voran und das auch ohne Präprozessor-Voodoo :-) Wie gesagt, das Voodoo bei QT hat da andere Gründe und es hat auch einige Vorteile.
Rolf Magnus schrieb: > Die steckt man doch eh in ein Layout, sodaß sie sich automatisch > anpassen. Schon. Aber du musst die Widgets mit der Maus erst mal in der richtigen Reihenfolge in das übergeordnete Layout Objekt reinkriegen :-) Es ist nicht besonders lustig, wenn in ein bestehendes Horizontal-Layout in dem schon ein Widget steckt, links davon noch ein Widget reinhaben willst und der Designer reiht es dir zum 20-ten mal rechts davon an. Egal wieviel Mühe du dir gibst, das Schei*&%"!# Label möglichst sauber zwischen Edit-Feld und Layout-Begrenzung fallen zu lassen :-) Nicht falsch verstehen: Ich will Qt keineswegs schlecht machen. Das ist eine Handling-Frage in einem Teilbereich des Pakets 'Qt' Was mich auch ein wenig stört: Man kann mit dem SIGNAL / SLOT Konzept auch Fehler machen, die weder vom Compiler noch vom Linker angemeckert werden und dazu führen, dass die gewünschte Funktion einfach nicht aufgerufen wird. Das war zwar bei den MFC-Windows Messages auch so, aber da war das irgendwie klarer, da die Sender/Empfänger Kopplung von Haus aus weit lockerer ist. Was ich am Anfang als Segen empfand, meine Meinung aber geändert habe: Es muss eine Stelle im Programm geben, die Sender und Empfänger miteinander bekannt macht (die den connect macht). Klingt auf den ersten Blick gut. Ist man aber die MFC gewohnt, so ist das in der MFC (für mich) eigentlich einfacher. Irgendjemand setzt eine Message ab, irgendjemand fischt sich diese Message raus. Der Empfänger muss nur wissen, dass diese Message im System existiert. Niemand muss wissen, wer sich welche Message schnappt. Tausche ich den Sender gegen einen anderen Sender aus, der die gleiche Message schickt, dann tangiert das niemand anderen im Gesamtsystem. Das muss niemand wissen. Hauptsache die Message wird weiterhin in die Queue gestellt.
> Es ist nicht besonders lustig, wenn in ein bestehendes > Horizontal-Layout in dem schon ein Widget steckt, links davon noch ein > Widget reinhaben willst und der Designer reiht es dir zum 20-ten mal > rechts davon an. Egal wieviel Mühe du dir gibst, das Schei*&%"!# Label > möglichst sauber zwischen Edit-Feld und Layout-Begrenzung fallen zu > lassen :-) Hmm, ich geb zu, daß es manchmal etwas hakelig ist, aber so problematisch erschreint mir das nicht. Allerdings tendieren komplexere Layouts bei mir dazu, nur teilweise im Designer gemacht zu werden, weil ich meist doch mehr Flexibilität brauche oder eh soviele Custom-Widgets hab, daß es sich nicht mehr lohnt. > Man kann mit dem SIGNAL / SLOT Konzept auch Fehler machen, die weder > vom Compiler noch vom Linker angemeckert werden und dazu führen, dass > die gewünschte Funktion einfach nicht aufgerufen wird. Das wird einem aber beim Aufruf des Connect zur Laufzeit auf die Konsole gespuckt. Ist allerdings unter Linux. Wo unter Windows die Debug-Ausgaben hinwandern (das was man mit qDebug() oder qWarning() ausgibt), weiß ich nicht. > Das war zwar bei den MFC-Windows Messages auch so, aber da war das > irgendwie klarer, da die Sender/Empfänger Kopplung von Haus aus weit > lockerer ist. Naja, mit Qt kann ich zur Laufzeit eine Verbindung Signal<->Slot aufbauen und auch jederzeit wieder trennen. Ich kann im Prinzip die Signale und Slots sogar zur Laufzeit auswählbar machen, oder z.B. ein ui-File ohne vorherige Konvertierung nach C++ direkt zur Laufzeit reinladen (QUiLoader) und dann die Signale und Slots per Objekt- und Signal-/Slot-Namen in Strings dynamisch verbinden. Viel lockerer kann die Kopplung eigentlich kaum sein. [MFC] > Irgendjemand setzt eine Message ab, irgendjemand fischt sich diese > Message raus. Der Empfänger muss nur wissen, dass diese Message im > System existiert. Niemand muss wissen, wer sich welche Message > schnappt. Tausche ich den Sender gegen einen anderen Sender aus, der > die gleiche Message schickt, dann tangiert das niemand anderen im > Gesamtsystem. Das muss niemand wissen. Hauptsache die Message wird > weiterhin in die Queue gestellt. So richtig verstehe ich das nicht. Vielleicht hilft ein einfaches Beispiel. Nehmen wir einen Slider an und eines von diesen schicken LCD-Ziffern-Widgets, das mir den Wert vom Slider anzeigen soll. Wo kommt jetzt die Verbindung her, die dafür sorgt, daß genau dieses eine Anzeige-Widget von geanu diesem einen Slider die Werte bekommt?
Ich denke über ein ähnliches Projekt nach. Ich werde auf jeden Fall Qt verwenden, weil das einfach das ausgereifteste und umfangreichste ist. Da nehm ich das Geturne mit den Makros in kauf.
Ich kann nur mehr Qt empfehlen! Wenns unter Windows mit dem Vc++ Compiler laufen soll: Beitrag "[QT] Installation von QT unter Windows mit MSVC Compiler"
Offensichtlich kennen nur sehr wenige wxWidgets oder warum wird hier so häufig QT empfohlen? QT habe ich mir auch mal kurz angesehen und fand das Ganze ziemlich frickelig. wxWidgets setzt auf den nativen Bibliotheken der jeweiligen Plattform auf, bietet daher auch das jeweilige Look & Feel, ist schlank (weil nur eine Art Wrapper) und mindestens so ausgereift wie QT. Damit mache ich seit Jahren alle meine GUI-Projekte.
wx ist nicht schlecht, keine Frage. Aber Qt ist wesentlich umfangreicher. Mir fehlt bei wx (AUI) z.B. die Möglichkeit, die Dockable Panels zu "stapeln". Man kann sie zwar übereinander oder nebeneinander anordnen, aber man kann sie nicht übereinander legen. Deshalb ist z.B. bei Editra der "Shelf" Hack nötig, was bei Qt überflüssig ist. Außerdem gibt es bei Qt so mächtige Widgets wie GraphicsView oder Module wie MultiThreading, Plugins, MVC und Datenbankgeschichten usw. Klar, vieles davon gibt es auch als Stand Alone Libraries, aber bei Qt ist alles "aus einem Guss" und macht weniger Arbeit. Und mir gefällt das "Signals and Slots" Konzept von Qt besser.
Für mich stellt sich immer die Frage, ob ich das alles wirklich unbedingt brauche, was QT noch mitbringt oder ob ich nicht einfach die wesentlich schlankere und auf nativen Betriebssystembibliotheken aufsetzende wxWidgets nehme. Ich habe mich damals für Letzteres entschieden, weil mich schon das undurchsichtige qmake-Zeugs gestört hat und ich auch das "Signals und Slots"-Konzept nicht so überzeugend fand. Bis vor kurzem stand auch die Lizenzpolitik von QT einer Nutzung entgegen, erst seit kurzem gibt es das auch unter der LGPL. Bei wxWidgets gibt es übrigens auch eine ganze Menge an Funktionen über die GUI-Funktionen hinaus (Multithreading, ODBC-Schnittstelle, usw.) und Addons dazu. Siehe auch hier, ein kurzer Überblick (von 2005, seitdem hat sich auch noch einiges getan): http://www.wxwidgets.org/about/datasheets/wxWidgetsOverview.pdf
Wirklich Nativ ist wx auch nicht. Unter Linux wird auf GTK aufgesetzt. Unter KDE also auch wieder ein "Umweg", um nativen Look&Feel zu bekommen. AUI ist afaik überhaupt nicht nativ sondern rendert selbst. Und seit Qt4.5 passt sich Qt wunderbar in einen GTK Desktop. Aber weder Größe (vor allem in der heutigen Zeit) noch "Nativität" sind für mich ausschlaggeben. Und wieso alle Leute solche Probleme mit der GPL haben verstehe ich auch nicht. Wenn man privat programmiert spielt es keine Rolle und wenn man Geld damit verdienen will darf man einen Teil davon ruhig mal an den Entwickler abgeben. Von qmake bekommt man mit dem Qt-Creator nicht viel mit. Man muss nur die Makros an den richtigen Stellen einfügen. Mit PyQt hat man damit gar nichts zu tun. Die Implementierung ist noch einfacher als die für C++. Für mich zählt letztendlich nur die Funktionalität. Warum soll ich heute Tkinter lernen, weil es mir für das aktuelle Projekt ja völlig ausreicht und morgen muss ich etwas programmieren, was Tkinter nicht mehr leistet? Und so lange AUI die Dockable Panels nicht stapeln kann ist es für mich eh unbrauchbar
Michael S. schrieb: > wxWidgets setzt auf den nativen Bibliotheken der jeweiligen Plattform > auf, bietet daher auch das jeweilige Look & Feel, ist schlank (weil nur > eine Art Wrapper) und mindestens so ausgereift wie QT. Damit mache ich > seit Jahren alle meine GUI-Projekte. Sehe ich das richtig, dass wxWidgets keine Autorskalierung der GUI macht?
Markus Burrer schrieb: > Aber weder Größe (vor allem in der heutigen Zeit) noch "Nativität" sind > für mich ausschlaggeben. Und wieso alle Leute solche Probleme mit der > GPL haben verstehe ich auch nicht. Wenn man privat programmiert spielt > es keine Rolle und wenn man Geld damit verdienen will darf man einen > Teil davon ruhig mal an den Entwickler abgeben. Hm, deine Unterscheidung zwischen "privat" und *Geld verdienen" legt nahe, dass du dich mit der GPL ueberhaupt noch nicht beschaeftigt hast. Falls du anderer Meinung bist, wuerde ich mich ueber eine rechtlich bestaetigte Definition von "derived work" freuen... gleiches gilt fuer die hier eher relevante Kompatibilitaet zwischen LGPL und GPL.
Markus Burrer schrieb: > Aber weder Größe (vor allem in der heutigen Zeit) noch "Nativität" sind > für mich ausschlaggeben. Und wieso alle Leute solche Probleme mit der > GPL haben verstehe ich auch nicht. Wenn man privat programmiert spielt > es keine Rolle und wenn man Geld damit verdienen will darf man einen > Teil davon ruhig mal an den Entwickler abgeben. Hm, deine Unterscheidung zwischen "privat" und *Geld verdienen" legt nahe, dass du dich mit der GPL ueberhaupt noch nicht beschaeftigt hast. Falls du anderer Meinung bist, wuerde ich mich ueber eine rechtlich bestaetigte Definition von "derived work" freuen...
Unter "privat" verstehe ich, dass man nur für sich selbst programmiert oder OpenSource. In beiden Fällen sehe ich keine nennenswerten Nachteile der GPL. Will man Geld verdienen wird man von der GPL zur Weitergabe des Sourcecodes verdonnert, was meistens nicht erwünscht ist. Qt bietet als Alternative eine kommerzielle Lizenz, die natürlich Geld kostet. Was ist daran unklar?
Markus Burrer schrieb: > ... > Will man Geld verdienen wird man von der GPL zur Weitergabe des > Sourcecodes verdonnert, was meistens nicht erwünscht ist. Nein, nicht mehr. Es gibt inwischen auch die Variante mit der LGPL. Da zahlt man nichts für Qt, kann Programme entwickeln und weitergeben, ohne den Quelltexte herauszurücken, und muß lediglich Änderungen an Qt veröffentlichen, was ja i.d.R. kein Problem sein wird. http://qt.nokia.com/products/licensing/licensing
Markus Burrer schrieb: > Unter "privat" verstehe ich, dass man nur für sich selbst programmiert > oder OpenSource. In beiden Fällen sehe ich keine nennenswerten Nachteile > der GPL. Dann musst du dich damit beschaeftigen. Will ich z.B. wirklich freie Software schreiben, scheidet die Verwendung von unter GPL stehenden Teilen aus. Nicht umsonst gibt es noch diverse andere Lizenzen im OS-Bereich. > Will man Geld verdienen wird man von der GPL zur Weitergabe des > Sourcecodes verdonnert, was meistens nicht erwünscht ist. > Was ist daran unklar? Das ist schlicht und einfach falsch. Die GPL macht ueber kommerziell/nicht-kommerziell ueberhaupt keine Aussage, lediglich ueber die Weitergabe. Und meine beiden wirklich interessanten Fragen hast du ja einfach gestrichen, statt sie zu beantworten...
Klaus Wachtler schrieb: > Nein, nicht mehr. > Es gibt inwischen auch die Variante mit der LGPL. Weiß ich. Aber das ist ja erst seit kurzem. Bisher war das Hauptargument der meisten GEGEN Qt fast immer nur die GPL. Ich bezog mich auf einen Kommentar von msk > Bis vor kurzem stand auch die Lizenzpolitik von QT einer Nutzung > entgegen, [..] "Warum?", frage ich mich. Für private oder OpenSource Projekte spielt es praktisch keine Rolle ob GPL oder LGPL. Es geht doch nur um's Geld. Geld verdienen, aber selber nix zahlen wollen. Einzige Ausnahme, wo ich Verständnis habe ist, wenn man nur ein einzelnes oder wenige Projekte machen will, deren Einnahmen schon durch die Lizenzkosten aufgefressen würden.
Peter Stegemann schrieb: > Das ist schlicht und einfach falsch. Die GPL macht ueber > kommerziell/nicht-kommerziell ueberhaupt keine Aussage, lediglich ueber > die Weitergabe. Die GPL verbietet kommerzielle Nutzung nicht. Aber sie verpflichtet den Entwickler, dem "Kunden" auf Nachfrage den kompletten Sourcecode auszuhändigen. Und welcher Entwickler kommerzieller Software will das? > Und meine beiden wirklich interessanten Fragen hast du > ja einfach gestrichen, statt sie zu beantworten... Du hast in den letzten Beiträgen nur eine Frage gestellt, und die habe ich nicht verstanden > Sehe ich das richtig, dass wxWidgets keine Autorskalierung der GUI macht? Was ist eine AUTORskalierung?
Peter Stegemann schrieb: > Will ich z.B. wirklich freie > Software schreiben, scheidet die Verwendung von unter GPL stehenden > Teilen aus. Frei nach George Orwell's "Farm der Tiere" GPL ist frei, aber BSD ist freier.
>> Das ist schlicht und einfach falsch. Die GPL macht ueber >> kommerziell/nicht-kommerziell ueberhaupt keine Aussage, lediglich ueber >> die Weitergabe. > Die GPL verbietet kommerzielle Nutzung nicht. Aber sie verpflichtet den > Entwickler, dem "Kunden" auf Nachfrage den kompletten Sourcecode > auszuhändigen. Und welcher Entwickler kommerzieller Software will das? Es gibt genügend Firmen die mit diesem Prinzip gut leben können. >> Unter "privat" verstehe ich, dass man nur für sich selbst programmiert >> oder OpenSource. In beiden Fällen sehe ich keine nennenswerten Nachteile >> der GPL. > Dann musst du dich damit beschaeftigen. Will ich z.B. wirklich freie > Software schreiben, scheidet die Verwendung von unter GPL stehenden > Teilen aus. Nicht umsonst gibt es noch diverse andere Lizenzen im > OS-Bereich. Bitte kein was-ist-wirklich-freie-Software-Geflame, da niemand so etwas jemals endgültig deklarieren kann, kann es auf diese Diskussion keine allgemein gültige Antwort geben.
Markus Burrer schrieb: > Wirklich Nativ ist wx auch nicht. Unter Linux wird auf GTK aufgesetzt. > Unter KDE also auch wieder ein "Umweg", um nativen Look&Feel zu > bekommen. AUI ist afaik überhaupt nicht nativ sondern rendert selbst. > Und seit Qt4.5 passt sich Qt wunderbar in einen GTK Desktop. Unter Linux gibt es nicht die native Oberflächenbibliothek, sondern mehrere. wx unterstützt sowohl QT als auch X11. wxAUI ist nur eine Zugabe und nicht wx selbst. Insofern alles bestens. > Aber weder Größe (vor allem in der heutigen Zeit) noch "Nativität" sind > für mich ausschlaggeben. Und wieso alle Leute solche Probleme mit der > GPL haben verstehe ich auch nicht. Wenn man privat programmiert spielt > es keine Rolle und wenn man Geld damit verdienen will darf man einen > Teil davon ruhig mal an den Entwickler abgeben. Für Bibliotheken ist die LGPL die Lizenz, die am besten passt und dafür geschaffen wurde. > Von qmake bekommt man mit dem Qt-Creator nicht viel mit. Man muss nur > die Makros an den richtigen Stellen einfügen. Mit PyQt hat man damit gar > nichts zu tun. Die Implementierung ist noch einfacher als die für C++. > > Für mich zählt letztendlich nur die Funktionalität. Warum soll ich heute > Tkinter lernen, weil es mir für das aktuelle Projekt ja völlig ausreicht > und morgen muss ich etwas programmieren, was Tkinter nicht mehr leistet? > Und so lange AUI die Dockable Panels nicht stapeln kann ist es für mich > eh unbrauchbar Sorry, aber stapelbare, andockbare Panels machen für mich die ganzen Nachteile von QT nicht wett.
Peter Stegemann schrieb: > Sehe ich das richtig, dass wxWidgets keine Autorskalierung der GUI > macht? Bitte beschreibe, was Du unter "Autorskalierung" verstehst. Ich kann mit dem Begriff nix anfangen...
Markus Burrer schrieb: > "Warum?", frage ich mich. Für private oder OpenSource Projekte spielt es > praktisch keine Rolle ob GPL oder LGPL. Es geht doch nur um's Geld. Geld > verdienen, aber selber nix zahlen wollen. Nö, es geht einfach darum, die Freiheit zu haben, auch Teile von privaten Spaßprojekten weitergeben oder verkaufen zu können, ohne dabei irgendwelche kommerziellen Verwertungseinschränkungen beachten zu müssen. Ich habe auch schon Code veröffentlicht und mit Fehlermeldungen und Konfigurationen bei offenen Projekten mitgeholfen. Ich habe wirklich kein Problem damit, meine Quellen anderen zu Verfügung zu stellen. Es widerstrebt mir aber, Bibliotheken zu nutzen, die künstlich in ihrer Lizenz eingeschränkt wurden, obwohl es Lizenzen wie die LGPL gibt. > Einzige Ausnahme, wo ich Verständnis habe ist, wenn man nur ein > einzelnes oder wenige Projekte machen will, deren Einnahmen schon durch > die Lizenzkosten aufgefressen würden. Eben.
Col. Trautman schrieb: > Es gibt genügend Firmen die mit diesem Prinzip gut leben können. Dann ist ja gut, wenn sie damit leben können. Das untermauert doch meine Frage nur. Wo ist das Problem mit der GPL? Warum wurde Qt von vielen erst akzeptiert, nachdem es die LGPL verwendet? > Bitte kein was-ist-wirklich-freie-Software-Geflame, da niemand so etwas jemals > endgültig deklarieren kann, kann es auf diese Diskussion keine allgemein gültige > Antwort geben. Warum, die Grundaussagen der drei wichtigsten Lizenzen sind eigentlich relativ eindeutig. GPL: Was GPL ist bleibt GPL. Wenn GPL eingesetzt wird muss das gesamte Produkt unter die GPL gestellt werden. LGPL: Was LGPL ist bleibt LGPL. Wenn LGPL eingesetzt wird muss dies als Source weitergegeben werden. Eigene Sourcen können unter eine andere Lizenz gestellt werden. BSD: Nimm alles und mach damit was du willst. Ich bitte die freie Interpretation zu entschuldigen. Es geht mir nur um die Verdeutlichung des Grundgedanken. Ausnahmen und ähnliche Feinheiten wie die unterschiedlichen BSD Versionen habe ich mal außen vor gelassen. Und bitte entschuldigt, wenn ich darauf so rumreite, aber das Thema ist für mich ein rotes Tuch weil ich Leute kenne, die nicht einsehen, dass sie für Software was zahlen sollen. Aber wenn sie selbst was programmieren sollen halten sie die Hand auf. Die hätten am liebsten alles nur unter der liberalsten BSD, damit sie sich in Ruhe die Rosinen rauspicken und dann teuer verkaufen können. Eine Einstellung, die ich nicht akzeptiere. Wenn jemand aus freien Stücken seine Arbeit als BSD unter die Leute wirft ist das in Ordnung. Aber wenn jemand sagt, "ich stelle meine Arbeit kostenlos zur Verfügung, aber wenn jemand damit Geld verdienen will möchte ich einen Anteil" akzeptiere ich das genauso. Michael S. schrieb: > Sorry, aber stapelbare, andockbare Panels machen für mich die ganzen > Nachteile von QT nicht wett. Welche Nachteile? Ich hab noch keine gefunden. Und stapelbare Docking Panels sind für einige meiner Projekte KO Kriterien. wx scheidet aus weil es gar nicht geht und GTK ist einfach nur katastrophal zu programmieren.
Michael S. schrieb: > Nö, es geht einfach darum, die Freiheit zu haben, auch Teile von > privaten Spaßprojekten weitergeben oder verkaufen zu können, ohne dabei > irgendwelche kommerziellen Verwertungseinschränkungen beachten zu > müssen. Wie ich schon sagte. Wenn jemand freiwillig seine Arbeit als LGPL oder BSD veröffentlicht ist das in Ordnung. > Ich habe auch schon Code veröffentlicht und mit Fehlermeldungen > und Konfigurationen bei offenen Projekten mitgeholfen. > Ich habe wirklich kein Problem damit, meine Quellen anderen zu Verfügung > zu stellen. Ich auch nicht, wie man z.B. hier sehen kann http://avr-gcc-library.svn.sourceforge.net/viewvc/avr-gcc-library/trunk/EP-gcc-lib/systick.c?revision=19&view=markup > Es widerstrebt mir aber, Bibliotheken zu nutzen, die > künstlich in ihrer Lizenz eingeschränkt wurden, obwohl es Lizenzen wie > die LGPL gibt. Wie sagte Mr. Spock in Star Trek 5? > "Weil er da ist" ist keine ausreichende Begründung, um auf > diesen Berg zu klettern
Markus Burrer schrieb: > Ich auch nicht, wie man z.B. hier sehen kann > http://avr-gcc-library.svn.sourceforge.net/viewvc/avr-gcc-library/trunk/EP-gcc-lib/systick.c?revision=19&view=markup Ein bisschen Eigenwerbung kann nie schaden, wie? ;) > Wie sagte Mr. Spock in Star Trek 5? > >> "Weil er da ist" ist keine ausreichende Begründung, um auf >> diesen Berg zu klettern Passt leider nicht als Antwort. > Welche Nachteile? Ich hab noch keine gefunden. Ich schon. Das undurchsichtige Gehampel mit qmake, bis vor kurzem die Lizenzen, keine Nutzung der nativen GUI-Bibliotheken (außer Linux). wxWidgets erschien mir schon immer schlanker und ausgereifter. Überhaupt finde ich das Konzept von wxWidgets, möglichst die nativen Bibliotheken der jeweiligen Betriebssysteme zu nutzen, deutlich besser als das Mitschleppen irgendwelcher fetten Bibliotheken mit tausend Abhängigkeiten, nur weil man mal ein kleines Progrämmchen unter System xyz nutzen will. BTW: Hast Du mal ein Beispiel dafür, was Du unter stapelbaren Docking-Panels genau verstehst?
Kann ja jeder machen wie er will. Wenn dir wx gefällt ist es doch gut. Mir gefällt Qt eigentlich recht gut, qmake finde ich gruselig. Deshalb nehme ich Qt, aber nicht qmake. Ein makefile für das normale make ist ja auch schnell geschrieben bzw. wird jeweils von einem anderen Projekt zweckentfremdet.
Michael S. schrieb: [..] Ich schenkt mir mal die weitere Diskussion > BTW: Hast Du mal ein Beispiel dafür, was Du unter stapelbaren > Docking-Panels genau verstehst? Nehmen wir als Beispiel diesen Screenshot vom AVR Studio. Das kann das z.B. auch http://folk.uio.no/geirfrs/FYS3240/Oblig2/Bilder/AVR%20Studio.jpg Watch, Memory, Output, Register und Workspace sind Docking Panels. Die kann man nebeneinander und übereinander anordnen. Aber man kann sich auch "aufeinander" legen. Dann werden sie angezeigt wie Project, I/O und Info im Workspace. Wenn ich möchte könnte ich I/O aber auch aus dem Workspace rausziehen und rechts vom Editorfenster ablegen. wx kann das zwar auch, aber nur mit Hilfe von AUI und ohne das "aufeinanderlegen". Besonders ärgern tut mich das auf meinem Laptop, wenn ich Editoren wie Gedit oder Geany verwende. Die haben links und unten statische Panels, auf denen man mit Tabs zwischen verschiedenen Anzeigen umschalten kann. Auf meinem Laptop mit WideScreen wird in der Breite Platz verschwendet (schraffierter Bereich) und in der Höhe fehlt mir was http://roboter-gallery.de/pub/gedit.png Lieber wäre mir, wenn ich z.B. die Dateiverwaltung und einen Class Browser nebeneinander legen könnte und das Terminal darunter. So hätte ich die Breite ausgenutzt und mir steht mehr Höhe zur Verfügung. Die Flexibilität habe ich bei wx eben nicht. Editra ist ein schönes Beispiel für ein wx Programm. Ich kann zwar Quellbrowser, Projekt, Dateimanager usw wunderbar überall andocken, aber nicht platzsparend aufeinanderlegen, wenn ich das möchte. Editra wäre so toll, aber diese Einschränkung hat mich schon mehr als einmal gestört. Eclipse zeigt, wie es gehen könnte. Beliebige Anordnung der Panels rund um das Center Widget. http://www.ilimitado.de/blog/wp-content/uploads/2007/09/php-debugger-dbg-eclipse-debug-perspective.gif
Angehängte Dateien:
-
codeblocks.jpg
150 KB
Also ich bin nicht sicher, ob ich jetzt richtig verstanden habe, was genau Du meinst: Das weitestgehend freie Platzieren von Unterfenstern über- und nebeneinander innerhalb des Programmfensters? Also das geht bei Codeblocks zum Beispiel und das basiert auf wxWidgets. Siehe Screenshot: Die Fenster Management, Logs & Others und Manpage Viewer kann ich weitesgehend frei innerhalb des Programmfensters anordnen und die Größe ändern. Aufeinanderlegen geht auch - siehe Screenshot 2, da ist "Search Results" unten im Logfenster herausgelöst.
Angehängte Dateien:
-
codeblocks2.jpg
140 KB
Anbei der zweite Screenshot, zwei Dateianhänge pro Beitrag geht wohl nicht...
Michael S. schrieb: > Aufeinanderlegen geht auch - siehe Screenshot 2, da ist "Search Results" > unten im Logfenster herausgelöst. Und wie geht das? Bei mir tut sich da nix
>> Es gibt genügend Firmen die mit diesem Prinzip gut leben können. > Dann ist ja gut, wenn sie damit leben können. Das untermauert doch meine > Frage nur. > Wo ist das Problem mit der GPL? Warum wurde Qt von vielen erst > akzeptiert, nachdem es die LGPL verwendet? Ich habe da doch auch kein Problem mit. ;-) >> Bitte kein was-ist-wirklich-freie-Software-Geflame, da niemand so etwas >> jemals endgültig deklarieren kann, kann es auf diese Diskussion keine >> allgemein gültige Antwort geben. > > Warum, die Grundaussagen der drei wichtigsten Lizenzen sind eigentlich > relativ eindeutig. > > GPL: Was GPL ist bleibt GPL. Wenn GPL eingesetzt wird muss das gesamte > Produkt unter die GPL gestellt werden. > > LGPL: Was LGPL ist bleibt LGPL. Wenn LGPL eingesetzt wird muss dies als > Source weitergegeben werden. Eigene Sourcen können unter eine andere > Lizenz gestellt werden. > > BSD: Nimm alles und mach damit was du willst. Für mich ist das alles frei, jede hat halt Bedingungen mit den man leben muss oder was anderes nimmt. > Ich bitte die freie Interpretation zu entschuldigen. Es sei dir verziehen. ;-)
Kann auch nur sagen, dass wxWidgets mit CodeBlocks als IDE und GUI Designer gut funktioniert. Kommt ja auch immer drauf an, was man damit erschlagen möchte. Was nützt mir das ganze Geraffel was z.B. QT mitbringt, wenn es als nur die Festplatte verstopft? just my 2 cents
Bevor ich lange rumrate. Das von mir erwartete funktioniert nicht. Hier ein Beispiel mit dem Qt Designer selbst In Beispiel 1 liegen alle Panels übereinander und lassen sich mit Tabs umschalten http://roboter-gallery.de/pub/Qt1.png In Beispiel zwei sind die Boxen wild verteilt http://roboter-gallery.de/pub/Qt2.png Dieses Verhalten ist mit wx NICHT realisierbar, zumindest ist mir das noch nicht untergekommen. Wenn es ginge, müsste Editra nicht den "Shelf Hack" machen. Um bei Codeblocks zu bleiben. Du hast links die Box Management und darunter die Box Man/HTML Pages Viewer. Versuche mal den Viewer per Drag and Drop "auf" die Management Box zu legen. Ich würde erwarten, dass die Linke Spalte anschließend die volle Höhe hat und das man zwei Tabs mit der Aufschrift "Management" und "Man/HTML page viewer" hat, so dass man zwischen beiden umschalten kann. Das geht nicht. Ich nehme an, das mit dem Search Result ist ähnlich gelöst wie bei Editra. Die Log & others Box enthält einfach ein Tab Widget. Dort kann man die einzelnen Tabs ein- und ausblenden. Soviel hab ich noch rausgefunden. Ich nehme an, man kann eine separate Search Result Box irgendwo öffnen, was ich noch nicht gefunden habe. Aber man kann nicht nach belieben per Drag & Drop die Boxen platzieren. Ah, ich sehe gerade, Search Results befindet sich noch in Log & others. Das ist eine Fähigkeit des AUI Tab Widget, aber keine der Dockwidgets. Was ich meine ist z.B., Search Result aus Log & others herausziehen und z.B. in Management ablegen (Auch wenn das in dem Kontext keinen Sinn ergibt). Oder Symbols aus dem Management Dock herausziehen und einzeln rechts vom Editorfenster andocken.
Markus Burrer schrieb: > Und wie geht das? Bei mir tut sich da nix Kräftig dran ziehen. ;) > Was ich meine ist z.B., Search Result aus Log & others herausziehen und > z.B. in Management ablegen (Auch wenn das in dem Kontext keinen Sinn > ergibt). Also das habe ich bisher nie vermisst und finde das in den meisten Fällen auch nicht sehr sinnvoll. Wenn ich irgendwas innerhalb eines Fensters per Tabs gruppiere, dann halte ich es nicht für sinnvoll, das wieder herauszulösen und frei herumzuschieben. Einzelne Fenster kann man natürlich frei herumschieben und aus dem Hauptfenster herauslösen. Kurzum: Für mich ist das nicht wirklich ein überzeugendes Argument für QT.
Michael S. schrieb:
> Also das habe ich bisher nie vermisst
Was man nicht kennt kann man auch nicht vermissen.
Michael S. schrieb: > Bitte beschreibe, was Du unter "Autorskalierung" verstehst. Ich kann mit > dem Begriff nix anfangen... GUI-Elemente sollen automatisch an die verfuegbare Groesse angepasst werden. Bei einem modernen GUI-System gebe ich nur noch Gruppierung und grobe Groessenverhaeltnisse der Elemente an, Anpassung an aktuelle Fenstergroesse, Schriftgroesse, Einblendung von Scrollern, etc, pp. macht das GUI-System selbst.
Peter Stegemann schrieb: > Michael S. schrieb: > >> Bitte beschreibe, was Du unter "Autorskalierung" verstehst. Ich kann mit >> dem Begriff nix anfangen... > > GUI-Elemente sollen automatisch an die verfuegbare Groesse angepasst > werden. Bei einem modernen GUI-System gebe ich nur noch Gruppierung und > grobe Groessenverhaeltnisse der Elemente an, Anpassung an aktuelle > Fenstergroesse, Schriftgroesse, Einblendung von Scrollern, etc, pp. > macht das GUI-System selbst. Du meinst einen Layout Manager. Gibt es. Nennt sich bei wx "sizer". BoxSizer, GridSizer usw http://zetcode.com/wxpython/layout/
Markus Burrer schrieb:
> Was man nicht kennt kann man auch nicht vermissen.
Ich verrate Dir mal ein Geheimnis: Dieser ganze Docking-Kram geht mir
mehr auf die Nerven als er mir sinnvoll erscheint. Man kann sich
wunderbar die Programmoberfläche zerstückeln und sich dann abmühen, den
Ursprungszustand wieder hinzubekommen.
Peter Stegemann schrieb: > GUI-Elemente sollen automatisch an die verfuegbare Groesse angepasst > werden. Bei einem modernen GUI-System gebe ich nur noch Gruppierung und > grobe Groessenverhaeltnisse der Elemente an, Anpassung an aktuelle > Fenstergroesse, Schriftgroesse, Einblendung von Scrollern, etc, pp. > macht das GUI-System selbst. Ja, das macht wxWidgets natürlich. Die GUI bzw. deren Elemente werden da über Sizer angeordnet.
Michael S. schrieb: > Markus Burrer schrieb: >> Was man nicht kennt kann man auch nicht vermissen. > > Ich verrate Dir mal ein Geheimnis: Dieser ganze Docking-Kram geht mir > mehr auf die Nerven als er mir sinnvoll erscheint. Man kann sich > wunderbar die Programmoberfläche zerstückeln und sich dann abmühen, den > Ursprungszustand wieder hinzubekommen. Wenn der Programmierer schlau war, kann man verschiedene Workbench Layouts speichern. Eclipse und sogar CodeBlocks können das.
Markus Burrer schrieb: > Wenn der Programmierer schlau war, kann man verschiedene Workbench > Layouts speichern. Eclipse und sogar CodeBlocks können das. Nach dieser Möglichkeit sucht der Nutzer aber immer erst dann, wenn er sein Layout schon einmal komplett durch den Mixer gedreht hat. Was heißt eigentlich "sogar" Codeblocks?
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.