Login
Newsletter
Werbung

Thema: Projekt wxWidgets bittet um Hilfe

25 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von ChilliConCarne am Mi, 25. April 2012 um 08:59 #

Bitte was?
Es ist zwar schon über drei Jahre her, als ich ernsthaft etwas mit wx erstellen wollte, jedoch muss ich sagen, dass es die reinste Katastrophe war. Die Doku war komplett löchrig und die Mär vom platformübergreifenden look and feel war eine Frechheit. Ich habe ja keine pixelgenau Darstellung erwartet, aber zwischen den Ergebnissen unter Linux und Windows waren nicht nur welten Unterschiede, nein, teilweise mussten haufenweise konditionelle quirks eingebaut werden, damit es unter beiden Platformen überhaupt lief. Wurden mir Listen unter Linux schön dargestellt war im glechen Code unter Windows gar nix zu sehen. Dass die Fensterdarstellung total kaputt war, war da dann nur noch das geringere Übel. Mein Eindruck war, dass wenn man sich auf eine Platform konzentriert wx ganz brauchbar gewesen sein muss. Nur dann war das Toolkit für mich eine schlechterer Ersatz, da ich dann hätte gleich etwas natives verwenden können.

Vielleicht bin ich jetzt zu harsch und die Situation hat sich gebessert, aber ich bin damals mit wxWidgets ordentlich auf die Schnauze gefallen. Und fange mir jetzt keiner mit PEBKAC an. Wenn es sich wirklich gebessert haben sollte, nehme ich gern (Gegen)Argumente auf.

Dieser Beitrag wurde 3 mal editiert. Zuletzt am 25. Apr 2012 um 09:03.
[
| Versenden | Drucken ]
  • 1
    Von HaMü am Mi, 25. April 2012 um 09:38 #

    Öhm ja...was ist z.B. mit FileZilla? Der ist wxWidgets und sieht sowohl unter Linux als auch unter Windows gut aus. Um nur mal ein Beispiel zu nennen.

    [
    | Versenden | Drucken ]
    • 1
      Von Matze1 am Mi, 25. April 2012 um 10:31 #

      Filezilla hat auch dassselbe Problem das Wx hat und keinen anderen Entwickler als den Einen der es angefangen hat. Es gibt nicht mehr viele die wieder MFC machen wollen.

      [
      | Versenden | Drucken ]
      • 1
        Von Dong! am Mi, 25. April 2012 um 11:18 #

        Der OP beschwert sich über die Funktionalität von wxWidgets, da wird mit dem Beispiel FileZille gegenargumentiert und du bringst als neues "Gegenargument", dass dieses nur einen Entwickler hat. Häh? Habe ich was verpasst oder beantwortest du immer Fragen, die keiner gestellt hat?

        [
        | Versenden | Drucken ]
    0
    Von default am Mi, 25. April 2012 um 19:27 #

    Meine Erfahrungen decken sich mit meinen. wx funktioniert eigentlich nur unter Windows gut, unter Linux deutlich schlechter und unter OS X absolut miserabel. Zahlreiche Hacks sind nötig, damit es auf allen Plattformen halbwegs anständig läuft.

    Also Cross-Platform-Toolkit kann man wx ÜBERHAUPT NICHT empfehlen!

    [
    | Versenden | Drucken ]
    0
    Von Layout am Do, 26. April 2012 um 22:31 #

    Kann es sein dass es sich hier schlicht um ein Layout Problem handelt? Der Vorteil von wxWidgets ist dass es die Nativen Toolkits verwendet. Macht man fixe, nach Pixel ausgerichtete Layouts wird das natürlich zum Problem. Man hat verschiedene Schriftarten, verschiednene Schriftgrößen, verschiedene Buttons, verschiedene Menüs.

    Ich selbst habe wxWidgets nur für ein Projekt verwendet, und das liegt schon Jahre zurück (damals war der Name noch wxWindows). Ich hab primär für Windows entwickelt, und es am Ende auch für Linux gebaut. Die Portierung war nur noch etwas nachjustieren beim Layout, und war in nicht mal einem Tag erledigt.

    [
    | Versenden | Drucken ]
1
Von lucas am Mi, 25. April 2012 um 09:25 #

wx mit Qt vergleichen echt?

Qt ist viel, viel, viel mehr als ein GUI Toolkit, es ist ein Framework (mit Netzwerk, Datenbank, GUI, OpenGL, Vektor- & Bildverarbeitung, Multimedia usw).

Und die angeblichen Probleme mit Qt 5 sind meiner Meinung nach eher herbei geredet. Digia wird sich weiterhin intensiv um QWidgets kümmern, denn das ist was ein grossteil der zahlenden Kunden verwendet.

