OS2.org Forum

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 hat geschrieben: So 27. Aug 2023, 12:04 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...

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

Andi B. hat geschrieben: Do 31. Jul 2025, 15:46

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.