Neues YouTube-Video – Qt-Tutorial 012: Unser erstes Programm layouten

Nachdem wir einfach ein paar Komponenten in unser Programm gezogen haben, sollten wir beginnen, mit Layouts zu arbeiten. Ich zeige kurz, wie man das bei unserem Programm macht. Dabei zeige ich auch, wie man Spacer benutzt.

Unser erstes Programm layouten
Unser erstes Programm layouten

Wir beschäftigen uns mit ganz einfachen Layouts. Die ersten Erfolge kommen schnell: der Inhalt des Formulars wächst und schrumpft beim Vergrößern oder Verkleinern des Dialogs.

Hier geht es zum Video.

Neues YouTube-Video – Qt-Tutorial 007: Meine QtCreator-Einstellungen

Im neuen Video geht es darum, wie ich meinen QtCreator eingestellt habe. Vor allem habe ich die Einrückungen im Texteditor eingestellt (Tabs statt Leerzeichen, bestimmte Einrückungen, uvm.).

Meine QtCreator-Einstellungen
Meine QtCreator-Einstellungen

Ich füge hier einmal die Screenshots der Einstellungen ein:

Environment -> Interface
Environment -> Interface
Text Editor -> Font & Colors
Text Editor -> Font & Colors
Text Editor -> Behavior
Text Editor -> Behavior
Text Editor -> Display
Text Editor -> Display
Text Editor -> Completion
Text Editor -> Completion
C++ -> Code Style
C++ -> Code Style
C++ -> Code Style -> General
C++ -> Code Style -> General
C++ -> Code Style -> Content
C++ -> Code Style -> Content
C++ -> Code Style -> Braces
C++ -> Code Style -> Braces
C++ -> Code Style -> Switch
C++ -> Code Style -> Switch
C++ -> Code Style -> Alignment
C++ -> Code Style -> Alignment
C++ -> Code Style -> Pointers and References
C++ -> Code Style -> Pointers and References
C++ -> File Naming
C++ -> File Naming

Hier geht es zum Video.

(Vor dem Import muss die Datei entpackt werden!)

Portierung eines Delphi-7-Projekts nach FreePascal und Lazarus

Hach, alte Software. Alte, gewachsene Software. Alte, gewachsene, ungepflegte Software. Ja. Wer kennt es nicht? Da gibt es ein Projekt, das hat bestimmt gut fünfundzwanzig Jahre auf dem Buckel und wurde, bis zuletzt, noch mit Delphi 7 „gepflegt“. Von gepflegt kann eigentlich nicht die Rede sein, doch wurden noch minimale Erweiterungen und, allem voran, Verschlimmbesserungen gemacht. Jeglicher Unsinn. Was aber versäumt wurde war, das Projekt, was bei hunderten von Kunden eingesetzt wird, auf eine aktuelle Plattform zu migrieren, damit eine vernünftige und saubere Weiterentwicklung überhaupt noch möglich ist.

Lazarus-IDE

Da komme ich ins Spiel. Problemlöser, Beruhiger … ja, einfach der, der das schlimme Los zog. Ich war zur falschen Zeit am falschen Ort.

Es war so, dass die Weiterentwicklung mit Delphi 7 in der Form nicht mehr möglich war. Die letzte Windowsbetriebssystemversion, auf der Delphi 7 wohl annehmbar lief, war Windows 7, welches ja bereits 2020 abgekündigt war. Ich habe Delphi 7 auf Windows 7 ausprobiert. Es war die Hölle. Stabilität war faktisch nicht vorhanden. Abgesehen von der unsinnigen Weiterentwicklung auf einer uralten, veralteten Plattform mit einem nicht unterstützten Betriebssystem war das Problem, dass Delphi 7 andauernd Fehler warf, stehen blieb, abstürzte. Abgesehen davon gab es in dem Projekt – teils absolut unnötige – Abhängigkeiten, die mitunter zwanzig (20!) Jahre alt waren.

Ich sah drei Möglichkeiten: 1. Ich kündige. Tja, Frau, Kinder und Haus …, also 2. Migration zu Delphi in einer aktuellen Version oder 3., und da war ich mir absolut nicht sicher, wie klug das war, Migration auf eine freie Plattform mittels FreePascal und Lazarus. Der Titel verrät, wofür wir uns entschieden.