[
| Versenden | Drucken ]
1
Von Martin Runge am Mi, 25. April 2012 um 09:39 #

Als ein Haupt-Feature von WxWidgets wird immer wieder angegeben, dass das Look&Feel der jeweiligen Plattform erhalten bleibt. Das stimmt meiner Meinung nach nur eingeschränkt, z.B. unter Linux mit KDE Desktop. WxWidgets Programme sehen dort wie gtk Apps aus, was z.B. im Datei öffnen Dialog gleich auffällt. Die Bookmarks des Datei-öffnen-Dialoges werden auch nicht übernommen.
Das gleiche gilt natürlich auch für das Java Toolkit SWT.
Ist sicher keine große Sache, aber wenn man Wert darauf legt, dass ein Programm sich nahtlos in den Desktop einfügt, ist es mit der Verwendung von WxWidgets oder SWT einfach nicht getan.

[
| Versenden | Drucken ]
  • 1
    Von HansiHinterseher am Mi, 25. April 2012 um 10:17 #

    Kein Wunder, wxWidgets für X11 setzt nunmal auf GTK+ auf! Also sieht es unter KDE logischerweise auch wie eine GTK+ Anwendung aus. Absolut unverwunderlich.

    Es geht darum, das wXWidgets in den Basis-Controls nunmal nicht selbst zeichnet. Natürlich muß es für X11 einen Kompromiss geben, man kann schlecht sowohl GTK+ als auch Qt als Implementierung anbieten. Und der Kompromiss lautet GTK+.

    Dafür unter Windows Win32-Controls.

    Die Frage ist, ob das heute noch sooo wichtig ist? Ich war bis vor kurzem auch der Auffassung, das alles die originale Implementierung nutzen muss. Mittlerweile denke ich, das man bei komplexen Anwendungen selbst gezeichnete Controls nutzen kann, so lange diese sich wenigstens an das Original anlehnen.
    Das tut ja Qt z.B. unter MS Windows: keine originalen Widgets, aber sie bilden sie zumindest nach.


    Um auf wxWidgets unter KDE zurück zu kommen: hier steht eher das GTK+ oder auch KDE in der Pflicht, unter KDE die GTK+ Filedialoge KDE-konform darzustellen. Denn anscheinend funktioniert es ja mit GTK+-Buttons u.a. Widgets doch auch?

    [
    | Versenden | Drucken ]
    • 1
      Von Das Brot am Mi, 25. April 2012 um 10:35 #

      > man kann schlecht sowohl GTK+ als auch Qt als Implementierung anbieten

      http://wiki.wxwidgets.org/WxQt

      [
      | Versenden | Drucken ]
      0
      Von default am Do, 26. April 2012 um 00:46 #

      wxWidgets sieht leider noch nicht einmal wirklich wie GTK aus. Das ganze Layout macht wx selbst, und hält sich somit auch nicht an die Regeln und Abstände, die GTK und das aktuelle Theme vorgeben. Bestimmte Widgets implementiert wx weiterhin auch komplett anders als GTK.

      [
      | Versenden | Drucken ]
0
Von Entwickler am Mi, 25. April 2012 um 10:17 #

"Während vergleichbare Toolkits wie beispielsweise Qt derzeit eher mit Querelen und umstrittenen Designänderungen auf sich aufmerksam machen,"

Denkst du es ist erforderlich oder zielführend andere Lösungsansätze und Communities so auf WxWidgets aufmerksam machen zu wollen? Echt daneben sowas und leider rückst du WxWidget in ein schlechtes Licht das es nicht verdient hat weil es ganz andere Vorteile hat. Schade.

