Studie: Rexx auf Qt portieren

[LotharS]

Nach einigen Anläufen konnte ich mein Projekt der Art Rexx->Qt auf endlich einen ersten Meilenstein bringen: lziqt40, "liesmich.txt" eingeschlossen.
Resultat ist zwar exemplarisch und höchstens "alpha", aber funktioniert...

(1) Die Idee: Meine kleine Anwendung LSZipWizard - trotz .exe ja doch ein Script - auf irgendwas Compilierbares zu bringen. Erste Schritte auf Basis VACPP3.08 schafften sogar ein funktionierendes Bildchen. Immerhin: Ein Warp4-Notebook und DnD-Events klappten; das Kernproblem: Umleitung von StdOut/StdErr nach Cmd-Aufruf - in Rexx ein Einzeiler! - habe ich dank Lars' Beispiel zu DosExecPgm() hinbekommen. Aber ohne echte IDE (etwa wie eclipse) und Debugger weiter für mich hoffnungslos. VACPP4.x sah mir noch schlimmer aus.

(2) Da wurde Qt interessant: Eine IDE Qt-Creator inkl. QtDesigner, ordentlichem Editor und -eigentlich- eingebautem Debugger. Allerdings: in ArcaOS nur auf altem Qt4 und ohne Debugger, einen "versprochenen" Qt5-Creator gibt's bis heute noch nicht. Aber mein Linux hatte alles!

(3) Statt DosExecPgm() fand ich im Netz einen entsprechenden Code mit QProcess::start(), was mein o.a. Kernproblem löste. Endlos weitere dringende Fragen fand ich irgendwie im Netz und der Qt-Doku gut erklärt, zwar alles für "Linux" aber ok...

(4) Habe deshalb begonnen, meinen Rexx-Code schritt---weise möglichst "1:1" auf Linux-Qt zu portieren (andernorts bekäme man dafür einen jecken Verdienstorden ). Natürlich jede Zeile angefasst, aber zum Glück war mein Rexx-Code bereits stark modularisiert und zeigte sich das Event-Handling in meinem VisproRexx ziemlich ähnlich dem in Qt (oder manchmal doch notify vs. VACPP-connect()). Das Rück-Portieren auf ArcaOS-Qt4 war mit Hilfe von #define-Makros (und reichlich Debug...) zu >90% sehr einfach, allerdings vereinzelt nur mit Hilfe Standard-C++ und Toolkit-API (und immer wieder Danke an Lars! ). Und profitiert hat zwischendurch rückwärts mein Rexx . Endresultat sh. oben, leistet fast das Gleiche wie's Rexx-Original.

An eine breite Veröffentlichung dieser Studie denke ich nicht, das Rexx-Original tut halt echteres "OS/2" und für eine weitere HLP-Doku und Pflege hab' ich keine Lust... Bin aber auf Wunsch gern bereit, über Source-Code (oder Teile daraus) zu reden, hab' ja dauernd selbst profitiert...

Vor allem bitte seid jetzt Ihr dran, ähnliche Projekte zu starten.

P.S.: Konnte die Zeit gut nutzen, ohne von Migration auf ArcaOS5.1.null gestört zu werden. Beide Announcements kreuzen sich gerade

[LotharS]

Nach einigen Anläufen konnte ich mein Projekt der Art Rexx->Qt auf endlich einen ersten Meilenstein bringen: lziqt40, "liesmich.txt" eingeschlossen.
Resultat ist zwar exemplarisch und höchstens "alpha", aber funktioniert...

Ein Update dieser Qt-Studie ist nun unter lzipqt40_002 zu finden, und zwar nur dort. Sie enthält kleine Anpassungen in Anlehnung aus LSZipWizard v.1.41 von Ende 2024. Dem wesentlich besseren Qt-Support unter Linux sei weiterhin Dank...

[Andi B.]

Ich nehme mir schon lange vor was mit QT zu machen. Darum verfolge ich auch deine Bemühungen. Ob QT4 oder 5 wäre mir da vorerst egal. Aber wie du auch schreibst, unter Linux geht vieles dann doch um eine Ecke einfacher. Und schön langsam frage ich mich, warum ich mir das dauernde gebastel antue, bis ich ArcaOS so halbwegs auf einem neuen Rechner am laufen habe. Unter Linux läuft es einfach. Auch mit richtiger Monitorauflösung, selbst wenn der beim Booten nicht schon dransteckt. Und USB zickt auch nicht dauernd rum.

und -eigentlich- eingebautem Debugger

