[C++ | VS2012 | POCO] GUI Library gesucht

[tophirsch]

Hallo ngb.coder,

ich suche, wie der Titel schon sagt, eine GUI Lib.

Ich möchte eine kleine Anwendung erstellen, die Inhalte aus einer lokalen SQLite-Datenbank anzeigen kann und diese Datenbank mit Inhalten aus dem Internet aktualisiert/befüllt.

Mit Hilfe von POCO habe ich mir ein paar Klassen erstellt, die mir folgende Funktionalität bereitstellen:

• Datei(en) von Server laden (können Zip oder Xml sein)
• je nachdem, ob es eine Zip-Datei ist, diese entpacken
• Xml-Datei(en) parsen und die enthaltenen Informationen in die DB schreiben
• Daten aus der DB abrufen

Die gesuchte Lib braucht also keine SQLite, Xml, http und trallala Unterstützung, weil das ja schon meine Klassen übernehmen. Geht nur um die Anzeige der bereitgestellten Daten und mal ein Update auslösen.

Soweit so gut. Habe die Klassen in einer Konsolen-Anwendung getestet und das funktioniert soweit alles ohne Probleme.
Nun möchte ich aber die Daten nicht einfach in die Konsole gerattert kriegen, weil das doch sehr unübersichtlich wird und ein bisschen Eye-Candy möchte ja auch sein
Habe dann versucht eine GUI dafür mit den in VS2012 eingebauten MFC zu schustern, aber festgestellt, dass das ziemliche Schmerzen im Hintern verursacht...
Vor allem, wenn das Layout dynamisch sein soll, da is immer alles verhunzt wenn man die Fenstergröße ändert.

Und da dachte ich mir:
Gibbet da nich was von Ratiopharm?

Bin bei meiner Recherche schon auf Qt gestoßen und hab damit auch ein bissel rumgefrickelt. Gefiel mir eigentlich ganz gut. Auch die Möglichkeit per qml einfach wie ne art "Stylesheet" für die Steuerelemente zu schreiben und die Tatsache, dass es auch ein Addin fürs VS2012 gibt gefällt.

Bevor ich mich da tiefer hineingestürzt habe, wollte ich dann mal eine einfache Anwendung(Die vom Wizard erstellte "Hello World") zum laufen bringen. Klappte auch. Aber dann... Als ich die erstellte .exe mal außerhalb der IDE ausführen wollte, musste ich feststellen, dass die Anwendung von einem ganzen Stapel dlls abhängig ist. Ich hab keine Lust zu einer mini-Anwendung noch 50Mb dlls zu kopieren. Statisch bauen hab ich jetzt nicht probiert, aber da dürften doch die exen auch riesig werden, oder? Kenne mich da ehrlich gesagt nicht so aus...
Abgesehen davon hab ich es auch mit drölfzig kopierten dlls und whatever nicht geschafft, dass die Anwendung was Anderes als ein leeres Fenster anzeigt. Wenn aber jmd sagt, Qt is so dufte und aus den und den Gründen den Anderen überlegen und das Problem mit den riesigen Executables kriegt man so und so in den Griff, dann bin ich auch bereit da an einer Problemlösung zu arbeiten.


tl,dr:
Also, kann mir da jmd eine gute GUI-Lib empfehlen

• Cross-Platform möchte die crossplatformität(jmd. n besseres adjektiv?) von POCO nicht einbüßen (nur Desktop, Android, iOS Apps etc. stehen vorerst nicht aufm Plan)
• dynamisches Layout sollte ohne große Aufwände möglich sein(Steuerelemente skalieren/positionieren wenn sich Fenstergröße ändert)
• fertige Anwendungen sollten nicht zu groß werden (keine drölftausend dlls zum mitgeben und die exen nicht 100Mb groß)

So, dat wärs erstmal, hoffe ich hab nix vergessen..

danke schonmal
tophirsch

 

[misterunknown]

Also ich weiß nicht, wie groß es ist, aber ich würde Qt dafür nehmen. Ich habe zwar selbst noch nicht damit gearbeitet, aber von einigen guten Erfahrungen von Kollegen gehört. Für so ein kleines Projekt könnte das aber evtl. den Rahmen sprengen, deshalb könnte vielleicht auch FLTK etwas für dich sein.
Alternativ gibt es hier eine Liste plattformunabhängiger GUI libraries.

 

[tophirsch]

