eigene Widgets, in ne "Library" unter windows ?

[RHBaum]

Hab erst vor kurzen angefangen mich in QT einzuarbeiten, sprich habs aufs Auge gedrueckt bekommen 8)

Iss aber erfrischend einfach und komfortabel .... trotzdem hab ich ne grundsaetzliche Frage :

Ich arbeite an mehreren "Projekten", sprich kleineren Tools - unabhaengige binaries (.exe). Die haben aber die Gemeinsamkeit, dass sie auf eine bestimmte Hardware zugreifen, welche konfiguriert werden muss.
Also alle diese kleinen programme sollten einen einheitlichen dialog zur konfiguration der Hardware haben.
Ok Prinzipiell kein Thema.
Von QDialog und QWidget ableiten, geht alles schoen.

Momentan kopier ich aber die codeanteile in die unterschiedlichen Projecte (sprich ich nehm die header und sourcen, kopier sie in alle Projectverzeichnisse , lass mir die moc dateien generieren ... ) was ich unschoen finde.

Wie lagert man sowas in ne Biblothek aus ?
Unter win32 oder mfc hab ich dll's fuer geschrieben, welche mir die dialoge erstellt haben, als parent konnte man ja einfach das windowshandle nehmen .... und schon war der ganze dialog gut in ner dll ausgelagert.
unter QT hab ich noch nix gefunden, wo ich nen windowshandle als parent fuer nen dialog nehmen kann ....

unter QT prauch ich ja fuer den dialog nen zeiger auf das Parentwidget ... den bekomm ich aber nicht "sauber" ueber ne c-dll schnittstelle.

Ne nadere moeglichkeit wenn man keine Biblos zu linken will, iss alles im header implementieren .... dann generierts der compiler wenn das tool erstelle immer neu .... macht sich mit QT schlecht, weil ich die gemocte cpp datei ja nich da reinbekomme ....

Bleibt noch ne statische lib .... hab da aber nix gefunden in der QT doc, wie man statische libs erstellt, auch gibts keine hinweisse auf projecteinstellungen ... weswegen ich da noch vorsichtig bin ....
Kann es damit probleme geben ?

Wie macht ihr das, wie erstellt ihr zur benutzung fertige Biblotheken unter QT ?

Ciao ...

P.S.
Hab hier QT 3.3.4 enterprice und MSVC 6.0 SP3 am laufen ....
Plattformunabhaengigkeit spielt hier keine rolle, weil die hardwaretreiber wird es nich unter nem anderen BS geben ... ausserdem iss in unser Firma Windows festvorgeschriebener Standard für alle "Arbeitsstationen", leider ...

[Christian81]

Was hält dich davon ab die komplette Klasse zu exportieren und dann in deinen Programmen diese einfach zu benutzen?

[RHBaum]

Was hält dich davon ab die komplette Klasse zu exportieren

Mein Gewissen

Name mergeling unter windows issn problem, weil es eben kein "System" compiler gibt ...
Sprich wenn ich ne DLL die klassen exportiert unter MSVC 6.0 compiliere, laeuft die nimmer mit anderen compilern (glaub auch nicht mal mehr mit dem 7er MSVC).
Deshalb "empfiehlt" MS, eben alle dll-schnittstellen als C-Schnittstellen (keine klassen) auszufuehren .... damit die auch unter sonstwas fuer compiler / interpreter laufen ....

In meinem Fall waer das zwar wurscht ... weil ich die dlls und alle anwendungen selber in der hand hab und selber versionieren kann, trotzdem hab ich dann skrupel ...

OK die MFC machts selber eigentlich auch (MFC erweiterungs-Dll) .... was ich aber immer vermeide.

Wie gesagt, unter unix seh ichs ned als das problem, weil ich da bei der installation entweder neu compiliere, oder auf meinen compiler zugeschnittene binaries verwende ....

unter windows kommt dann die compilerversion noch in die versionierung rein -> kann in chaos ausarten ...

Bei ner statischen lib entfaellt die ganze versionierung, auf kosten der codegroesse, glaub aber bei unseren usern iss mir es das wert

Momentan probier ich grad mit statischen libs, und es scheint ohne probs zu funktionieren .... wenn man mal die projekteinstellungen alle beisammen hat :p

Ciao ...

[Christian81]

Aber mit der Qt-Dll hast Du doch schon eine solche Abhängigkeit... da macht eine zweite auch nichts mehr.
Statische Libs sind auch eine Idee, wobei eben dann dein executable recht gross werden kann.
Wegen den Projekteinstellungen - warum nimmst Du nicht qmake (zumindest als Hilfe)

[RHBaum]

Aber mit der Qt-Dll hast Du doch schon eine solche Abhängigkeit

Aehm sicher ?

Ich linke bei der QT doch statisch gegen eine lib, welche mir dann die dll dynamisch anzieht ....
bist sicher das da klassen exportiert werden ?

Weil ich glaub ich kann nen project was ich mit VC 6.0 und der zugehoerigen lib erstellt hab, mit der gleichen dll laufen lassen, als wie mit dem mingw erstellte exe und entsprechender Lib. Die beiden mergeln definitiv die klassennamen unterschiedlich, so das die dll uner mingw compiliert andere symbole exportieren mueste als wie die vom ms compiler.
Und trotzdem funktionierts .... denk mal die statische lib wrappt da ne ganze menge .... und die schnittstelle zur dll is ohne exportierte klassen ....

Wegen den Projekteinstellungen - warum nimmst Du nicht qmake (zumindest als Hilfe)

Wie gesagt kenn mich noch ned so aus mit der QT ... und das plugin fuer den VC 6.0 iss so schoen easy ... :p
aber wahrscheinlich komm ich ned umhin, mich mit qmake weiter zu beschaeftigen ....
Kann ich dann das project noch unter der MSVS Oberflaeche verwalten, oder hakt das mit den qmake einstellungen (hab dann sicher nen anderes projektfile *.pro != *.dsp )
Wenn ich die IDE nich nutzen kann (zur Project und makefile verwaltung), und die MFC eh nich nehme, sollt ich dann kann ich mir den umstieg auf den gcc echt ueberlegen :p

Ciao ...

[Christian81]

Aber mit der Qt-Dll hast Du doch schon eine solche Abhängigkeit

Aehm sicher ?

Ich linke bei der QT doch statisch gegen eine lib, welche mir dann die dll dynamisch anzieht ....
bist sicher das da klassen exportiert werden ?

Weil ich glaub ich kann nen project was ich mit VC 6.0 und der zugehoerigen lib erstellt hab, mit der gleichen dll laufen lassen, als wie mit dem mingw erstellte exe und entsprechender Lib. Die beiden mergeln definitiv die klassennamen unterschiedlich, so das die dll uner mingw compiliert andere symbole exportieren mueste als wie die vom ms compiler.
Und trotzdem funktionierts .... denk mal die statische lib wrappt da ne ganze menge .... und die schnittstelle zur dll is ohne exportierte klassen ....

nein, da liegst Du falsch. Die lib die Du siehst ist nur ne import-lib um nicht die blöden .def-Files benutzen zu müssen. Und du kannst nicht die qt-dll für mingw mit einem Programm welches mit msvc gelinkt ist, benutzen.

Wegen den Projekteinstellungen - warum nimmst Du nicht qmake (zumindest als Hilfe)

Wie gesagt kenn mich noch ned so aus mit der QT ... und das plugin fuer den VC 6.0 iss so schoen easy ... :p
aber wahrscheinlich komm ich ned umhin, mich mit qmake weiter zu beschaeftigen ....
Kann ich dann das project noch unter der MSVS Oberflaeche verwalten, oder hakt das mit den qmake einstellungen (hab dann sicher nen anderes projektfile *.pro != *.dsp )
Wenn ich die IDE nich nutzen kann (zur Project und makefile verwaltung), und die MFC eh nich nehme, sollt ich dann kann ich mir den umstieg auf den gcc echt ueberlegen :p

Ciao ...

Nein, entweder qmake oder die IDE - aber zum ersten Erstellen des Projektes kannst Du qmake benutzen und später dann den Rest mit der IDE machen (so mache ich das meist).

[RHBaum]

Glaub echt mal gelesen zu haben, dass man eigentlich nur die umgebungsvariable QMAKESPEC umsetzen muss und schon kann man zwischen dem ms und dem gcc hin und herschalten. Ohne die dll qt_mtxxx.dll neu zu generieren. oder nimmt der gcc ne andere dll her ?