Also der geht nicht? Hast du den idebug mit QT probiert? Wenn du es schaffst die exe mit den richtigen debug Symbolen zu generieren, könnte es ja gehen. Wie bei anderen GCC sourcen auch. Oder ist das wieder was ganz anderes? Ich nehme üblicherweise für VAC oder GCC Projekte den idebug vom VAC3.65 (oder den vom 4.0?).

[LotharS]

und -eigentlich- eingebautem Debugger

Also der geht nicht? Hast du den idebug mit QT probiert? Wenn du es schaffst die exe mit den richtigen debug Symbolen zu generieren, könnte es ja gehen. Wie bei anderen GCC sourcen auch. Oder ist das wieder was ganz anderes? Ich nehme üblicherweise für VAC oder GCC Projekte den idebug vom VAC3.65 (oder den vom 4.0?).

Wie erwähnt, hatte ich zuvor mit VAC experimentiert, inklusive Debugging. Aber dessen "Project View"(?) war ja nun doch eine "IDE" aus dem vorigen Jahrhundert..., alles inzwischen entfernt. Den Umweg über Linux-Qt-Creator fand ich nicht nur optisch besser handzuhaben, sondern durfte reichlich aber vernünftig debuggen... Zudem habe ich den Code mit zahlreichen "qDebug()"-Statements bespickt, die auch im Qt4-Creator von ArcaOS nützlich sind (und bei exe-Ausführung unsichtbar). - Der alte Qt4-Creator zeigt zwar äußerlich einen Punkt "Debuggen", aber die "innen" mitgelieferten Make-Parameter sehen ein Debuggen offenbar nicht vor.

In Köln hatte ich 2021/22 ein wenig über die Idee erzählt, wobei es mit Mini-Beispielen mehr ums Thema Architektur ging: modulare Trennung Inhalt/Darstellung, bequemes Event-Handling. Für die tausenden Details gibt's ja Bücher, Dokus und Experten-Hilfen im Netz.

[LotharS]

Ein Update dieser Qt-Studie ist nun unter lzipqt40_002 zu finden, und zwar nur dort. Sie enthält kleine Anpassungen in Anlehnung aus LSZipWizard v.1.41 von Ende 2024. Dem wesentlich besseren Qt-Support unter Linux sei weiterhin Dank...

Nun hatte ich doch einen sichtbaren "Bug" erwischt zu einigen meiner farbigen Buchstaben ... harmlos "Darstellung" jedoch tut . Im Sommerloch mal Gelegenheit zu ein paar Code-Vereinfachungen und Vorziehen einiger formaler Eingabe-Prüfungen; Ergebnis LZipQt40_003 (als "Studie" nur hier), mit unveränderter Funktionalität. Soll damit eigentlich wieder eingefroren sein ... Fürs REXX-"Original" habe ich mal Notizen für _irgendwann vorgemerkt...

Ich nehme mir schon lange vor was mit QT zu machen. Darum verfolge ich auch deine Bemühungen. Ob QT4 oder 5 wäre mir da vorerst egal. Aber wie du auch schreibst, unter Linux geht vieles dann doch um eine Ecke einfacher...

Das ganze Projekt wie bisher: Führend gepflegt und getestet in meiner Linux-VM mit der dort verfügbaren vernünftigen Umgebung. Für die OS/2-Spezifika habe ich Macros definiert so dass ich den (reinen) Code einfach per Samba von dort in meine ArcaOS-VM mit Qt4-Creator transportieren kann, notfalls nur wenig nachfeilen und Rückmeldung... Am Aufruf von Toolkit-APIs <os2.h> u.dgl. brauchte ich nicht zum Glück nicht mehr zu wackeln...

Zum Einstieg in Qt hatte ich mir neugierig den Qt-Designer angeschaut, aber wie mit 'OK'-Buttons usw. umgehen?? Deshalb habe ich mir ein Buch "Einführung in Qt" gekauft (und zu C++ gleich mit...) und verstand langsam was in Qt anders und einfacher läuft als in VAC++ (oder gelegentlich ähnlich). Mit hinterher einem Code den man in der IDE wenigstens bequem lesen und pflegen kann..(nagut ). Dazu gibt's (mindestens eine) umfangreiche Bibliothek voller Klassen und Methoden, im Netz bestens dokumentiert mit Anleitungen, Qt6 - Qt5 - zu Qt4 etwa hier: https://doc.qt.io/archives/qt-4.8/classes.html. - Etwas Neues an dieser Stelle werde ich definitiv nicht mehr anfangen.