Delphi in einer aktuellen Version war meinem Chef nicht nur zu teuer (?!), der Migrationsaufwand aufgrund des alten Codes und der noch schlimmeren Abhängigkeiten, wäre, so dachte ich, mindestens genau so groß gewesen, wie die Migration auf eine andere Plattform. Natürlich bin ich recht naiv an die Sache herangegangen, hatte ich doch wenig Erfahrung mit FreePascal und Lazarus, abgesehen von meinem Spieltrieb, den ich daran ab und zu mal auslebte. Aber was wusste ich? Ich fand, aufgrund meiner Tests, dass die Plattform stabil genug war und ist. Ich spiele gerne mit Technologien und ich habe mir Lazarus und FreePascal über Jahre hinweg angesehen. Die anfänglichen Probleme von vor einer Dekade waren behoben, FreePascal lief eigentlich schon immer ganz gut und Lazarus mauserte sich zu einer stabilen IDE. Ich schlug meinem Chef diese Lösung vor und ich denke, das Hauptargument war „kostenlos“. Ob er den Rest hörte, weiß ich nicht.

Also machte ich mich daran, mich tiefergehend mit FreePascal und Lazarus zu beschäftigen, Blog- und Forenartikel dazu zu lesen und ein oder zwei kleine Testprojekte damit zu schreiben, um das System und die Probleme kennenzulernen. Pascal lag bei mir bereits gut zwanzig Jahre weit weg und ich hatte das nur in zwei kleinen Projekten in meiner alten Firma eingesetzt. Ich kam immer mehr rein.

Dann schnappte ich mir eine virtuelle Maschine, warf ein Windows 7 an, schauderte mich als alter FreeBSD– und Mac-User, installierte Delphi 7 und TortoiseSVN, checkte das alte Projekt aus und installierte alle Abhängigkeiten, die mir die gut zwanzig Jahre alte Doku des Projekts preisgab. Diese elende Abhängigkeitenhölle. Abhängigkeiten, um eine „hübschere“ Toolbar hinzukriegen, oder Abhängigkeiten, um eine Pfadauswahl zu implementieren. Die alten Programmierer lebten faktisch die Abhängigkeitshölle und genossen sicher, dass eines Tages ein kleiner Programmierer den Quatsch ausbaden müsse.