Wenns nich so ist, hasst recht, dann bin ich eh so schon abhaengig und brauch meine eigene dll nich generisch halten ....

Ciao ...

[taki]

Such doch mal in der Qt-Referenz nach Plugin. Ein Plugin wird als dynamsiches verteiltes Objekt realisiert (shared dynamic object). Also müsste sich damit doch unter Win eine dll erzeugen lassen, die Du dynamisch in Deine Programme einbinden können müsstest.

Ich habe in meinem Programm (Kalva) Plugins mit dem KDE-Framework erstellt und eingebunden. Diese werden über .so Dateien (shared library) eingebunden. Mit Win kenne ich mich nicht aus. Aber das müsste m.E. ganz ähnlich funktionieren, da die entsprechende KDE-Klasse direkt von der Qt-Klasse Plugin abgeleitet ist. Es dürfte nur ein kleines bischen mehr Handarbeit angesagt sein, um das Finden und Laden des Plugins zu realisieren.

[RHBaum]

Ok mit PlugIns unter windows kenn ich mich wiederum etwas aus ...

Glaub das funzt aequivalent wie unter Unix .... nur die Namen der systemfunktionen heissen sicher etwas anders

Aber wie gesagt, grade bei plugins unter win scheue ich mich, klassennahmen zu exportieren ... weil unter windows issn kompilerwechsel wahrscheinlicher ... ok, neuer gcc auf unix, und man muss eh alles neu compileieren. unter windows geht das schon deshalb meist nich, weil die sourcen nich mitgeliefert werden
Und ich selber hab schon mal 3 compiler auf meiner kiste, die zueinander nich kompatibel sind ... den gcc (mingw) den VC 6.0 und den VC 7.0. weil manche eben ihren code nicht in C-dlls packen (sondern als libs ausliefern) und dich die auch teilweise verwenden muss ...

Ich hab meine "Plugins" immer nur mit c-schnittstellen versehen, grade um sie von der kompilerversion unabhaengig zu machen (intern isses wurscht was du verwendest). Das bringt zwar bei der entwicklung maechtig overhaed, erspart aber bei der pflege und wartung spaeter enorm nerven und Zeit ....

Und wie gesagt aufs dynamische laden kams mir gar nich an ... ich muss es eh in jeder applikation anziehen .... mir kams nur drauf an, wiederverwendbaren code irgendwo zentral abzulegen ... ohne viele grosse probleme ....

Glaub meine "Allergie" gegen klassensymbole in dlls kommt wirklich nur aus dem Umfeld hier

Ciao ...

[FlorianBecker]

Ich denke, ich habe das ultimative für dich:

ClassLoading Framework - factory++

Das ist eine Template Library in C++, die Plugins wie Klassen benutzen kann, aber eben als Plugins. Die während der Laufzeit ausgewechselt werden können und die ganzen Spielereien. Ist eine Template Lib mit 5 Dateien und eben Cross Plattform.

Link habe ich nicht parat, aber der Entwickler ist ein Schweizer und wenn du ein wenig Googlest findest du die ganz schnell. In dem Debian Tree ist die Lib enthalten.

[taki]

QPlugin ist doch auch eine template factory?! Ist das nicht mindestens genauso portabel?

Ich kenne mich noch nicht so richtig gut mit den c++ Feinheiten aus - bei KDE ist das alles gut gekapselt, so dass ich es nicht im Detail verstehen musste um es anzuwenden. Aber auf jeden Fall bin ich mir sicher, dass man auch für eine von QPlugin abgeleitete Klasse eine Factory erstellen muss, um mit dem Plugin arbeiten zu können. Und vom Lesen (Vorsicht: Halbwissen) weiß ich, dass Qt viel mit Templates arbeitet.

[FlorianBecker]

Ja, aber Template und Class Loading sind 2 paar Stifel.

STL = Template Library - only!
Qt = Lib die gelinkt werden muss. Manche Klassen sind Templates.

Class Loading geht ja darum, dass du unabhängige Programme ohne main Funktion, also Plugin, wie eine Klasse innerhalb einer Lib die du linken würdest, einbinden kannst.