4. VS2015 + QT

VS2015 + QT

  • R

    Th69 schrieb:

    Qt5 Tutorial Visual Studio Add-in - 2015
    Demnächst aber selber danach suchen...

    Das hatte ich schon gefunden, allerdings funktioniert das Addin mit VS2015 bei mir nicht.

    Mechanics schrieb:

    Du brauchst eine pro Datei, die dein Projekt beschreibt:

    http://doc.qt.io/qt-4.8/qmake-project-files.html

    Für eine Basisversion reicht sowas:

    TEMPLATE=app
    TARGET=myproject
    CONFIG-=flat

    SOURCES+=
    HEADERS+=

    Also die cpp und die h Dateien angeben (*.cpp geht auch, aber nicht rekursiv).
    Dann kann man bei Bedarf noch mit
    INCLUDEPATH+=
    zusätzliche Includepfade und mit QMAKE_LIBDIR und LIBS Libverzeichnisse und Libs angeben. Viel mehr braucht man normal nicht und kann sich das dann bei Bedarf zusammensuchen.

    Dann führst du in dem Verzeichnis wo die pro liegt qmake -tp vc aus und das erstellt dir ein Visual Studio Projekt.

    Muss ich die qmake für jede neue Datei die ich dem Projekt hinzufüge, neu erstellen oder kann ich das dann wie gewohnt in VS machen, sobald das Projekt einmal erstellt ist?

    EDIT: Muss ich im VS noch die Include/Lib-Pfade einbinden? Wenn ja, welche?

    Gruß

    0
  • M

    Wenn du Dateien hinzufügst, musst nochmal qmake aufrufen. Zumindest ist es mein Workflow, ich lege neue Dateien im Dateisystem an und ruf dann nochmal qmake auf.

    Wegen den Include und Lib Pfaden hab ich ja schon was geschrieben. Das Ziel ist, dass das qmake Projekt vollständig ist und du in VS nichts mehr anpassen musst. Ob du zusätzliche Includes oder Libs brauchst, musst du selber wissen. Wenn du keine brauchst, dann brauchst du eben keine 😉

    0
  • M

    Hallo Raven, als Anfänger in der Programmierwelt möchte ich dir Mut machen, erst mal die grundsätzlichen Zusammenhänge von Compiler,Assembler,Linker zu verstehen. Dann ist es nämlich völlig egal mit welchem Compiler,IDE,Build-System,Betriebsystem... du arbeitest.
    Ich persönlich benutze zur Zeit eine CMake/Ninja/QtCreator Umgebung. Damit ist der Workflow für mich deutlich einfacher und schneller als mit VS.

    0
  • B

    Mechanics schrieb:

    Ja. Aber dann sehe ich erst recht keinen Grund, QtCreator zu verwenden.

    Ich finde den Editor und die Projektverwaltung vom QtCreator deutlich besser als beim VS und nutze deswegen auch QtCreator mit dem VSCompiler (und Debugger). Dazu braucht man dann noch das WindowsSDK. Das ist etwas fummlig einzurichten, geht aber.
    Gerade im Zusammenhang mit MinGW hatte ich (besonders bei Creator-Versionen über 2.8) immer wieder Probleme mit dem Debugger.

    0
  • M

    Grad VS2015 hat nochmal deutlich zugelegt, was C++ Unterstützung angeht, und da seh ich nochmal erst recht keinen Grund, den Qt Creator zu benutzen 😉

    0
  • F

    Mechanics schrieb:

    Grad VS2015 hat nochmal deutlich zugelegt, was C++ Unterstützung angeht, und da seh ich nochmal erst recht keinen Grund, den Qt Creator zu benutzen 😉

    Öhm wiso, nur weil der compiler + die c++ runtime mehr c++11 + c++14 features kann muss man nicht unbedingt Visual studio als IDE verwenden...

    0
  • M

    Doch, die IDE hat sehr viele neue Debugging und Refactoring Funktionen bekommen.

    0
  • P
    Mod

    Mechanics schrieb:

    Grad VS2015 hat nochmal deutlich zugelegt, was C++ Unterstützung angeht, und da seh ich nochmal erst recht keinen Grund, den Qt Creator zu benutzen 😉

    Wenn sie wenigstens voll C++11 unterstützen würden...
    ... leider wird auch in dieser Version Eric Nieblers Range Library nicht compilieren...

    QtCreator ist vor allem wegen des RAD Editiors sehr gut, gibts da Alternativen in VS?

    0
  • B

    Was die neuen Features vom VS2015 betrifft ist da für mich eh uninteressant, da bei uns alles über C++03 nicht gestattet ist. Ich arbeite ja sowieso auch noch mit dem VS2010 und Qt 4.8.
    Evtl. ändert sich das aber dieses Jahr noch. 🙂

    0
  • M

    Was meinst du mit dem RAD editor?

    0
  • ?

    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

    0
  • _

    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

    0
  • M

    Qt zu kompilieren ist kein Problem.

    0
  • ?

    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?

    0
  • ?

    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: 😉 ?!?

    0
  • F

    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

    0
  • F

    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

    0
  • ?

    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).

    0
  • M

    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.

    0

  • 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

    0
Anmelden zum Antworten