Ich hatte ja oben schon geschrieben, dass ich auch den Verdacht habe, dass Qt etwas oversized ist. Lasse mich da aber auch gerne eines Besseren belehren, bin wie gesagt noch nich so tief eingetaucht.
Auf FLTK bin ich auch schon gestoßen, hast du selber schon Erfahrung damit gemacht?

Die Liste hab ich natürlich auch schon gefunden, aber so ne Liste is halt irgendwie keine große Entscheidungshilfe

 

[misterunknown]

Auf FLTK bin ich auch schon gestoßen, hast du selber schon Erfahrung damit gemacht?

Nein, ich selbst habe es noch nicht verwendet. Ich habe einen Freund der es schon mal verwendet hat, und der meinte: Es ist nicht "schön", aber schnell und light

Die Liste hab ich natürlich auch schon gefunden, aber so ne Liste is halt irgendwie keine große Entscheidungshilfe

Das stimmt natürlich.
Was mir gerade beim erneuten Lesen deiner Anforderung eingefallen ist: Wäre vielleicht eine Web-Oberfläche was? Ich bin mir nicht sicher, wie gut man das in C++ umsetzen kann, aber das wäre doch eigentlich perfekt für dich...

 

[tophirsch]

Wäre vielleicht eine Web-Oberfläche was? Ich bin mir nicht sicher, wie gut man das in C++ umsetzen kann, aber das wäre doch eigentlich perfekt für dich...

Du meinst, das mein Programm html erzeugt und das dann an den lokalen Horst zur Anzeige im Browser sendet? Wird das nicht auch unnötig kompliziert? Hab keine Ahnung davon... Abgesehen davon, wäre es vielleicht schon schön, wenn die Anwendung auch ohne Browser auskommt.

Hab mir FLTK nun auch nochmal genauer angeschaut, nunja... das sieht ja wirklich ein bisschen... altbacken aus
Weiß nicht, obs das nun bringt, mich da einzuarbeiten, wenn es mir dann für zukünftige Projekte dann doch nicht mehr gefällt, dann war alles umsonst.

Gibts nich was, was schön aussieht, für kleine Projekte schmal genug ist, aber auch gut später für größere Sachen verwendbar ist? Ich mein, ich will mich dann nicht jedes mal in ein neues Framework einarbeiten. Naja, vielleicht bin ich zu anspruchsvoll
Immer nur Konsole, ich wollte auch mal schönes Klickibunti machen, menno.

Vielleicht kannst du deine Kollegen ja mal fragen, ob man Qt für kleinere Anwendungen auch irgendwie klein kriegt. An sich gefällt mir das immer besser, wenn halt diese Probleme mit den riesenhaften erzeugten Dateien nicht wären...

 

[misterunknown]

Du meinst, das mein Programm html erzeugt und das dann an den lokalen Horst zur Anzeige im Browser sendet? Wird das nicht auch unnötig kompliziert? Hab keine Ahnung davon...

Nein, ich hab eher an eine extreme-leightweight Webserver-Klasse gedacht, mit der du einen eigenen Port binden kannst. Dann startet dein Programm den Default-Browser (jedes System hat sowas) und du kannst die Oberfläche mit HTML5 und CSS3 gestalten. Und wenn du Javascript mit rein bringst, welches ab und zu paar Requests an dein Programm sendet, wäre das eine portable, flexible Lösung. Aber keine Ahnung, ob es sowas gibt. Problem wäre aber eigentlich nur die Webserver-Klasse, da sind hier einige gegeben.

Abgesehen davon, wäre es vielleicht schon schön, wenn die Anwendung auch ohne Browser auskommt.

Naja, das muss man sehen, was geht. Mir ist kein System mit grafischer Oberfläche bekannt, welches nicht standardmäßig einen Browser hat.

Weiß nicht, obs das nun bringt, mich da einzuarbeiten, wenn es mir dann für zukünftige Projekte dann doch nicht mehr gefällt, dann war alles umsonst.

Korrekt. Deshalb hatte mir auch die Webserver-Variante ganz gut gefallen. Aber da fragt sich auch ob da eine etwas intensivere Einarbeitung sinnvoll ist.

Vielleicht kannst du deine Kollegen ja mal fragen, ob man Qt für kleinere Anwendungen auch irgendwie klein kriegt. An sich gefällt mir das immer besser, wenn halt diese Probleme mit den riesenhaften erzeugten Dateien nicht wären...

Ich seh den erst am Montag wieder, aber dann frag ich den mal


PS: Ich hab mal noch bisschen gegoogelt und das hier gefunden. Sieht sehr interessant aus.

 