[
| Versenden | Drucken ]
  • 0
    Von Anonymous am Mi, 25. April 2012 um 10:57 #

    So? Wo soll denn der Vorteil von wxWidgets liegen? Spätestens seit Qt unter der LGPL steht, ist wxWidgets vollkommen obsolet.

    [
    | Versenden | Drucken ]
    • 0
      Von Johann am Mi, 25. April 2012 um 13:37 #

      kann man Qt .exe einfach so weiterverteilen? Oder gibt es die üblichen LGPL 'Freiheiten' ?

      [
      | Versenden | Drucken ]
      • 0
        Von lucas am Mi, 25. April 2012 um 13:45 #

        Ja kann man.

        Auch mit der LGPL darf man statisch builden, man muss einfach in der Lizenz darauf aufmerksam machen das Qt LGPL-Code enthalten ist und diesen auf nachfrage zur verfügung stellen.

        [
        | Versenden | Drucken ]
        • 0
          Von Johann am Mi, 25. April 2012 um 15:44 #

          .. und ich habe gedacht, man muss alles notwendige mitliefern, damit der Anwender sich eine neue .exe mit einer neuen qt-library wieder zusammenlinken kann.

          [
          | Versenden | Drucken ]
          0
          Von ichk am Mi, 25. April 2012 um 20:40 #

          Ich glaube diesbezüglich solltest du nocheinmal die LGPL konsultieren und/oder einen Anwalt. Denn deine Binary muss vom Empfänger der Binary auch mit einer modifiezierten Form der Bibliothek gelinkt werden können. Du musst also so linken das der Empfäger die Funktionen welche dir die Bibliothek zur Verfühgung stellt verändern kann und anschließend mit deinem Programm zusammen ausführen kann. Ausgenommen davon sind nur Konstanten, Struckturen, Macros, Zugriffsfunktion sowie kurze inline Funktionen.
          Du musst also falls du statisch linkst auch deine Objekt-Dateien zur Verfügung stellen. Bei C++ als Programmiersprache musst du besonders vorsichtig sein —deshalb steht die libstdc++ von gnu auch unter der gpl mit "Runtime Exception" und nicht unter lgpl— denn du darfst die Funktionen nicht mit "eincompilieren", Templates können zum Problem werden genauso wie das Beerben von Bibliotheks Klassen oder wenn der Compilier Aufrufketten optimiert.

          wxWidgets scheint unter einer Art lgpl mit "Runtime Exception" zu stehen.

          Dieser Beitrag wurde 1 mal editiert. Zuletzt am 25. Apr 2012 um 20:42.
          [
          | Versenden | Drucken ]
    0
    Von lucas am Mi, 25. April 2012 um 13:48 #

    Seh ich auch so.

    Und wer Qt verwendet hat keinen Grund umzusteigen. Auch wenn man Qt 5 nicht mag (was schonmal total grundlos ist da es dort auch QWidgets gibt) kann man weiterhin die 4.X Serie verwenden, welche noch lange von Digia mit Updates versorgt wird.

    [
    | Versenden | Drucken ]
0
Von pingos am Mi, 25. April 2012 um 20:06 #

Also dass die Entwickler so ausgelastet sind, liegt nicht an der Beliebtheit, sondern dass es so wenige sind. Robin Dunn, der eher wxPython macht, Vadim Zeitlin, Julian Smart und noch zwei oder drei andere. Das ist für ein so großes Projekt natürlich wenig.
Meiner Erfahrung nach lief wx unter Windows ganz gut, unter Linux allerdings nur sehr mäßig. Den Mac-Port habe ich nicht probiert.

[
| Versenden | Drucken ]
0
Von LeiderNochPerlUser am Mi, 25. April 2012 um 23:03 #

Ist wxWidgets im Moment wirklich die einzige, brauchbare Möglichkeit, mit Perl eine Benutzeroberfläche unter Linux und Windows zu bauen?
Das Qt nicht so nutzerfreundlich zum Erstellen von Bindings sein soll, ist ja einigermaßen geläufig.
Hab ich verpennt, das es irgendwo eine einigermaßen fertiggestellte Version von GTK3-Bindings existiert, die auch ohne große Konfigurations- und Compilerorgien (nicht wie SDL) sowohl auf Linux als auch mit ActiveStatePerl auf Windows läuft?
Auf metacpan sieht das nämlich anders, sprich unfertig aus.

[
| Versenden | Drucken ]
  • 0
    Von default am Do, 26. April 2012 um 01:04 #

    gobject-introspection ist eventuell eine interessante andere Möglichkeit. Damit lassen sich alle gobject-Libraries in Perl verwenden, also auch GTK. Ob das jetzt mit dem Perl von ActiveStae läuft, weiß ich nicht.

    Aber warum eigentlich Perl? ;) Für andere dynamische Sprachen gibt es z.B. gut funktionierende Qt-Bindings.

    [
    | Versenden | Drucken ]
    • 0
      Von LeiderNochPerlUser am Do, 26. April 2012 um 18:35 #

      Danke. Ich werds vielleicht mal ausprobieren, sobald ich dazu komme.
      >Aber warum eigentlich Perl? ;) Für andere dynamische Sprachen gibt es z.B. gut funktionierende Qt-Bindings.
      Ich such mir das nicht aus. Hoffentlich kommt bald Perl 6 in Form von Rakudo, denn technisch ist Parrot schon ne schöne Sache.

      [
      | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung