VS2015 + QT
-
Was meinst du mit dem RAD editor?
-
Hallo allerseits.
Ich habe gar keine Erfahrungen mit qt und vs15. Soweit ich verstanden habe, muss ich selbst ein project file erzeugen. Aber ich weiß leider nicht wie. Könnte mir bitte jemand ein Beispiel zeigen: also wie dies file aussieht, was und wo ich schreiben soll. sehr vieles habe ich im Internet leider nicht gefunden
Danke im voraus
-
Hallo,
Qt unterstützt aktuell nur offiziell bis VS 2013 (siehe: http://www.qt.io/download-open-source/#section-2). Als Anfänger würde ich VS 2013 + Qt5 + Qt Addin für VS2013 empfehlen. Wenn alles erfolgreich installiert ist, ist es nur noch das Projekt zu kompilieren ohne selbst irgendwelche QMake Skripte o.ä. anzupassen.
Mit VS 2015 müsste man aktuell selbst Qt kompilieren ... und ob das so viel Spaß macht, weiß ich nicht ^^
Als Alternative wie bereits angesprochen dann doch die ganze Qt Toolkette mit dem Qt Creator.
Viele Grüße,
Jakob
-
Qt zu kompilieren ist kein Problem.
-
Mal ne ernst gemeinte Frage. Warum habe ich das Gefühl, dass eigentlich jeder in letzter Zeit QT nutzen will?
Das, was ich hier so lese klingt alles relativ umständlich im Vergleich zu wxWidgets.
Bei wxWidgets schmeiße ich ne IDE an, haue ein paar Mal auf die Tastatur, und schon habe ich ein Fenster-Programm am Laufen. Ohne irgendwelche Workarounds..
Fremde Libs einzubinden ist auch kein Problem.
Liegts daran, dass man es auch kaufen kann, oder ists der Herdentrieb?
Das wären so Sachen, die mich nicht wirklich beeidrucken würden (im Gegenteil). Aber irgendwie habe ich inzwischen die Befürchtung, dass mir da was wichtiges entgangen ist....
Soweit ich weiß ist wxWidgets doch sogar nativer, was das Rendern angeht. Gibts irgendwas, dass man mit wxWidgets nicht machen kann?
Je mehr Meinungen desto besser, aber ich frage schon mal Raven2823568201 direkt: Wie kommts?
-
Mir ist gerade noch ne kleine Spinnerei eigefallen:
Zugegeben nicht sehr wahrscheinlich, aber wenn, dann eher bei qt als bei wxWidgets zu erwarten..
Wäre es möglich, dass, ob in 1, 2, 5, oder 10 Jahren, die Lizenz wieder restriktiver wird.
Also erstmal dafür sorgen, dass jeder Qt nutzt, wxWidgets dadurch mangels Interesse ausstirbt, und wenn der Konkurrent dan weg ist, die Qt-Lizenz wieder besteuern... Gibts hier kein :evil:
?!?
-
HappyDay schrieb:
Mir ist gerade noch ne kleine Spinnerei eigefallen:
Zugegeben nicht sehr wahrscheinlich, aber wenn, dann eher bei qt als bei wxWidgets zu erwarten..
Wäre es möglich, dass, ob in 1, 2, 5, oder 10 Jahren, die Lizenz wieder restriktiver wird.
Also erstmal dafür sorgen, dass jeder Qt nutzt, wxWidgets dadurch mangels Interesse ausstirbt, und wenn der Konkurrent dan weg ist, die Qt-Lizenz wieder besteuern... Gibts hier kein :evil: ?!?Dafür gibt es die "KDE Free Qt Foundation", welche ein Vereinbarung mit trolltech und jetzt digia hat:
Durch diese Vereinbarung ist eine opensource version von Qt sichergestellt. Sollte zukünftig Digia Qt nicht mehr als opensource veröffentlichen, so kann die Foundation die letzte freie version von Qt nehmen und weiter als opensource weiterentwickeln
-
HappyDay schrieb:
Mal ne ernst gemeinte Frage. Warum habe ich das Gefühl, dass eigentlich jeder in letzter Zeit QT nutzen will?
Qt bietet aktuell eine größere support von versschiedenen Platformen. Neben dem PC/Mac OS wird auch mobile platformen unterstützt (Android, IOs, Windows Phone)
Und es wird auch in vielen embedded projekten verwendet, welche eine form von UI anbietet.
Das könnte einer der Gründe sein, wiso viele anfangen sich mit Qt zu beschäftigen
-
Dafür gibt es die "KDE Free Qt Foundation"
Ich hätte nicht gedacht, dass das nötig ist. Aber gut zu wissen, dass man nicht alleine paranoid ist 
Ich habe mich mal (hauptsächlich bei stackoverflow) umgeschaut. Da wurde, was embedded-Geschichten angeht wxWidgets empfohlen, wegen der geringeren Größe der Anwendungen im Vgl. zu Qt. Irgendwer hat wxWidgets auch auf seinem raspberry zum Laufen gebracht.
Dann habe ich noch gelesen, dass man bei Qt nur dynamisch linken darf, bzw. wenn man statisch linkt, man seinen Quellcode offenlegen muss. Gut bei wxWidgets linke ich momentan aus praktischen Gründen auch gegen eine dll. Aber wenn ich dann mal was zum Veröffentlichen habe, werde ich dann doch statisch linken, da die "All-In-One"-dll um die 30Mb groß ist, und das eigentliche Programm gerade mal 300kb oder so. Das wird bei Qt wohl ähnlich sein.
Die Einschränkung beim statischen Linken ist, finde ich, schon nen Minuspünktchen.
( Andererseits habe ich irgendwo, nicht bei SO, also weniger vertrauenswürdig, gelesen, dass man doch ohne Einschränkung statisch linken darf. Die waren sich aber nicht einig, sah also eher nach einer subjektiven Meinung aus. Trotzdem fühle ich mich etwas verunsichert, und das ist auch nen kleines Minuspünktchen. Nachher stellt sich raus, dass die Pessimisten doch recht hatten...)
Aber irgendwelche Einschränkungen muss es ja geben. Sonst fehlt ja komplett der Anreiz doch Geld für Qt zu zahlen. Und das ist ja nicht gerade wenig. Umso größer muss der Anreiz sein.Support von mobilen Geräten ist schon ne feine Sache. Bei Android habe ich mal kurz drüber geschaut (und bei iOS ist das soweit ich weiß ähnlich). Da scheint die erste Wahl doch eh das "Android Studio" (IDE++) zu sein, einfach weil es umfassender ist, bzw. mit vielen Extras besser drauf abgestimmt ist, als ein "simples" GUI-Toolkit alleine.
Also ich würde dann, weil man ja möchte, dass die Äpp auf allen möglichen mobilen Geräten läuft eh die maßgeschneiderte Lösung jedem GUI-Tooklit, ob Qt oder wxWidgets, vorziehen. Also ist die Unterstützung von Android und Konsorten bei Qt überhaupt relevant? Kennt wer wen, der schon was vernünftiges alleine mit Qt im mobilen Bereich zusammengeklöppelt hat? (Wenn ich dann doch quasi für jede mögliche mobile Prozessorarchitektur ne einene Extra-Lib brauche wirds irgendwie uninteressant.)
Das klingt zu schön um wahr zu sein: Einmal ein Programm schreiben. Den Schalter auf Windows, oder android, oder iOS stellen, kompilieren und fertig. So einfach kann es eigentlich nicht sein: Bei android wird Java empfohlen, und ich habe eigentlich keine Lust desswegen aufm PC auf c++ zu verzichten.
Wie ist das denn mit den language-bindings bei Qt? Ich verbinde das immer nur mit c++. Bei wxWidgets gibts haufenweise bindings für z.B. Python, Java, Ruby usw. . Und bei z.B. android wird empfohlen, mit Java zu entwickeln...
Ich stelle mir das gerade als Horror vor, bei den verschiedenen Programmiersprachen dieses Signal/Slot-Zeugs einzurichten (bzw. ich wüsste nicht wie).
-
HappyDay schrieb:
Andererseits habe ich irgendwo, nicht bei SO, also weniger vertrauenswürdig, gelesen, dass man doch ohne Einschränkung statisch linken darf.
Nein, das ist schon richtig, statisch linken darf man nur mit GPL oder der kommerziellen Lizenz. War für mich bisher aber nie eine Einschränkung.
Binding für andere Sprachen gibts schon, vor allem Python. Wenn ich nach was suche, finde ich öfter mal zuerst irgendwelche PyQt Seiten.
Mit wxWidgets kenne ich mich jetzt nicht so gut aus. Ich hatte schon bei paar Projekten damit zu tun, musste da aber nicht wirklich viel machen. Ich habe aber das Gefühl, dass es eher "veraltet" und nicht so flexibel ist. Qt ist auch nicht wirklich "toll", aber es bietet schon eine solide Grundlage und viele Möglichkeiten. Mit Item Delegates und Style Sheets kann man z.B. schon sehr viel erreichen, was GUI angeht. Ich glaub nicht, dass wxWidgets Stylesheets kann. Und bei uns ist es z.B. nicht mal ein unwichtiger Punkt. Teilweise wird unsere Software über andere Firmen vertrieben (oder Teile davon zusammen mit anderen Lösungen) und die wollen sie oft an ihr CI anpassen, geht mit Stylesheets sehr einfach. Und überhaupt ist unsere GUI oft sehr komplex, das geht eh weit über das hinaus, was man unter Windows mit nativen Controls machen könnte, da ist es auch überhaupt kein Argument, obs wirklich 100% nativ ausschaut oder nicht.
-
Hallo,
ich komme mal auf die ursprüngliche Frage zurück; "Kann mir jemand eine leicht verständliche Hilfe (für Anfänger wie mich) geben, wie man QT in VS2015 zum laufen bekommen?".Ich benutze Visual Studio 2010 Express (in Deutsch) mit QT 5.5.
Ich habe eigentlich nichts anderes gemacht, als das QT 5.5 Installations-Programm runter zu laden und auszuführen.
Dann habe ich die Windows-Umgebungsvariablen QTDIR "Drive:\QT Einrichtungsverzeichnis\5.5\msvc2010" eingerichtet.Damit die LIBs gefunden werden, habe ich noch den PATH um "%QTDIR%\bin" erweitert.
Jetzt zur Handhabung in Visual Studio:
Den QT-Assistent und QT-Designer habe ich zum Aufruf aus der Visual Studio IDE unter dem Menüpunkt "Extras" mit "Externe Tools…" hinzugefügt (die Programme sind unter "%QTDIR%\bin\assistend.exe" und "%QTDIR%\bin\designer.exe").Für die UI-Dateien (sind die Informationen für den QT-Designer) habe ich in der VS-IDE einen "Filter" für diese UI-Dateien in mein Projekt eingefügt. Die UI-Dateien öffne ich standardmäßig mit dem QT-Designer (kann man einstellen wenn man "öffnen mit" auswählt. Diese UI-Dateien aus dem QT-Designer müssen mit dem QT-Tool "uic.exe" verarbeitet werden, welches daraus Header-Dateien erzeugt, von denen meine jeweiligen Dialogklassen erben (siehe QT-Doku!).
Damit dieses automatisch geschieht, kann man in den Eigenschaften für die UI-Dateien unter "Konfigurationseigenschaften/Allgemein" einstellen, dass diese Date nicht "Vom Build ausgeschlossen" ist und kann den "Elementtyp" von "Ist nicht Teil des Build" auf "Benutzdefiniertes Buildtool" umschalten. Dort habe ich folgende drei Eintragungen vorgenommen:`Befehlszeile: $(QTDIR)/bin/uic.exe "%(fullpath)" -o ui_%(filename).h
Beschreibung: Compile QT UserInterface File %(Filename).ui
Ausgabe: ui_%(filename).h`
Um die Klassen mit dem Q_OBJECT Makro mit dem MOC-Tool von QT verarbeiten zu können, habe ich auch für diese Header einen speziellen "Filter" (Filter aber leer gelassen) in das Projekt eingefügt wo ich diese Header ablege. Ähnlich wie für UI-Dateien habe ich folgende Eigenschaften eingetragen:
`Befehlszeile: $(QTDIR)\bin\moc.exe "%(FullPath)" -o "%(RootDir)%(Directory)moc_%(Filename).cpp"
Beschreibung: Performing moc on %(Filename).h
Ausgabe: %(RootDir)%(Directory)moc_%(Filename).cpp`
Die resultierenden "Moc-Sourcedateien" füge ich noch dem Projekt hinzu.
Ab dann kann ich die UI-Dateien mit einem Doppelklick im QT-Designer bearbeiten und vor dem kompilieren werden automatisch uic.exe und ggf. moc.exe für geänderte Dateien ausgeführt. Keine QMake und keine PRO-Datei!
Ich hoffe, ich habe nichts vergessen und Visual Studio 2015 weicht nicht zu stark vom 2012 ab; mit freundlichen Gruß
Helmut
-
Ich habe aber das Gefühl, dass es eher "veraltet" und nicht so flexibel ist.
Dann ist es bestimmt schon länger her, dass du es benutzt hast. Ich kanns auch nur nachplappern, einfach weil ich erst nach Version 3 bei wxWidgets eingestiegen bin, aber es wird an allen Ecken davon geredet, dass mit Version 3 einiges radikale erneuert wurde. Und mit jeder Subversion tut sich da einiges (das kann ich tatsächlich eigenständig sagen). Ist vielleicht gerade ne Umbruchphase oder so.
Z.B. allgemein weniger Makros, dafür mehr Templates.
Oder nen konkreteres Alltags-Bsp.: Du hast die Wahl, ob du Events statisch zur Compilezeit, via der guten alten Event-Table (die ich persönlich sehr gerne nutze, der Übersicht und Performance wegen), oder zur Laufzeit dynamisch via Bind (einem erneuerten "Connect") verbindest.Und weil wxWidgets schon eine so lange Tradition hat, findet man im Netz verhältnismäßig mehr Tutorials, die sich auf veraltete Versionen beziehen. Der Haufen an mitgelieferten Programm-Beispielen ist aber aktuell und ausführlich dokumentiert.
Ich glaub nicht, dass wxWidgets Stylesheets kann.
Glaube ich fast auch nicht. Ich weiß nur von TextCtrls die das zumnindest ansatzweise unterstützen, habe mich aber noch nicht mit dem Thema beschäftigt. Geht das evtl. nur, wenn die Controls selbst gezeichnet werden?! Bei nativen Controls ist das dann selbstverständlich nicht möglich. Das muss man dann über Themes des OS machen, die dafür aber auch sicher erkannt bzw übernommen werden.
Ich habe mich noch etwas nach Qt-Eigenheiten umgesehen.
-Qt scheint nicht so performant zu sein, was wohl (auch) an der Emulation der Wigets liegt. Ist zwar meistens egal, aber wenns mal drauf ankommt, gibts eben nur realtime, oder nicht realtime ... oder nen neuen PC.
-Die Anwendungen sind wohl etwas größer. Das dürfte wohl wirklich egal sein, wenn man nicht gerade auf Diskette speichern muss...
-Außerdem habe ich gelesen, dass Qts MOC manchmal Probleme macht, indem er hier und da irgendwelche, sozusagen unnötige Beschränkungen auferlegt, weil es sich genau genommen eben nicht mehr um standard c++ handelt.
Das kann wohl echt harte Kopfschmerzen verursachen, wenns denn mal soweit ist.
-Keine Ahnung, ob das damit zusammenhängt, aber es wurde auch gesagt, dass Qt im Vergleich zu wxWidgets nicht so viel Feintuning erlaubt, was dann die Performance beeinflussen kann, oder ab und zu Lösungswege umständlicher macht.
-Und, worüber ich mir noch garkeine Gedanken gemacht habe, Qt ist wohl, weil es alles selbst rendert, nicht so barrierefrei, weil dann diverse Hilfssoftware, wie Screenreader, nicht mit den selbstgezeichneten Controls klarkommt, bzw native Controls erwartet, aber keine findet.Also wenn da was dran ist, und vieles finde ich recht einleuchtend, bin ich doch froh, mich für wxWidgets entschieden zu haben. Ich bin nämlich sonn verkappter "Performist" und frickel gerne an dem "perfekten Algo" für ein bestimmtes Problem rum (zumindest soweit mir das möglich ist).
Dazu zählen auch eigene Widgets. Klar sehen die dann nicht nativ aus, sind ja auch von mir gezeichnet. Aber wie ist das denn bei Qt mit dem Erstellen von eigenen Widgets/Controls und eigenen Events?? Bei wxWidgets ist das eigentlich straightforward: Von Widget-Basisklasse ableiten, falls eigenes/neues Event nötig, Eventobjekt erstellen und senden.
Das bringt mich gerade auf noch einen weiteren Punkt.. Theoretisch kann ich ja in wxWidgets auch durchweg eigene Controls verwenden. Wäre zwar viel Arbeit die alle zu schreiben und wohl eher eine Gemeinschaftsprojekt (vielleicht gibts sowas auch schon auf "wxCode" oder im "wxWiki"), aber es wäre immerhin möglich. Und dann hätte man quasi zusätzlich noch alle Vorteile die nicht-native Controls so mit sich bringen. Aber im Gegensatz dazu kann ich bei Qt nicht einfach mal so native Controls nutzen.
Also theoretisch kann wxWidgets Qt enthalten, aber nicht umgekehr. Qt als Untermenge von wxWidgets..
-
Wie gesagt, so wirklich toll finde ich Qt auch nicht. Vor allem stören mich die nicht-typsicheren Signals und Slots und der MOC. Hat sich in Qt 5 zwar geändert, das nutze ich aber weder in der Arbeit noch privat. Und mich stört auch so ein bisschen, dass man teilweise die Qt Widgets nicht ohne weiteres erweitern kann. Es gibt viele Möglichkeiten, etwas am Aussehen oder am Verhalten zu ändern, aber wenn man sich intensiv mit etwas beschäftigt, dann stößt man immer öfter an irgendwas, was man nicht ändern kann, ohne das in Qt selber umzubauen (was wir auch recht häufig machen, oder evtl. auch kopieren). Das ist jetzt kein Qt-spezifisches Problem, das ist natürlich mit allen APIs so, irgendwo muss man eine Grenze ziehen.
Ich hab gestern z.B. gesucht, ob es in wxWidgets TreeViews mit mehreren Spalten gibt. Ja, gibts wohl, aber nur die erste Spalte kann Checkboxen oder Icons enthalten. Ist eine Einschränkung, die es in Qt nicht gibt. Und wir benutzen häufiger sowas, und nicht nur das, wir haben auch andere Widgets in irgendwelche Spalten in Baumansichten.
Was die Performance angeht, kann ich dir jetzt nicht unbedingt Recht geben. Qt ist da schon recht gut und man kann auch viel beeinflussen. Was willst du beim Zeichnen von Controls auch großartig falsch machen? Dynamische Models usw. sind auch alles kein Problem. Wir haben teilweise sehr komplexe GUIs (kann mich nicht erinnern, etwas ähnlich komplexes mal in freier Wildbahn gesehen zu haben), die mit sehr vielen Daten umgehen müssen und teilweise ziemlich dynamisch sind. Alles kein Problem.
Ok, kein Problem ist vielleicht übertrieben. Das steckt schon viel Aufwand drin und teilweise muss man sich schon genau reindenken, wie das in Qt intern funktioniert, damit man das richtig hinbekommt. Aber es geht definitiv. Und sogar recht sauber.