Nachdem ich guten Gewissens alle mir bekannten Abhängigkeiten mit teils Windows 3.11-Installationsprogrammen installiert hatte (und hey, dass das Zeug noch lief … man kann von Microsoft ja halten, was man will, aber ich war schon beeindruckt), lud ich das Projekt. Das bedeutet, ich versuchte, es zu laden. Ich weiß nicht, wie die alten Programmierer das zusammengebastelt hatten, aber man musste tatsächlich noch Projekteinstellungen an seine individuelle Entwicklungsumgebung anpassen. Normal? Nein. Stell dir mal vor: du checkst ein Projekt aus, auf irgendeinem Computer, und du musst dann noch die Projektdatei an deine Pfade usw. anpassen, weil dort der Benutzername drin steht. Das geht doch nicht! Und es war einiges und es dauerte noch viel länger, bis ich aufgrund der kargen Doku das Ding mal soweit hatte, dass nicht mehr gemeckert wurde. Ich sage das jetzt mal so: bitte, bitte, bitte, dokumentiert nicht das Offensichtliche (function SchreibeVornamen() // Diese Funktion schreibt den Vornamen…), sondern das, was eben nicht offensichtlich ist. In diesem Projekt wurde, und das mit einer solchen Begeisterung und einem solchen Arbeitsaufwand, nur das Offensichtliche dokumentiert.

Gut, es lud jetzt, es kompilierte. Naja, ab und an. Mal klickte ich auf „Play“, dann kompilierte es, mal auch nicht (ohne Code-Änderung), mal startete es, mal nicht, mal hing es sich auf und dann hing sich ganz Delphi auf. Es war nicht tragbar und wieder einmal wunderte es mich, wie man früher so arbeiten konnte (ich konnte das noch nie).

Nach dem Spruch „Man kann nicht alles haben.“ durchwühlte ich den Code. Ich durchwühlte ihn nach den ganzen Abhängigkeiten, die ich ja unter FreePascal und Lazarus nicht mehr zur Verfügung haben sollte. Ich fand viele Stellen, die man einfach nicht brauchte oder für die Lazarus eigene Komponenten mitbrachte. Ich begann, auszuklammern und zu schauen, was noch lief oder was einfach nur sinnlos darin war. Ich fand so einiges. Als ich nach einigen Tagen der Pein dachte, fertig zu sein, dachte ich mir: Jetzt ist der Zeitpunkt da, an dem ich versuche, die Spaghetti … erm, den Code in Lazarus zu importieren.

Lazarus bietet einen Import von Delphi-Projekten an. Danke, liebe Lazarusentwickler. Der Dank ist ernstgemeint, denn der Import funktioniert gut. Nicht sehr gut, aber gut. Während des Imports zeigt das System bereits mögliche Probleme an, fehlende Units und so kann man sich, Notizen machend, schon einmal darauf einstellen, dass ein einfacher Import wohl sicher nicht den Segen bringt, den man so dringend bräuchte. Ich importierte, notierte, importierte erneut, notierte wieder. Sprang mit meinen Notizen wieder zurück zu Delphi und versuchte, weitere Probleme zu beheben oder zumindest zu minimieren. Commit, Checkout, Import, Notizen.

Irgendwann war ich dann soweit, dass der Import gut durchlief. Das hatte aber auch Tage gedauert. Ich war aber sehr stolz auf mich. Dann klickte ich auf „Kompilieren“. Ich musste noch einige Units entfernen, einige Funktionen und Prozeduren ausklammern, einigen Code umschreiben, aber irgendwann, recht schnell, wenn ich mich recht erinnere, kompilierte das Projekt dann durch. Nachdem ich auch Firebird inklusive Abhängigkeiten am Rennen hatte, haute es mich aus den Socken: Das Ding startete. Es startete. Es kam … tatatataaaa … die Login-Maske. Zumindeste schätzte ich, dass sie es wäre, denn sie war noch leer. Ich schloss den Tag trotzdem als erfolgreich ab. Ich fand dann recht schnell heraus, dass ich teilweise Ressourcen-Dateien ausgeklammert hatte und als ich sie wieder einklammerte und die Endung .dfm in .lfm umschrieb, die Masken (fast) 1:1 so aussahen, wie in Delphi. Ich arbeitete mich langsam vor, Maske für Maske für Maske. Ich wusste, es würde ein langer Weg werden, der noch weitere Stolpersteine haben sollte.

Einer dieser Stolpersteine war tatsächlich, dass einige Masken/Dialoge in Delphi binär und nicht in Textform abgespeichert waren. Komischerweise waren das von gut fünfzig Dialogen fünf oder sechs. Das Problem ist einfach zu lösen. In Delphi 7 öffnet man den Dialog und speichert ihn als Text, so dass man ihn in Lazarus benutzen kann. Dialoge, die per Text beschrieben werden, haben gegenüber den binären Dialogen den entscheidenden Vorteil, dass man sie mit jedem beliebigen Editor öffnen und bearbeiten kann, während sie auch mal aus Inkompatibilität eben nicht mit Lazarus GUI-Editor laden.

Es war eine Menge Tipperei, Ausklammerei, Umschreiben von Code, Entfernen von altem Code und Schreiben von neuem Code. Vor allem einiges an der Datenbankschnittstelle musste geändert werden, da wohl IB nicht hunderprozentig wie IBX funktioniert, vor allem im Transaktionsbereich.

Ich war dann aber sehr stolz, als die gesamte Basis der Software lief und fast so aussah und sich verhielt, wie sie es davor bei Delphi auch tat. Dann kam aber der Teil, der mir am meisten Bauchschmerzen bereitete. Im alten Projekt wurde QuickReport benutzt, um Reports zu generieren, das Drucken zu übernehmen und PDFs zu erzeugen. Gibt es QuickReport nicht mal mehr für ein aktuelles Delphi und ist die alte Version anscheinend nur mit Gefrickel und neueren Delphi-Versionen zum Laufen zu überreden, gibt es das Projekt gar nicht für Lazarus. Das bedeutet: Keine Reports, kein Drucken, kein PDF-Export.

Ich sah mir dann drei oder vier verschiedene kostenlose Report-Generatoren an, die sich über den Lazarus-Online-Packager installieren liessen. Alles unfertig. Der einzige Report-Generator, den ich halbwegs brauchbar fand und finde, heißt FortesReport. Dieser ist sehr nah an QuickReport und lässt sich ähnlich bedienen. Man baut die Reports mit dem Lazarus-GUI-Builder zusammen und kann sie dann aufrufen und mit Daten füllen. Ein Problem gibt es aber an FortesReport, welches nicht zu unterschätzen ist: Die Dokumentation. Diese gibt es nämlich nicht.

Wer mich kennt weiß, ich bin faul. Jemand meinte mal zu mir, alle Programmierer sind faul. Also überlegte ich nach einem Weg, wie ich das QuickReport-Zeugs zum FortesReport-Zeugs konvertiert bekomme. Und während ich so nachdachte, googlte ich und fand jemanden, der das selbe Problem hatte. Ich war nicht alleine auf dieser Welt. DACConv heißt das Programm. Die Software macht nicht viel mehr, als in den Pascal-Dateien und in den LFM-Dateien Klassennamen und Variablennamen anhand bestimmter mitgelieferter Schemata auszutauschen. Abgesehen von der echt schlechten Bedienung der Software macht sie ihren Job aber fein. Nur leider bleibt Handarbeit nicht erspart, denn teils müssen Bänder umgebaut werden, teils müssen Objekte entfernt werden, die einfach von FortesReport nicht unterstützt werden. Aber es geht allemal schneller, sehr viel schneller, als die Reports vollständig von Hand neuzubauen.

Ist das alles geschafft, kann man stolz auf sich sein. Das Projekt lässt sich reproduzierbar kompilieren und läuft und auch die Reports sehen aus, wie im Original.

Ist das alles also einfach gewesen? Nein. Man benötigt bereits einiges an Erfahrung, viel Sitzfleisch und, am Wichtigsten: Nerven wie Drahtseile.

Was ich allerdings sagen muss: Lazarus und FreePascal sind sehr stabil und sehr brauchbar, das hätte ich so nicht gedacht. In all der Zeit ist mir Lazarus vielleicht vier oder fünf Mal abgestürzt, und es war nicht einmal schlimm, da keine Daten dadurch beeinträchtigt wurden. Sie sollten noch ein wenig an der Stabilität feilen, aber ich könnte mir vorstellen, damit noch einmal zu arbeiten. Vielleicht nicht an einem großen Projekt, aber an kleinen Tools.

Mein YouTube-Kanal

Ich habe es getan, ich habe es wirklich getan. Nachdem manche meinten, ich solle einen YouTube-Kanal aufmachen, und ich immer sagte: „Ich kann sowas nicht, ich kann ja nichtmal vernünftig frei reden.“ und mir gesagt wurde: „Jeder hat mal klein angefangen, da wächst du schon hinein.“ habe ich für mich beschlossen, ich beginne mal einfach und schaue, was daraus wird.

Ich habe bereits ein paar Videos vorproduziert. Natürlich, wie ich auch erwartet habe, sind sie noch schrecklich. Wenn ich aber nicht anfange und einfach mache, dann kann ich natürlich auch nicht besser werden. Also seid ein wenig nachsichtig (:

Ich werde mit drei, vielleicht vier, Sparten beginnen:

  • Softwareentwicklung mit Qt
  • FreeBSD
  • Kurztipps
  • und, vielleicht etwas später, macOS-Administration im Netzwerk mit Deployment und vielem mehr

Hier geht es zu meinem YouTube-Kanal: Thorsten Geppert

wxWidgets auf Windows installieren

wxWidgets … neben Qt mein Lieblingsframework für die Entwicklung in C++. So installiert man es auf Windows:

wxWidgets-Website-Screenshot
wxWidgets-Website
  1. wxWidgets herunterladen: http://wxwidgets.org/downloads -> „Windows ZIP“
  2. Heruntergeladene Datei nach C:\wxWidgets entpacken
  3. tdm-gcc herunterladen: https://jmeubank.github.io/tdm-gcc/download
  4. tdm-gcc installieren (32bit- und 64bit-Variante, vollständige Installation, der Pfad zu den ausführbaren Dateien wird automatisch in die PATH-Variable eingetragen)
  5. CMD öffnen und nach C:\wxWidgets\build\msw wechseln
  6. Kompilieren:
    mingw32-make SHELL=CMD.exe -j4 -f makefile.gcc BUILD=release UNICODE=1 SHARED=0 MONOLITHIC=1

wxWidgets wird jetzt kompiliert und kann danach genutzt werden.

CDs vom Radiologen – Eine grobe Sicherheitsgefährdung?

Ich war beim Röntgen. Von dort bekommt man eine CD mit den Röntgenbildern mit, die man zum Arzt nimmt. Ich habe mir das mal kurz angesehen und war doch sehr erstaunt, dass darauf nicht nur die Röntgenbilder drauf sind.

CD vom Radiologen

Neben den Bildern auf der CD ist ebenfalls noch ein ausführbares Windowsprogramm drauf, welches die Bilder mehr oder weniger benutzerfreundlich anzeigen kann.

Tatsächlich wurde mir ein wenig mulmig, als mein Arzt die CD einfach in seinen Rechner schob, auf dem auch sein Arztinformationssystem lief. Er startete einfach das Programm und sah sich die Bilder an.

Muss das so sein? Wird in irgendeiner Weise abgefangen, wenn darauf irgendwas ist, was nicht sein sollte?

Schnell fallen mir zwei Szenarien ein:

  1. Wenn Viren oder andere Schadprogramme darauf sind
  2. Wenn der Patient, in böser Absicht, den Inhalt der CD ausgetauscht hat

Weiß vielleicht jemand mehr dazu? Letztlich empfinde ich das als extrem hohes Risiko.

Warum ich für neue Projekte eher Qt als wxWidgets nutze

Wir schreiben das Jahr 2005. Mein Arbeitgeber möchte eine neue Software erstellen und wir sind dafür auf der Suche, nach einer nahezu plattformunabhängigen GUI-Bibliothek.

Wir beginnen, mit Qt herumzuspielen und sind begeistert. Bis wir Lizenz und Preise sehen. Schweren Herzenz begaben wir uns auf die weitere Suche und stießen irgendwann, eigentlich recht schnell und ich weiß gar nicht mehr, warum, auf wxWidgets.

Ich spielte einige Stunden, nein Tage und dann auch Wochen, damit herum und war doch sehr angetan, schon alleine, da wxWidgets die GUI-Elemente (in der Regel) nicht selbst zeichnete, so wie es Qt wohl tat (und nicht mehr tut, wenn es nicht sein muss), sondern eine Abstraktion der nativen GUI-Bibliotheken war, die auf den Zielplattformen ohnehin zur Verfügung standen. Auf Windows also MFC, auf Linux/FreeBSD/ähnliche GTK, auf macOS zu der Zeit Carbon, mittlerweile Cocoa, und so weiter und so fort.

Die Programmierung verlangte aber eine höhere Einarbeitung ab, als Qt dies tat und viele Dinge mussten selbst implementiert werden, bsplw. Datenbankabstraktionsschichten mit Persistenzbibliotheken und vieles mehr. All das machte aber Spaß und wenn man es einmal hat – und natürlich auch richtig gemacht hat -, dann kann man es ja wieder verwenden.

So lief es und wir schrieben eine Software nach der anderen. GUI-Software, Systemsoftware, sogar etliche Websites und Backends schrieb ich mit wxWidgets und meinen eigenen Bibliotheken. Ich war schnell, effizient, glücklich.

Doch ich empfand es immer als anstrengend, wxWidgets auf anderen Plattformen als FreeBSD (oder manchmal auch Linux) zu benutzen. Auf FreeBSD reichte sowas wie „c++ *.cpp -o MeinProgramm `wx-config --libs --cppflags`“. Auf anderen Plattformen wie Windows und macOS war es halt kompliziert. Auf Windows mussste (und muss) man noch selbst gegen etliche Bibliotheken linken, auf macOS muss man das Bundling selbst schreiben und Bibliotheken bei der Auslieferung umbiegen. Nervig, ätzend.

Nachdem ich aber für kurze Zeit bei CGM anheuerte und die mit Qt einiges machten, setze ich mich, im Wissen darüber, dass die Lizenz nun liberaler geworden war, noch einmal ausgiebig damit auseinander. Mein Herz ging auf. Ich begann nicht nur, mich mit der Materie mehr zu beschäftigen, ich entwickelte die ersten Projekte darin.

Qt bringt für eltiche Systeme einen Installer mit und Programme und Scripts, die einem das Leben immens vereinfachen.

QtCreator

Es kommt eine komplette IDE, der QtCreator, mit, mit der man seine Programme entwickeln kann. Es wird ein GUI-Designer und vieles mehr mitgeliefert und auch das Deployment auf anderen Plattformen ist integriert und ein Kinderspiel.

Doch das ist nicht alles. Qt ist groß. Es deckt eine Menge ab. Von Netzwerkkommunikation über Datenbankhandling und GUI bis hin zur Entwicklung von Software für Android und iOS. Der (oftmals) selbe Code kompiliert unter allen Plattformen, so dass eine Crossplattformentwicklung relativ einfach (naja, nicht immer) möglich ist.

Aber was sagt die Lizenz? Bei wxWidgets ist es letztlich so: nimm und mach, erwähne uns. Bei Qt muss ich, wenn ich Änderungen am Qt-Code mache, diese auch freigeben. Eigene Software allerdings darf ich ohne Code herausgeben. Klingt das fair? Ja.

Noch eine Sache: Mit QML bringt Qt ein (weiteres) unglaublich mächtiges Werkzeug. Damit lassen sich die grafischen Oberflächen bis ins kleinste designen und anpassen, Abläufe definieren und Layouts für unterschiedliche Dinge entwerfen.

Die große Community hilft bei Problemen und es gibt einige Anwendungssoftware, die mit Qt umgesetzt ist.

Schaut es euch einmal an.