Motif Explorer

« | 17 Nov 2024 | »

Mit der Ausimplementierung von Treeview und Listview Controls mit dem antiken Motif Framework, kann ich jetzt auch meinen File-Browser im Unix-1990 Look-and-Feel schimmern lassen.

---

Für “einfache” Controls wie Buttons oder Textfelder gibt es im motif Toolkit recht selbst-erklärende WidgetClass Instanzen wie xmPushButtonWidgetClass oder xmTextWidgetClass.

Treeviews und Listviews, wie sie in Win32 seit über 30 Jahren heißen sind aber in der motif Welt zusammengesetzte Widgets und benötigen mehr Aufmerksamkeit um Ihre Entsprechungen zu finden und zusammenzunähen.

Treeviews

xmOutlineWidgetClass bzw. die Funktion XmCreateOutline() stellen uns einen Widget-Container bereit, der seine Kind-Elemente hierarchisch ordnen, sowie dynamisch ein- oder ausblenden kann.

Funfact: Visual Basic 4 hatte damals auch ein selbst-fabriziertes “Outline Control”, bevor mit Win95/NT3.5 das Win32 Treeview Control auf den 32-bit Plattformen eingeführt wurde.

Mit dem Resource-Argument XmNconnectNodes werden Hierarchielinien zu den Kindelement gezeichnet und XmNindentSpace gibt an, um wieviele Pixel ein Kindelement eingerückt werden soll.

Will man jetzt ein Element einfügen, kann man einen beliebigen Widget erzeugen und diesem die Resource XmNparentNode mit einem Pointer zum Eltern-Widget mitgeben, oder eben NULL für ein Top-Level Element.
Die State-Resource XmNnodeState gibt an, ob die Kinder ausgeklappt sind (XmOpen) oder nicht (XmClosed).

Ich füge hier Push-Button-Widgets ohne sichtbaren Rahmen ein, die einen Click Callback bei mir aufrufen, womit ich den Ein/Ausklapp-Status wechseln kann. Der Text des Elements lässt sich wie üblich per XmNlabelString bearbeiten.

Und schon ist die Treeview-Alternative fertig.

Listview

Listviews (damit meine ich immer die “Detail” Ansicht) sind quasi Tabellen, also Datensatzlisten mit Zeilen und Spalten.

Nach langem erfolglosem Herumexperimentieren konnte ich von einer uralten motif-Demoanwendung lernen, dass sich das am Besten mit der xmContainerWidgetClass umsetzen lässt.
Dem kann man nämlich über XmNlayoutType die Eigenschaft XmDETAIL zuweisen und dann per XmNdetailColumnHeadingCount und XmNdetailColumnHeading die Column-Header definieren und benennen lassen.

Anschließend fügt man pro Zeile eine xmIconGadgetClass Instanz über XmCreateIconGadget() hinzu, bei der Eigenschaften wie XmNlabelString den Text der ersten Spalte definieren, und die restlichen per XmNdetail und XmNdetailCount als String-Array angefügt werden.
(Das ist ja in Win32 ganz ähnlich gelöst.)

Sogar Icons lassen sich mit XmNsmallIconPixmap und XmNsmallIconMask der Datenzeile voranstellen.

Fazit

In Summe ist das Zusammensetzen von Treeviews und Listviews gar nicht so unterschiedlich zu den Win32 Controls.
Das größte Problem liegt in der fehlenden Dokumentation, bzw. den fehlenden (oder schwer findbaren) Beispielen.

Man findet tausende Codezeilen im Netz, wenn man eine Explorer-Ansicht unter Windows selbst mit Win32 Controls ausprogrammieren kann.

Bei motif sehen wir nur lange Listen von Resource-Eigenschaften, aber wie diese zusammenarbeiten und wie man bestimmte Ergebnisse damit produzieren kann bleibt ein Geheimnis.

Funfact: KI ist dumm!

Da über motif wenig Code im Umlauf ist, sind die selbstherrlichen Large-Language-Models nicht in der Lage auch nur irgend etwas sinnvolles darüber hauszufinden.

Doch KIs kennen die Antwort: “Ich habe keine Ahnung!” eben nicht, und erfinden APIs, die nicht existieren und teilen selbstsicher mit, dass sie die Lösung gefunden hätten.

Es kostete mich viel Recherche-Zeit um festzustellen, dass jede zweite Funktion im generierten Code reine Phantasie war.

Merksatz:
Vertraue keiner KI,
denn wenn sie was nicht weiß, dann lügt sie.