"This app was build onto of Qt 4.7. I've never tried compiling for Qt 5. You are welcome to help port it to Qt 5.0."
Nun, das Projekt ist ein Opensource-ODB++-Viewer – einen anderen konnte ich zumindest auf die Schnelle nicht finden. Insofern könnte sich ein wenig Aufwand ja mal lohnen.
Am Ende stolpere ich über die Art und Weise, wie dort Scrollbar-Events gehandhabt werden:
/usr/local/include/qt5/QtCore/qobject.h:222:36: note: candidate function not viable: cannot convert argument of incomplete type 'QScrollBar *' to 'const QObject *' for 1st argument
/usr/local/include/qt5/QtCore/qobject.h:225:36: note: candidate function not viable: cannot convert argument of incomplete type 'QScrollBar *' to 'const QObject *' for 1st argument
/usr/local/include/qt5/QtCore/qobject.h:481:41: note: candidate function not viable: cannot convert argument of incomplete type 'QScrollBar *' to 'const QObject *' for 1st argument
/usr/local/include/qt5/QtCore/qobject.h:222:36: note: candidate function not viable: cannot convert argument of incomplete type 'QScrollBar *' to 'const QObject *' for 1st argument
/usr/local/include/qt5/QtCore/qobject.h:225:36: note: candidate function not viable: cannot convert argument of incomplete type 'QScrollBar *' to 'const QObject *' for 1st argument
/usr/local/include/qt5/QtCore/qobject.h:481:41: note: candidate function not viable: cannot convert argument of incomplete type 'QScrollBar *' to 'const QObject *' for 1st argument
/usr/local/include/qt5/QtCore/qobject.h:222:36: note: candidate function
not viable: cannot convert argument of incomplete type 'QScrollBar *' to
'const QObject *' for 1st argument
Er kennt QScrollBar nicht. Evtl. einfach QWidgets includen?
1
#include<QtWidgets>
Im Übrigen würde ich empfehlen die SIGNAL() und SLOT() durch Funktionspointer-Schreibweise zu ersetzen, weil es nicht mehr zu Runtime-Errors führt (sondern compile-time) falls die signal/slot connection nicht erstellt werden kann. Ungefähr so (ungetestet):
Er kennt QScrollBar nicht. Evtl. einfach QWidgets includen?
Danke nochmal. Dass man QtWidgets explizit angeben muss (schon im qmake-Projekt und dann in den includes) ist offenbar eine der wesentlichen API-Änderungen zwischen Qt4 und Qt5 gewesen. Das include fehlte in diesem Projekt an vielen Stellen.
Jetzt habe ich es soweit mit Qt5 am Compilieren. Es gibt aber immer noch ein paar deprecation warnings, die würde ich auch noch aufräumen, dann sollte es vielleicht auch gleich Qt6-kompatibel sein.
Bei Qt hat man mit der Zeit immer weiter die sich gegenseitig inkludierenden Header reduziert, so das etwas, das in Qt4 noch implizit durch einen anderen Header mit reingezogen wurde, in Qt5 ggf. explizit eingebunden werden muss.
Ich würde aber auch nicht QtWidgets inkludieren, weil das ein Rundumschlag mit allem ist. Besser wäre es, nur die Widgets, die auch tatsächlich benötigt werden, einzeln einzubunden.
Ich würde aber auch nicht QtWidgets inkludieren, weil das ein
Rundumschlag mit allem ist. Besser wäre es, nur die Widgets, die auch
tatsächlich benötigt werden, einzeln einzubunden.
Das wäre jetzt schon sehr viel Feinschliff. Im Moment habe ich es mit QtWidgets (und ein paar anderen Änderungen) wenigstens erstmal mit Qt5 zum Compilieren bekommen. Qt6 braucht noch paar Handgriffe mehr (u.a. weil QRegExp dann wegfällt oder nur noch compat ist).
Erstmal möchte ich es aber auch sinnvoll laufen sehen. Soweit ist es leider im Moment noch nicht.
angehängt ist ein Patch gegen den aktuellen Stand in GitHub. Damit lässt sich QCamber zumindest unter Linux sowohl mit Qt5 als auch Qt6 (aber nicht mehr mit Qt4) bauen. Die regulären Ausdrücke sind auf QRegularExpression umgestellt, die Compat-Library wird daher unter Qt6 nicht benötigt.
Es scheint soweit auch zu laufen, allerdings habe ich es bisher nur mit der Beispieldatei von odbplusplus.com getestet.
(https://odbplusplus.com/wp-content/resource-docs/designodb_rigidflex.tgz)
Hmm, ich habe es jetzt mal mit einer aus KiCad exportierten ODB++-Datei getestet. Dabei stürzt QCamber direkt ab. Das Fehlerhandling der aktuellen Implementierung ist eher bescheiden, die Software verlässt sich sehr darauf, dass der Input genauso aussieht wie erwartet. Im konkreten Fall wird versucht, eine Datei "steps/pcb/attrlist" zu laden, die im KiCad-Export aber gar nicht existiert. Das wird aber nicht abgefangen, sondern führt in der Folge zu einem NULL-Pointer Zugriff.
Es ist auch nicht schön, dass QCamber nur ODB++-Dateien im Format .tar.gz lesen kann. KiCad exportiert aber nur .zip, das muss dann erst mal umgepackt werden.
Korrektur: Stimmt gar nicht, KiCad kann auch .tgz exportieren.
Ja, mindestens einen der Nullpointer-Abstürze habe ich hier im Debugger schon analysiert und korrigiert. Ich vermute, dass das noch nicht der letzte ist.
Man müsste das Teil auch noch umstellen vom externen Aufruf eines tar-Kommandos auf zlib, dann wäre sowohl .tar.gz als auch .zip gleichermaßen handhabbar, und man muss nicht noch auf Windows extra ein tar.exe beilegen, wie es die Demo-Binaries machen (die bei mir unter Wine aber auch nur crashen).
Ja, mindestens einen der Nullpointer-Abstürze habe ich hier im Debugger
schon analysiert und korrigiert. Ich vermute, dass das noch nicht der
letzte ist.
const StructuredTextDataStore::ValueType d = ds->getValueData();
12
for (StructuredTextDataStore::ValueType::const_iterator it = d.begin();
13
it != d.end(); ++it) {
Nachdem ich rausgefunden habe, wie man die Farben umstellt (wenngleich mir nicht klar ist, warum es nur 6 Farben sind und wie diese den Lagen zugeordnet werden), kann ich jetzt auch einen Kicad-Export damit anzeigen.
In einem anderen Projekt habe ich vor kurzem die KArchive-Library (https://github.com/KDE/karchive) benutzt.
Damit müsste man die Dateien noch nicht mal auf die Platte einpacken, sondern könnte die Inhalte direkt aus dem Archiv lesen. Könnte allerdings einen größeren Umbau erfordern. KArchive stammt zwar vom KDE-Projekt; anders als der Name vermuten lässt werden aber nur Qt- und keine KDE-Libraries benötigt. Ausserdem erfordert zumindest der aktuelle Stand von KArchive Qt6.
In einem anderen Projekt habe ich vor kurzem die KArchive-Library
(https://github.com/KDE/karchive) benutzt.
Damit müsste man die Dateien noch nicht mal auf die Platte einpacken,
sondern könnte die Inhalte direkt aus dem Archiv lesen.
Naja gut, für ein größeres Projekt ist es sicher gar nicht so schlecht, die Platte gewissermaßen als Cache zu haben. Zip lässt sich ja random access zugreifen, aber .tar.gz nicht, das geht immer nur im ganzen Stream.
Außerdem ist zlib halt (wie wir seit dem letzten security issue wissen ;-) praktisch mittlerweile omnipräsent.
Außerdem bräuchte das Ganze wohl zumindest eine leicht zu findende Hilfe-Funktion und vielleicht ja auch noch ein paar Standard-Dinge wie File -> Exit. Das Herausfinden der Bedienung war jedenfalls teilweise schon mal eine Herausforderung.
Ich sehe auch gerade, dass im Projekt sonst an vielen Stellen "if (!ds)" als Test benutzt wird. Das würde ich daher aus stilistischen Gründen dann auch so machen.
angehängt ist ein Patch gegen den aktuellen Stand in GitHub.
Ich habe das als PR eingereicht.
Ich hatte gerade noch festgestellt, dass bei mir der Zoom via Mausrad nicht funktionierte. Ich habe in
ODBPPGraphicsView::wheelEvent()
mal ->pixelDelta durch ->angleDelta ersetzt. So, wie ich die Doku verstehe, gibt es angleDelta immer (ggf. halt mit großen Sprüngen), während pixelDelta nicht immer ein Ergebnis bringen muss. Extra noch eine Fallunterscheidung fand ich für das bissel Zoom jetzt auch nicht sinnvoll.
Dann werde ich mal meinen Stand mit der Repo synchronisieren. Ich habe noch ein paar weitere Änderungen gemacht, z.B. den StructuredTextParser von Hand implementiert, so dass Flex & Bison nicht mehr gebraucht werden. Ich habe zwar prinzipiell nichts gegen Flex/Bison, aber es ist immer etwas mühsam, Versionen zu finden, die auch mit Windows funktionieren. Ein alternativer und einfacherer Ansatz wäre, die generierten Files mit in die Versionsverwaltung aufzunehmen; da wird ja normalerweise nichts mehr geändert werden müssen.
Ich spiele auch immer noch mit dem Gedanken, KArchive einzubinden. Naja, vielleicht irgendwann einmal, in den letzten drei Wochen habe ich nichts mehr daran gemacht.
Ein alternativer und einfacherer Ansatz wäre, die generierten Files mit
in die Versionsverwaltung aufzunehmen; da wird ja normalerweise nichts
mehr geändert werden müssen.
Selbst wenn, könnte man ja die neu generierten Dateien ebenfalls mit aufnehmen.
Erscheint mir zumindest ein sinnvollerer Ansatz, als Zeit in einen handgestrickten Scanner/Parser zu investieren.
... als Zeit in einen handgestrickten Scanner/Parser zu investieren.
Das stimmt zwar, aber nur weil der Parser bereits fertig implementiert war.
Der von Hand geschriebene Parser ist mit 73 Zeilen Code sogar kleiner als die Flex/Bison Definitionen, ganz zu schweigen vom daraus generierten Code.
begeistert habe ich gerade festgestellt, dass das QCamber-Projekt noch lebt.
Die verlinkte 32-Bit exe ist ein bisschen veraltet, könnte jemand, der ein lauffähiges System hat die mal aktualisieren? Dann könnten alle von der Arbeit der Vorgänger profitieren!
Ich habs mal selbst probiert, aber es scheiterte bereits an der Installation von QT...
Jemand hat den Issue erstellt, man könnte das ja in KiCad integrieren. Gute Idee, aber ich denke mit QT und Kicad dürfte das eher schwierig werden, oder?
Ich habs mal selbst probiert, aber es scheiterte bereits an der
Installation von QT...
Man wächst mit seinen Aufgaben. Das ist ja das schöne an Open Source, man kann alles selber machen. Das gute an Open Source ist, dass „es müsste mal jemand“ niemals funktioniert, wenn man nicht selbst der jemand ist.
Eigentlich ist die Installation von QT doch einfach:
Maintenance Manager installieren, da drin die gewünschte Version auswählen, eventuell noch eine MinGW-Toolchain, falls erforderlich, auf Installieren klicken, Kaffee trinken gehen, und fertig.
