Wer von euch nutzt alles wxWidgets?



  • wxSkip schrieb:

    Danke für die Aufklärung! 👍

    Welche Aufklärung? Wird wiederspruchen von: http://www.c-plusplus.net/forum/viewtopic-var-t-is-267670-and-view-is-next.html



  • Zeus schrieb:

    wxSkip schrieb:

    Danke für die Aufklärung! 👍

    Welche Aufklärung? Wird wiederspruchen von: http://www.c-plusplus.net/forum/viewtopic-var-t-is-267670-and-view-is-next.html

    xD
    Na ja, wenigstens gab's bis jetzt noch keinen Flamewar 😉



  • Zeus schrieb:

    Welche Aufklärung? Wird wiederspruchen von: http://www.c-plusplus.net/forum/viewtopic-var-t-is-267670-and-view-is-next.html

    Wo ist da der widerspruch zu dem von mir geschriebenen? Ich hab doch extra darauf hingewiesen, dass man allein mit dem begriff "nativ" verwirrungen stiften kann.



  • MasterK schrieb:

    Zeus schrieb:

    Welche Aufklärung? Wird wiederspruchen von: http://www.c-plusplus.net/forum/viewtopic-var-t-is-267670-and-view-is-next.html

    Wo ist da der widerspruch zu dem von mir geschriebenen? Ich hab doch extra darauf hingewiesen, dass man allein mit dem begriff "nativ" verwirrungen stiften kann.

    Vielleicht in dem Satz: "Qt kennt sehr wohl native Widgets", wobei man jetzt natürlich wieder "kennen" weit auslegen könnte.



  • wxSkip schrieb:

    Vielleicht in dem Satz: "Qt kennt sehr wohl native Widgets"

    Vielleicht befasst du dich einfach mal mit Qt, bevor du hier wilde mutmaßungen anstellst.
    Ich wüsste nicht, was an dem satz falsch wäre.



  • MasterK schrieb:

    wxSkip schrieb:

    Vielleicht in dem Satz: "Qt kennt sehr wohl native Widgets"

    Vielleicht befasst du dich einfach mal mit Qt, bevor du hier wilde mutmaßungen anstellst.
    Ich wüsste nicht, was an dem satz falsch wäre.

    Ich meine ja bloß, dass meiner Auffassung nach dein Satz Zeus' Meinung widerspricht.



  • MasterK schrieb:

    wxSkip schrieb:

    Vielleicht in dem Satz: "Qt kennt sehr wohl native Widgets"

    Vielleicht befasst du dich einfach mal mit Qt, bevor du hier wilde mutmaßungen anstellst.
    Ich wüsste nicht, was an dem satz falsch wäre.

    Dann kannst du mir mal erkären wieso eine MFC und WinForms mit einigen wenigen Controls gleich aussehen (ohne Anordnung) und sich gleich verhalten, eine QT-Dialog-Anwendung allerdings nicht.

    Siehe: http://img6.imageshack.us/img6/3064/74154671.png

    In den Titel steht das Framework.

    Button sind alle gleich.
    Qt Calendar sieht deutlich anders aus.
    Das Kontextmenü der TextBox hat andere Einträge.
    Kleines Detail: Der Cursor wird nicht angezeigt, solange das Kontextmenü offen ist.



  • wxSkip schrieb:

    Ich meine ja bloß, dass meiner Auffassung nach dein Satz Zeus' Meinung widerspricht.

    Sorry, hatte dich und zeus verwechselt.

    Zeus schrieb:

    Dann kannst du mir mal erkären wieso eine MFC und WinForms mit einigen wenigen Controls gleich aussehen (ohne Anordnung) und sich gleich verhalten, eine QT-Dialog-Anwendung allerdings nicht.

    Es wurde doch schon gesagt, dass Qt die oberflächen der widgets selbst zeichnet. Dennoch kannst du dir von jedem widget eine systemspezifische window-ID geben lassen (methode heisst QWidget::winId()) und diese auch mittels zB WinAPI nutzen. Vorausgesetzt, dass widget ist "nativ". Such einfach mal nach "Qt Native Widgets vs Alien Widgets".
    Hier aber besteht eben die gefahr der verwirrung beim begriff "nativ". Hatte ich aber schon angesprochen. Du redest vom "nativen look-and-feel". Stelle ich einen style bereit, der die oberfläche haargenau so aussehen lässt wie deine MFC anwendung, würdest du "native" widgets/windows vermuten, auch wenns nicht der fall ist.



  • MasterK schrieb:

    wxSkip schrieb:

    Ich meine ja bloß, dass meiner Auffassung nach dein Satz Zeus' Meinung widerspricht.

    Sorry, hatte dich und zeus verwechselt.

    Zeus schrieb:

    Dann kannst du mir mal erkären wieso eine MFC und WinForms mit einigen wenigen Controls gleich aussehen (ohne Anordnung) und sich gleich verhalten, eine QT-Dialog-Anwendung allerdings nicht.

    Es wurde doch schon gesagt, dass Qt die oberflächen der widgets selbst zeichnet. Dennoch kannst du dir von jedem widget eine systemspezifische window-ID geben lassen (methode heisst QWidget::winId()) und diese auch mittels zB WinAPI nutzen. Vorausgesetzt, dass widget ist "nativ". Such einfach mal nach "Qt Native Widgets vs Alien Widgets".
    Hier aber besteht eben die gefahr der verwirrung beim begriff "nativ". Hatte ich aber schon angesprochen. Du redest vom "nativen look-and-feel". Stelle ich einen style bereit, der die oberfläche haargenau so aussehen lässt wie deine MFC anwendung, würdest du "native" widgets/windows vermuten, auch wenns nicht der fall ist.

    Endich, das hat drei Seite zu lange gedauert.



  • Ein Vergleich von wxWidgets und Qt wäre mal sehr interessant.
    Was kann man mit Qt machen, was nicht mit wxWidgets möglich ist und umgekehrt?
    Die meisten Leute, die sich für ein Framework entscheiden, wählen sowieso entweder Qt oder wxWidgets.
    Etwas, dass mir bisher aufgefallen ist, ist, dass Qt MDI-Applikationen unterstützt - auch unter Linux - dass scheint in wxWidgets bisher nur unter Windows möglich zu sein (auf anderen Plattformen wird das ganze "nur" simuliert - beispielsweise mit Hilfe von Tabs unter Linux und mit Hilfe "normaler" Frames unter MacOS).
    Wer kann weitermachen?



  • Vergleicher schrieb:

    Ein Vergleich von wxWidgets und Qt wäre mal sehr interessant.
    Was kann man mit Qt machen, was nicht mit wxWidgets möglich ist und umgekehrt?
    Die meisten Leute, die sich für ein Framework entscheiden, wählen sowieso entweder Qt oder wxWidgets.
    Etwas, dass mir bisher aufgefallen ist, ist, dass Qt MDI-Applikationen unterstützt - auch unter Linux - dass scheint in wxWidgets bisher nur unter Windows möglich zu sein (auf anderen Plattformen wird das ganze "nur" simuliert - beispielsweise mit Hilfe von Tabs unter Linux und mit Hilfe "normaler" Frames unter MacOS).
    Wer kann weitermachen?

    1. gibt es schon viele Threads zu diesem Thema, vielleicht nicht ganz so übersichtlich, wie du sie dir vorstellst
    2. ist es sehr ungeschickt, auf der 5.Seite in einem Thread eine neue Diskussion anzufangen, da solltest du schon einen eigenen Thread erstellen
    3. musst du aufpassen, dass dabei kein Flamewar entsteht.



  • wxSkip schrieb:

    1. gibt es schon viele Threads zu diesem Thema, vielleicht nicht ganz so übersichtlich, wie du sie dir vorstellst

    Wenn man nach diesem Argument gehen würde, könnte man das Forum gleich dicht machen, denn es gibt schon Threads zu fast allen Themen.
    Ne, mir gehts eher um aktuelle Meinungen und vor allem darum, dass ich mich bei der Diskussion beteiligen kann - ich kann doch keinen 5 Jahre alten Thread aufrollen.



  • Vergleicher schrieb:

    wxSkip schrieb:

    1. gibt es schon viele Threads zu diesem Thema, vielleicht nicht ganz so übersichtlich, wie du sie dir vorstellst

    Wenn man nach diesem Argument gehen würde, könnte man das Forum gleich dicht machen, denn es gibt schon Threads zu fast allen Themen.
    Ne, mir gehts eher um aktuelle Meinungen und vor allem darum, dass ich mich bei der Diskussion beteiligen kann - ich kann doch keinen 5 Jahre alten Thread aufrollen.

    Da hast du recht - ich würde allerdings trotzdem einen neuen Thread aufmachen, das geht AFAIK auch als Unregistrierter.


Anmelden zum Antworten