GUI-Aspekte
Verfasst: 14.07.2005 10:06:29
Zur Kommunikation liegen bereits diverse Erkenntnisse vor, zur Konfiguration habe ich auch schon mal ein paar Gedanken in den Raum gestellt, und nun habe ich mich ein wenig mit Überlegungen zur Benutzeroberfläche (GUI) beschäftigt.
Ein schon früher von mir geäußertes Kriterium ist Trennung von Form und Funktion. Stellwerkslogik und deren Bedienung bzw. Visualisierung sind zwei verschiedene Dinge, die auch softwareseitig getrennt werden sollen. Ob das im Endeffekt auch zwei Prozesse sein müssen, sei mal dahingestellt, ich gehe im Moment von einem Prozess aus, aber mit klarer Trennung im Inneren, also z.B. durch separate Namensräume in separaten Assemblies/DLLs.
Die Stellwerkslogik fürs mechanische Stellwerk liegt zum wesentlichen Teil als UML-Analyse bereits vor. Das ist reine Logik, keine Anzeige oder Bedienung.
Für eine gründliche Aufbereitung des GUI-Teils bietet sich ebenfalls ein UML-Modell an. Ich habe trotzdem schon mal ein wenig vorweg experimentiert, halt Bottom-Up, um auszuprobieren was geht, ohne Räder neu zu erfinden.
Eine der Entscheidungen beim Design wird sein, wo man aufsetzt, auf der leeren Zeichenfläche, oder vielleicht auf Basis-Steuerelementen. Ich habe Versuche mit letzterem gemacht, Plattform .Net und Windows-Forms.
So lassen sich Weichen/Signalhebel, Fahrstraßenhebel und Blockfelder durchaus als Buttons implementieren, auch wenn sie nicht wie Buttons aussehen. Man bekommt so direkt eine Menge Basis-Funktionalität, z.B. Visual Inheritance, um die neuen Controls mal eben zum Ausprobieren zusammenzuklicken, aber auch Unterstützung beim Layout mit automatischem Docking, wiederverwendbare Properties, aufbereitete Events mit lokalen Maus-Koordinaten usw. Natürlich sind die normalen Button-Zeichenfunktionen eher ungeeignet, aber der Zeichenaufwand für Owner-Drawn-Buttons hält sich in Grenzen. Die diversen Bitmaps dazu lassen sich in Resource-Files speichern, die Sounds leider nicht.
Für den Ton bietet sich die Audiowiedergabe aus Managed DirectX an, so wie sie auch Jens Haupert bei seinen Applikationen verwendet (das ist nicht Direct-Sound, sondern schlichtes Abspielen einer Audiodatei, wie wir es auch aus Win32 kennen.)
Die Attribute dieser neuen Controls werden im Wesentlichen über Properties gesetzt, auch der Anfangszustand, ggf bietet sich noch die eine oder andere explizite Funktion an, z.B. externes Entsperren eines Blockfeldes, wo es ja klappert oder rasselt. Auch die Bedienbarkeit, blockiert oder nicht, wird über Properties gesetzt, ähnlich dem klassischen Enable. Vom Bediener ausgelöste Zustandsänderungen werden über Events rückgemeldet.
Wie koppelt man nun die Bedienung mit der Logik?. Mir schweben im Moment Brückenobjekte auf GUI-Seite vor, die die Stellwerkslogik als abstrakte Interface-Klassen kennen, und die Bedienelemente als konkrete Member (Attribute/Felder) enthalten. Diese Brückenobjekte kennen auch die Konfiguration, d.h. sie sind über IDs eindeutig ansprechbar. Ein solcher Weg über Brückenobjekte scheint mir ein geeigneter Kompromiss aus Vererbung und Delegation zu sein.
Ein schon früher von mir geäußertes Kriterium ist Trennung von Form und Funktion. Stellwerkslogik und deren Bedienung bzw. Visualisierung sind zwei verschiedene Dinge, die auch softwareseitig getrennt werden sollen. Ob das im Endeffekt auch zwei Prozesse sein müssen, sei mal dahingestellt, ich gehe im Moment von einem Prozess aus, aber mit klarer Trennung im Inneren, also z.B. durch separate Namensräume in separaten Assemblies/DLLs.
Die Stellwerkslogik fürs mechanische Stellwerk liegt zum wesentlichen Teil als UML-Analyse bereits vor. Das ist reine Logik, keine Anzeige oder Bedienung.
Für eine gründliche Aufbereitung des GUI-Teils bietet sich ebenfalls ein UML-Modell an. Ich habe trotzdem schon mal ein wenig vorweg experimentiert, halt Bottom-Up, um auszuprobieren was geht, ohne Räder neu zu erfinden.
Eine der Entscheidungen beim Design wird sein, wo man aufsetzt, auf der leeren Zeichenfläche, oder vielleicht auf Basis-Steuerelementen. Ich habe Versuche mit letzterem gemacht, Plattform .Net und Windows-Forms.
So lassen sich Weichen/Signalhebel, Fahrstraßenhebel und Blockfelder durchaus als Buttons implementieren, auch wenn sie nicht wie Buttons aussehen. Man bekommt so direkt eine Menge Basis-Funktionalität, z.B. Visual Inheritance, um die neuen Controls mal eben zum Ausprobieren zusammenzuklicken, aber auch Unterstützung beim Layout mit automatischem Docking, wiederverwendbare Properties, aufbereitete Events mit lokalen Maus-Koordinaten usw. Natürlich sind die normalen Button-Zeichenfunktionen eher ungeeignet, aber der Zeichenaufwand für Owner-Drawn-Buttons hält sich in Grenzen. Die diversen Bitmaps dazu lassen sich in Resource-Files speichern, die Sounds leider nicht.
Für den Ton bietet sich die Audiowiedergabe aus Managed DirectX an, so wie sie auch Jens Haupert bei seinen Applikationen verwendet (das ist nicht Direct-Sound, sondern schlichtes Abspielen einer Audiodatei, wie wir es auch aus Win32 kennen.)
Die Attribute dieser neuen Controls werden im Wesentlichen über Properties gesetzt, auch der Anfangszustand, ggf bietet sich noch die eine oder andere explizite Funktion an, z.B. externes Entsperren eines Blockfeldes, wo es ja klappert oder rasselt. Auch die Bedienbarkeit, blockiert oder nicht, wird über Properties gesetzt, ähnlich dem klassischen Enable. Vom Bediener ausgelöste Zustandsänderungen werden über Events rückgemeldet.
Wie koppelt man nun die Bedienung mit der Logik?. Mir schweben im Moment Brückenobjekte auf GUI-Seite vor, die die Stellwerkslogik als abstrakte Interface-Klassen kennen, und die Bedienelemente als konkrete Member (Attribute/Felder) enthalten. Diese Brückenobjekte kennen auch die Konfiguration, d.h. sie sind über IDs eindeutig ansprechbar. Ein solcher Weg über Brückenobjekte scheint mir ein geeigneter Kompromiss aus Vererbung und Delegation zu sein.
![:]](./images/smilies/pleased.gif "Freude"){kind=small}
