Im Gegensatz zu anderen vergleichbaren Toolkits nutzt wxWidgets das API der jeweiligen Plattform, was dazu führt, dass sich mit wxWidgets erstellte Applikationen nahtlos in das Look&Feel des jeweiligen Betriebssystems einfügen.
Das stimmt so einfach nicht. Unter Linux benutzt wxWidgets nicht das API der jeweiligen Plattform, jedenfalls nicht unter KDE und ich bezweifle mal stark daß sich wxWidgets Applikationen nahltlos in das Look&Feel von KDE einfüten.
Mal abgesehen davon daß sich Applikationen noch lange nicht nahtlos in das Look&Feel eines Betriebssystems einfügen, nur weil sie die gleichen Widgets verwenden. Das heißt ja noch lang nicht, daß die Applikationen die gleiche Anordnung der Buttons usw. verwenden.
Natürlich stimmt es. Einfach mal die Windows oder Mac-Screenshots anschauen. Unter Linux werden dann beispielsweise X11, Motif oder GTK+ benutzt. Hier mal eine Beschreibung der Unterschiede zwischen den Toolkits: http://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits
Wichtig wäre dieser Satz zum Vergleich zwischen Qt und wxWidgets:
Qt doesn't have true native ports like wxWidgets does. Qt does not use system provided widgets, but emulates it with themes. What we mean by this is that even though Qt draws them quite realistically, Qt draws its own widgets on each platform. It's worth mentioning though that Qt comes with special styles for Mac OS X and MS Windows XP and Vista that use native APIs (Appeareance Manager on Mac OS X, UxTheme on Windows XP) for drawing standard widget primitives (e.g. scrollbars or buttons) exactly like any native application.
wxWidgets benutzt unter KDE also Qt? Würd mich doch sehr wundern.
Außerdem ist das Look&Feel einer Applikation mehr als das Aussehen der Widgets. Da gibts alle möglichen Unterschiede wie z.B. instant apply vs. OK und Cancel Knöpfe zum Anwenden bzw. Verwerfen von Änderungen. Glaubst du ernsthaft ne typische Windows-Applikation würde sich nahtlos in das Look&Feel von MacOS X integrieren, nur weil sie die nativen Widgets verwendet? Träum weiter.
Screenshots sagen erstmal wenig aus. WxWidgets haben sehr wohl ihre eigenen Widgets die nicht zum nativen Toolkit gehören und in diese teils eingebettet werden. Man muss sich nur mal so manches Tree-Widget ansehen. Vor Jahren habe ich mal versucht eine platformunabhängige Wx Anwendung zu schreiben. Nicht nur, dass manche Elemente in entsprechenden Toolkits wie Arsch und Friedrich aussahen - was musste ich rumfrickeln bis ich eine einheitliche Basis zwischen Linux (GTK) und Windows XP hatte - teilweise verschlang es ganze Widgets ins Nirvana. Sie waren entweder hier oder dann dort nicht sichtbar. Das war dann jedes mal Russisch Roulette (nutzte damals noch keine VM) wenn man ins andere OS bootete um zu sehen, ob dort noch alles vernünftig aussah. Und die Doku war damals ebenfalls ein Witz. Nicht nur, dass mich der MFC artige Aufbau damals schon nervte, während andere Toolkits wesentlich elegantere Wege hatten, die Doku war in Fällen wie eben beschrieben auch gar keine Hilfe mehr. Kann sein, dass es heute besser ist.
Ich war damals einfach nur schwer genervt von wxWidgets. Wenn ich platformunabhängige Anwendungen mit GUI erstelle, nativ hin oder her, dann ist meine präferierte Wahl mittlerweile Qt. Da nehme ich auch in Kauf, dass Windows 8 noch nicht unterstützt wird (zumindest nach meinem letzten Wissensstand). Mit dem Schritt zu 3.0 werfe ich vielleicht nochmal einen Blick drauf.
was musste ich rumfrickeln bis ich eine einheitliche Basis zwischen Linux (GTK) und Windows XP hatte - teilweise verschlang es ganze Widgets ins Nirvana.
:)
Das ist einer der Gründe warum ich WxWidgets zum Proggen nicht mag.
Und die Doku war damals ebenfalls ein Witz. Nicht nur, dass mich der MFC artige Aufbau damals schon nervte, während andere Toolkits wesentlich elegantere Wege hatten, die Doku war in Fällen wie eben beschrieben auch gar keine Hilfe mehr. Kann sein, dass es heute besser ist.
Das auch.
Wenn schon nicht Qt, dann lieber GTK+ bzw. GTKmm anstatt WxWidgets.
Naja, es gibt eben unter Linux nicht "die" API. Der Satz bezog sich wohl in erster Linie auf Windows und Mac, sowie GTK+ unter Linux. Wie du aber erwähnst kommt es darauf auch nicht so sehr an. Das Interface kann noch so "nativ" aussehen, wenn es grottig ist bleibt es auch grottig. Das muss jetzt nicht für jede wxwidgets-basierte Anwendung gelten, aber es war schon sehr auffällig, dass diese Anwendungen (aufs Interface bezogen) sehr verbuggt waren.
Bestes Beispiel ist VLC. Nach dem Wechsel auf Qt4 verschwanden so einige Bugs, das Interface wirkt ansprechender (auch wenn es unter Windows nicht 100%ig nativ aussieht, aber ist doch schnuppe) und die Entwickler können verhältnismäßig wesentlich mehr Zeit in die Entwicklung des Interfaces stecken als in das Minenfeld aus Bugs dass früher das Interface war.
Mal ganz abgesehen davon fällt mir eigentlich nur noch 3 beliebte Anwendung ein, die das nutzt: Filezilla, Truecrypt und Audacity Alle anderen sind untergegangen oder gewechselt.
Bevor jetzt Gemecker kommt: Es ist mir schon klar, dass es noch Anwendungen gibt, die das verwenden, aber is ist inzwischen eben doch die Seltenheit geworden. Früher war wxwidgets deutlich beliebter.
Wx hab ich irgendwann mal aus den Augen verloren. Damals gab es doch Ideen die API nicht mehr so an MFC zu orientieren, oder? Hat man da jetzt was geändert oder muss ich immer noch diese komischen Message Tables definieren?
Fox wird iirc nicht mehr weiterentwickelt. Technisch war es sehr gut, aber nur ein One-Man-Show des Entwicklers, von daher auch wieder unbrauchbar, von der Optik ganz abgesehen, die war schon vor 10 Jahren altbacken.
FLTK habe ich früher mal für Kleinkram verwendet, eher hässlich - optisch wie technisch - hat sich aber bis heute teilweise geändert, kann afaik sogar Themes aber ganz praktikabel wenn man damals platformübergreifende GUI-Programme bauen wollte, war aber noch häslicher als Tk damals.
Mittlerweile bin ich wieder bei Tk+Scriptsprache (alles ausser Tcl) gelandet, wenn es ein Programm mit GUI werden soll und das als Webanwendung eher unvorteilhaft ist, ansonsten wird es als Webanwendung entwickelt, alles was keine GUI braucht wird als Konsolenanwendung mit Scriptsprachen entwickelt. C/C++ fasse ich nur noch an wenn ich an Microcontrollern rumfummele. Wer heute noch mit C/C++ Anwendungen entwickeln (muss), überhaupt mit dem Schwerpunkt GUI, hat mein tiefstes Beileid.
Von doctor_vitus am Mi, 13. November 2013 um 09:58 #
Fox wird schon noch weiterentwickelt, und im Vergleich zu anderen Ein-Mann-Projekten wie 7-Zip sogar recht kontinuierlich. Siehe http://fox-toolkit.org/, die Entwicklungsversionen erscheinen etwa monatlich.
>Wer heute noch mit C/C++ Anwendungen entwickeln (muss), überhaupt mit dem Schwerpunkt GUI, hat mein tiefstes Beileid.
Es geht schon. Viel schlimmer finde ich es für die Framework/Bibliothek-Ersteller, da diese quasi gezwungen sind, z.B. ihre eigene String-Implementierung für halbwegs funktionierenden Unicode-Support zu basteln.
Von doctor_vitus am Mi, 13. November 2013 um 03:57 #
Was habt Ihr bloß alle gegen wx? Ich finde die API intuitiv, das ganze Toolset ist sehr umfangreich und inzwischen auch recht ausgereift, und die Applikationen fühlen sich (fast) überall nativ an.
Bzgl. FLTK und Fox als Alternativen gebe ich zu bedenken, daß sie (insbesondere FLTK) keine vollständigen Toolkits, sondern primär GUI-Bibilotheken sind und man für andere Funktionalitäten mit weiteren Bibliotheken beschäftigen muss.
In die Liste der prominenten wx-Anwendungen gehört übrigens auch noch die Entwicklungsumgebung Codeblocks.
> Was habt Ihr bloß alle gegen wx? Nix. Das Bessere ist halt Feind des Guten.
> Bzgl. FLTK und Fox als Alternativen gebe ich zu bedenken, daß > sie (insbesondere FLTK) keine vollständigen Toolkits, sondern > primär GUI-Bibilotheken sind Es gibt Leute die genau das brauchen. Die anderen nehmen Qt.
Im Gegensatz zu anderen vergleichbaren Toolkits nutzt wxWidgets das API der jeweiligen Plattform, was dazu führt, dass sich mit wxWidgets erstellte Applikationen nahtlos in das Look&Feel des jeweiligen Betriebssystems einfügen.
Das stimmt so einfach nicht. Unter Linux benutzt wxWidgets nicht das API der jeweiligen Plattform, jedenfalls nicht unter KDE und ich bezweifle mal stark daß sich wxWidgets Applikationen nahltlos in das Look&Feel von KDE einfüten.
Mal abgesehen davon daß sich Applikationen noch lange nicht nahtlos in das Look&Feel eines Betriebssystems einfügen, nur weil sie die gleichen Widgets verwenden. Das heißt ja noch lang nicht, daß die Applikationen die gleiche Anordnung der Buttons usw. verwenden.
Natürlich stimmt es. Einfach mal die Windows oder Mac-Screenshots anschauen. Unter Linux werden dann beispielsweise X11, Motif oder GTK+ benutzt. Hier mal eine Beschreibung der Unterschiede zwischen den Toolkits:
http://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits
Wichtig wäre dieser Satz zum Vergleich zwischen Qt und wxWidgets:
Natürlich stimmt es.
wxWidgets benutzt unter KDE also Qt? Würd mich doch sehr wundern.
Außerdem ist das Look&Feel einer Applikation mehr als das Aussehen der Widgets. Da gibts alle möglichen Unterschiede wie z.B. instant apply vs. OK und Cancel Knöpfe zum Anwenden bzw. Verwerfen von Änderungen. Glaubst du ernsthaft ne typische Windows-Applikation würde sich nahtlos in das Look&Feel von MacOS X integrieren, nur weil sie die nativen Widgets verwendet? Träum weiter.
Screenshots sagen erstmal wenig aus. WxWidgets haben sehr wohl ihre eigenen Widgets die nicht zum nativen Toolkit gehören und in diese teils eingebettet werden. Man muss sich nur mal so manches Tree-Widget ansehen. Vor Jahren habe ich mal versucht eine platformunabhängige Wx Anwendung zu schreiben. Nicht nur, dass manche Elemente in entsprechenden Toolkits wie Arsch und Friedrich aussahen - was musste ich rumfrickeln bis ich eine einheitliche Basis zwischen Linux (GTK) und Windows XP hatte - teilweise verschlang es ganze Widgets ins Nirvana. Sie waren entweder hier oder dann dort nicht sichtbar. Das war dann jedes mal Russisch Roulette (nutzte damals noch keine VM) wenn man ins andere OS bootete um zu sehen, ob dort noch alles vernünftig aussah. Und die Doku war damals ebenfalls ein Witz. Nicht nur, dass mich der MFC artige Aufbau damals schon nervte, während andere Toolkits wesentlich elegantere Wege hatten, die Doku war in Fällen wie eben beschrieben auch gar keine Hilfe mehr. Kann sein, dass es heute besser ist.
Ich war damals einfach nur schwer genervt von wxWidgets. Wenn ich platformunabhängige Anwendungen mit GUI erstelle, nativ hin oder her, dann ist meine präferierte Wahl mittlerweile Qt. Da nehme ich auch in Kauf, dass Windows 8 noch nicht unterstützt wird (zumindest nach meinem letzten Wissensstand). Mit dem Schritt zu 3.0 werfe ich vielleicht nochmal einen Blick drauf.
:)
Das ist einer der Gründe warum ich WxWidgets zum Proggen nicht mag.
Das auch.
Wenn schon nicht Qt, dann lieber GTK+ bzw. GTKmm anstatt WxWidgets.
Unter Linux werden dann beispielsweise X11, Motif oder GTK+ benutzt
Das wäre aber neu dass das wxX11 endlich tut ohne Kaputt und Crash.
Naja, es gibt eben unter Linux nicht "die" API. Der Satz bezog sich wohl in erster Linie auf Windows und Mac, sowie GTK+ unter Linux. Wie du aber erwähnst kommt es darauf auch nicht so sehr an. Das Interface kann noch so "nativ" aussehen, wenn es grottig ist bleibt es auch grottig. Das muss jetzt nicht für jede wxwidgets-basierte Anwendung gelten, aber es war schon sehr auffällig, dass diese Anwendungen (aufs Interface bezogen) sehr verbuggt waren.
Bestes Beispiel ist VLC. Nach dem Wechsel auf Qt4 verschwanden so einige Bugs, das Interface wirkt ansprechender (auch wenn es unter Windows nicht 100%ig nativ aussieht, aber ist doch schnuppe) und die Entwickler können verhältnismäßig wesentlich mehr Zeit in die Entwicklung des Interfaces stecken als in das Minenfeld aus Bugs dass früher das Interface war.
Mal ganz abgesehen davon fällt mir eigentlich nur noch 3 beliebte Anwendung ein, die das nutzt: Filezilla, Truecrypt und Audacity
Alle anderen sind untergegangen oder gewechselt.
Bevor jetzt Gemecker kommt: Es ist mir schon klar, dass es noch Anwendungen gibt, die das verwenden, aber is ist inzwischen eben doch die Seltenheit geworden. Früher war wxwidgets deutlich beliebter.
Außerdem: Vergessen wir mal nicht, dass die ganzen OS-Hersteller auch Software rausbringen, die sich nicht in ihr OS integriert.
Wx hab ich irgendwann mal aus den Augen verloren. Damals gab es doch Ideen die API nicht mehr so an MFC zu orientieren, oder? Hat man da jetzt was geändert oder muss ich immer noch diese komischen Message Tables definieren?
Ok, hat sich erledigt. Schaue mir gerade den Code an. wxWidgets programmiert sich offenbar immer noch wie MFC
Danke fürs nachschauen. Also immer noch der selbe Käse.
Siehe dazu http://wxwidgets.blogspot.com/2007/01/in-praise-of-connect.html
Kurz: Die an die MFC erinnernden Event-Tables gibt es noch, aber auch Connect als Alternative.
Hallo,
nun was nimmt man jetzt, wenn man in C++ programmieren möchte? Qt oder wx?
ruediger
Qt
na, C++ !!1!
Nach meiner Erfahrung mit wxWidgets damals ... eindeutig Qt. Vor allem auf lange Sicht gesehen.
Qt, danach FLTK, oder Fox Toolkit.
Der Omega13
Fox wird iirc nicht mehr weiterentwickelt.
Technisch war es sehr gut, aber nur ein One-Man-Show des Entwicklers, von daher auch wieder unbrauchbar, von der Optik ganz abgesehen, die war schon vor 10 Jahren altbacken.
FLTK habe ich früher mal für Kleinkram verwendet, eher hässlich - optisch wie technisch - hat sich aber bis heute teilweise geändert, kann afaik sogar Themes aber ganz praktikabel wenn man damals platformübergreifende GUI-Programme bauen wollte, war aber noch häslicher als Tk damals.
Mittlerweile bin ich wieder bei Tk+Scriptsprache (alles ausser Tcl) gelandet, wenn es ein Programm mit GUI werden soll und das als Webanwendung eher unvorteilhaft ist, ansonsten wird es als Webanwendung entwickelt, alles was keine GUI braucht wird als Konsolenanwendung mit Scriptsprachen entwickelt.
C/C++ fasse ich nur noch an wenn ich an Microcontrollern rumfummele.
Wer heute noch mit C/C++ Anwendungen entwickeln (muss), überhaupt mit dem Schwerpunkt GUI, hat mein tiefstes Beileid.
Fox wird schon noch weiterentwickelt, und im Vergleich zu anderen Ein-Mann-Projekten wie 7-Zip sogar recht kontinuierlich. Siehe http://fox-toolkit.org/, die Entwicklungsversionen erscheinen etwa monatlich.
>Wer heute noch mit C/C++ Anwendungen entwickeln (muss), überhaupt mit dem Schwerpunkt GUI, hat mein tiefstes Beileid.
Es geht schon. Viel schlimmer finde ich es für die Framework/Bibliothek-Ersteller, da diese quasi gezwungen sind, z.B. ihre eigene String-Implementierung für halbwegs funktionierenden Unicode-Support zu basteln.
Fox wird weiterentwickelt. Ein Blick auf den FTP Server:
File:fox-1.7.41.tar.gz 4936 KB 08/27/2013 11:17:00 PM
File:fox-1.7.42.tar.gz 4944 KB 09/16/2013 01:34:00 AM
File:fox-1.7.43.tar.gz 4959 KB 10/24/2013 09:09:00 PM
> C/C++ fasse ich nur noch an wenn ich an Microcontrollern rumfummele.
Schreibt jmd der freiwillig Tk benutzt. => LOL!
Der Omega13
Qt, und wenn du Qt nicht mögen solltest kannst du immer noch FLTK und GTKmm den Vorzug gegenüber wx geben.
Was habt Ihr bloß alle gegen wx? Ich finde die API intuitiv, das ganze Toolset ist sehr umfangreich und inzwischen auch recht ausgereift, und die Applikationen fühlen sich (fast) überall nativ an.
Bzgl. FLTK und Fox als Alternativen gebe ich zu bedenken, daß sie (insbesondere FLTK) keine vollständigen Toolkits, sondern primär GUI-Bibilotheken sind und man für andere Funktionalitäten mit weiteren Bibliotheken beschäftigen muss.
In die Liste der prominenten wx-Anwendungen gehört übrigens auch noch die Entwicklungsumgebung Codeblocks.
> Was habt Ihr bloß alle gegen wx?
Nix. Das Bessere ist halt Feind des Guten.
> Bzgl. FLTK und Fox als Alternativen gebe ich zu bedenken, daß
> sie (insbesondere FLTK) keine vollständigen Toolkits, sondern
> primär GUI-Bibilotheken sind
Es gibt Leute die genau das brauchen.
Die anderen nehmen Qt.
Der Omega13.