[Larius]

An sich gefällt mir das immer besser, wenn halt diese Probleme mit den riesenhaften erzeugten Dateien nicht wären...

Und wo besteht da jetzt genau das konkrete Problem? Ich mein, ich hab erst jetzt vor ein paar Tagen eine 1 TB SSD Platte gesehen und hier wird grad vl über 100 MB diskutiert Oder willst du das dann irgendwo laufen lassen wo Speicher wirklich ein Problem darstellt?

 

[tophirsch]

Oder willst du das dann irgendwo laufen lassen wo Speicher wirklich ein Problem darstellt?

Das nicht, aber wenn ich dann doch mal ein Programm weitergebe, dann würd ich mich ja schämen, wenn so ein simples Progrämmchen so riesengroß ist

@misterunknown
Agar sieht auf den ersten Blick ja mal ganz gut aus, werd ich auf jeden Fall noch mal genauer unter die Lupe nehmen.

 

[Larius]

Und? Wenn du etwas in Java oder C# programmierst braucht derjenige dann das JRE bzw. die .net Runtime damit das Ganze rennt. Das ist auch nicht grad ein Pappenstil, auch wenn Letzeres weit verbreitet ist (ATI hat bsp. für die Treiber mal das Framework benötigt, das war lustig wenn du einen PC neu aufgesetzt hast ). So kannst ja noch immer sagen "Sorry Leute, die Dateien für die Oberfläche ist so groß, da kann ich leider nichts dran machen".

 

[musv]

Als ich vor vielen Jahren mal MFC (*hust*) ausprobiert hab, war das Hello-World-Programm auch ein paar MB groß. Und damals waren ein paar MB noch wesentlich mehr Speicher. Dazu muss man sagen, dass bei MFC noch zusätzlich die Runtime benötigt wurde, die im Windows drinsteckt. Bei Qt wird halt alles mitgeliefert, was irgendwie an Libs notwendig ist.

 

[Larius]

Ums genau zu nehmen ist das eine Microsoft Visual C++ Runtime welche benötigt wird. Wenn man nicht zufällig die Runtime installiert hat kriegt man nämlich eine schicke Fehlermeldung

 

[Asseon]

Außerdem wenn man nur die Qt libs einbindet die unbedingt nötig sind hält sich das eigentlich in grenzen.

Mehr als QtCore und QtGui sollten eigentlich nicht nötig sein

 

[tophirsch]

Also nach einer googelei habe ich nun wahrscheinlich den Grund gefunden, warum Qt bei mir so große Dateien erzeugt und haufenweise riesige dlls haben will. Ich hatte zum schnellen testen natürlich die fertig kompilierte Version heruntergeladen. Da ist aber sämtlicher Schickimiki-Scheiß aktiviert. Das führt dann zu jeder Menge Abhängigkeiten, was auch erklärt, warum ich immer so viele dlls benötigt hab...

Werde jetzt mal versuchen Qt mit verschiedenen Optionen nochmal selbst zu kompilieren...da hat der Compiler am Wochenende wenigstens was zu tun
Vielleicht gibt's ja dadurch Besserung.

 

[misterunknown]

@tophirsch: Ich bin auf jeden Fall an deinen Erkenntnissen interessiert

 

[tophirsch]

Soo,
hatte am we doch weniger Zeit, als gedacht zum experimentieren(RL und so ).
Aber ich habe es zumindest geschafft, meinem Rechenknecht einen static build von Qt abzuringen.
Noch nicht perfekt, aber immerhin: Eine kompilierte Anwendung mit ein paar wahllos platzierten Widgets läuft ohne zusätzliche dlls und ist um die 7Mb groß.

Spoiler

Möglicherweise ist auf Systemen ohne Visual Studio noch die MSVC Redistributable nötig ist, kann man aber auch umgehen, indem man dem Compiler statt -MD die Option -MT mitgibt, dann wird die redist auch statisch gelinkt. Davon wird aber abgeraten, siehe hier unter Static tips.

Ich werde noch versuchen alle Module auszuschließen, die nichts mit GUI, Widgets etc. zu tun haben, da ich Funktionalität wie net, zip etc. schon von POCO abgedeckt hab und daher nicht nochmal von Qt brauche. Versuche sozusagen einen minimal-build, der nur für die GUI-Entwicklung ist.

Aber zumindest zeigt mir das Alles schonmal, dass es auch kleiner geht.

Genaueres Vorgehen poste ich dann nochmal, wenn ich das ganze noch weiter untersucht habe

 

[Larius]

Versuch mal dein Projekt in VS als Release zu builden. Kann nur sein das du dann auch für die Release-Konfiguration die Libs einstellen musst, aber beim Release ist IMMER die Runtime dabei.

 

[MingsPing]

Was ich persönlich auch noch interessant fände, was du alles noch bräuchtest, wenn du das Programm auf nem Rechner laufen lassen möchtest, der wirklich nur nen gcc drauf hat oder so (also ohne dein Visual Studio etc.).
Bin nämlich auch immer wieder erstaunt, was alles schief gehen kann, wenn Librarys fehlen und finde es dann sorgenfreier, einfach jede Abhängigkeit mitzuschicken.

 

[Larius]

Naja, wenn du ein Projekt in Visual Studio im Release-Modus kompilierst liefert das automatisch alle wichtigen Dateien mit damit es eben ohne der Runtime auskommt - die Runtime wird ja nur für die Debug-Routinen benötigt die beim Debug-Modus kompiliert werden. Zusätzlich muss man halt die passenden Libraries dazu packen - entweder indem man sie in die Exe reinkompiliert (glaub das ist statisches Linken, bin mir aber nicht sicher) oder halt als DLL dazuliefert und korrekt referenziert. Das ist aber schon die ganze Hexerei.

 

[musv]

Naja, wenn du ein Projekt in Visual Studio im Release-Modus kompilierst liefert das automatisch alle wichtigen Dateien mit damit es eben ohne der Runtime auskommt - die Runtime wird ja nur für die Debug-Routinen benötigt die beim Debug-Modus kompiliert werden. Zusätzlich muss man halt die passenden Libraries dazu packen - entweder indem man sie in die Exe reinkompiliert (glaub das ist statisches Linken, bin mir aber nicht sicher) oder halt als DLL dazuliefert und korrekt referenziert. Das ist aber schon die ganze Hexerei.

Weiß nicht, ob ich Dich jetzt richtig interpretier. Zuerst meinst du, dass man im Release-Modus absolut nichts dazupacken muss. Später schreibst du, dass man die passenden Libraries beilegen oder statisch linken muss.

Bei uns auf Arbeit nutzen wir (leider) Win7 mit VS2012. Bau ich damit irgendwas im Release-Modus, dann läuft der Mist auf den anderen Win7-Rechnern normalerweise nicht, weil eben die entsprechende Runtime (VC2012) fehlt. Die kriegst du mit dem Redistributable Package. Und weil ja immer so schön die Abwärtskompatibilität betont wird: Hast du nicht die richtige Runtime installiert, dann läuft gar nichts. Bei falschen Minor-Version kriegst du ganz leicht einen Side-By-Side-Configuration Error (Beispiel), bei dem man sich dann oft tagelang aufhalten kann, bis (sofern) man mal eine Lösung findet.

Also nix mit Release-Modus und keine Abhängigkeiten bei Visual Studio!

 

[tophirsch]

Naja, wenn du ein Projekt in Visual Studio im Release-Modus kompilierst liefert das automatisch alle wichtigen Dateien mit damit es eben ohne der Runtime auskommt

Ich konnte mein VS leider noch nicht zu so einem Verhalten überzeugen.

Oben schreibst du ja noch

Kann nur sein das du dann auch für die Release-Konfiguration die Libs einstellen musst, aber beim Release ist IMMER die Runtime dabei.

Kannst du mir sagen, was genau du wo und wie eingestellt hast, das dein VS automatisch die passende Runtime mitliefert?

Die kriegst du mit dem Redistributable Package. Und weil ja immer so schön die Abwärtskompatibilität betont wird: Hast du nicht die richtige Runtime installiert, dann läuft gar nichts. Bei falschen Minor-Version kriegst du ganz leicht einen Side-By-Side-Configuration Error (Beispiel), bei dem man sich dann oft tagelang aufhalten kann, bis (sofern) man mal eine Lösung findet.

Und wenn ich die msvcpXXX.dll und/oder msvcrXXX.dll manuell dazupacke? Dann müsste ich doch die richtige Version haben, mit der ich auch den code entwickelt hab?

Dumme Frage, weil ich grad durcheinander bin wie ein Rührei: Bei einer 32bit Anwendung muss ich nur die x86 Version mitgeben, und nicht noch die x64, nur weil das Programm auch auf 64bit läuft...oder? Logischerweise wär ja nur die x86 nötig...oder doch nich?