Erfahrungen mit dem Interfacebuilder ixbuild bei der Konstruktion von Motif Oberflächen für Supercomputer Anwendungen

Transkript

1 Erfahrungen mit dem Interfacebuilder ixbuild bei der Konstruktion von Motif Oberflächen für Supercomputer Anwendungen Seite 1

2 Problem Einerseits Komfort durch Verwendung von Workstations oder X Terminals mit grafischen Schnittstellen, aber bedienerunfreund liche Schnittstelle für den Supercomputerzugang mit exotischer Kommandosprache, so z.b. die MVS oder VSP/I Steuersprache Verstärkung der Problematik bei einer Frontend Backend Kopplung (gar nicht so selten!). Was fehlt: Intuitive und objektorientierte Oberflächen zur benutzer freundlichen Bedienung des Supercomputers Erste Ansätze: Die Kommandosprache ISPF unter MVS oder SDF im BS2000, aber: unitelligente Terminals wie 3270 oder 9750 machen den Gewinn teilweise wieder zunichte. Seite 2

3 Z.B.: Löschen einer Datei auf dem Supercomputer VP100 Mit Originalsteuersprache (MVS bzw. VSP/I) Mit USER2000, einem BS2000 Zugang mit SDF Interface Mit dem grafischen VP100 Interface xvp Seite 3

4 VSP/I Seite 4

5 SDF/BS2000 Seite 5

6 XVP Seite 6

7 Entwicklung der grafischen Interface mit X Window als Fenstersystem und OSF/Motif als Toolkit Schnittstelle Verlust an Performance, da proprietäre Fenstersysteme schneller sind Aber: Gewinn durch Portabilität und Client Server Architektur (d.h. variable Netzeinbindung) Seite 7

8 Entwicklung von X Window Programmen nicht trivial wegen: Diverser X, Xt und Xm Bibliotheken und Includes Intensives Auseinandersetzen mit Begriffen wie Xt Intrinsics Motif Widget Sets Klassen Hierarchie,... Von Hand aufwendiges Einpassen der unterschiedlichen Fenster und Schrifttypen, Füll und Randmuster, Pulldown und Popupmenüs,... Umständliches Austesten des Look and Feel Seite 8

9 Reduktion der formalen Probleme durch Interfacebuilder: WYSIWYG Editor zum definieren des statischen Fensteraufbaus und der Callbacks Testmodus, ggfls. Mit Callback Anschluss und Emunlation Objekt Bibliotheken UIL Interface Erzeugung von portablem C Code, manchmal auch von UIL Gegebenenfalls (bei manchen Interfacebuildern): Reduktion des erzeugten Codes durch Laufzeitsysteme, damit aber plattformgebundene, nicht portable Anwendungen Die meisten Interfacebuilder sind X Window und Motif basiert und damit in Client Server Architekturen enbindbar. Seite 9

10 System bzw. Hardware Plattformen HP SUN AIX SGI SCO... Seite 10

11 Xvp Generierung mit ixbuild Seite 11

12 Systemumgebung Am Regionalen Hochschulrechenzentrum Kaiserslautern Workstations der Typen HP Apollo Silicon Graphics Sun/SPARC AIX Heterogenes Spektrum wegen Unterschiedlicher X11 Releases (R3 oder R4) Unterschiedlicher OSF/Motif Releases (1.0 oder 1.1) Unterschiedlicher UNIX Varianten (SV.3/BSD 4.3) Seite 12

13 ... Systemumgebung Ixbuild läuft aus SUN mit OS 4.1.1, vernetzt mit den übrigen Maschinen über TCP/IP (NFS,telnet, ftp, X Window) Lagerung des erzeugten Layout Codes nur auf einer Maschine Anwenderteil (Rahmen und Callback Code) auf nur einer Maschine; möglich durch Verwendung portabler Systemschnittstellen Schnittstellengenerierung läuft je Machinentyp (Apollo, SUN und SGI) auf jeweils einer Referenzmaschine Seite 13

14 Streng portabler Code Seite 14

15 Entwicklungskonfiguration Xvp Makefile Ixbuild Daten Layout Code Xvp Sourcecode Xvp Makefile SUN-IPC APOLLO Ixbuild Software Xvp Makefile SGIINDIGO LAN LAN LAN Seite 15

16 Ixbuild Datenverwaltung: Zugriff auf (momentan 36) verschiedene Supercomputerfunktionen heißt entsprechende Aufteilung der ixbuild Steuerdaten, denn: Ablage in einer Datei wegen Größe und Übersichtlichkeit nicht empfehlenswert Im WYSIWYG Editor nicht alle Fenster auf einmal darstellbar Zur Ablaufzeit würden alle Fenster auf einmal erstellt: teils Performance Verlust, teils funktional unerwünscht Umsetzung der xvp Funktionalität in Menüs, Pulldowns, Toggle und Push Buttons mittels ixbuild ohne Probleme zu bewerkstelligen, aber Dynamisches Austesten der Schnittstellen mit ixbuild nicht möglich Seite 16

17 Modifizierung des Layout Codes, denn der Layout Code ist nicht automatisch für die Makeläufe verwendbar, denn: Einhängen eines Fensters in die Funktionshierarchie geht an ixbuild vorbei, da ixbuild im Prinzip von einem kompletten Hauptprogramm ausgeht Layout Code nicht ohne weiteres als Unterprogramm verwendbar (zu viele oder fehlende Include Header) Bezüge auf eigene und X11 spezifische Bitmap Files u.u. nicht brauchbar, wenn die Lage zur Laufzeit von xvp anders ist als zur Zeit der Code Generierung Manchmal nicht alle gewünschten Widget Resourcen im Resourcen Editor verfügbar Seite 17

18 Problematische Codestellen /***************************************************** * IXBUILD v2.0 Generated Code File * Interface Code for xvp_info ******************************************************/ #include "xvp_info.layout.h" #define MAX_ARGS 100 /*** Insert your code after this line ***/... {... n = 0; XtSetArg(args[n],XmNlabelPixmap,BitmapFileToPixmap(Lable_logo, "/usr/export/home/ipc01/backes/logo.bmp","black","white")); n++;... } problematischer main Bezug Dieser Pfadname könnte sich ändern Seite 18

19 Codeänderungen automatisiert über awk Skripte durchgeführt: Aufteilung in verschiedene Include Files mit Anpassung an Ablaufumgebung Verfahren nicht unproblematisch, da empfindlich gegen ixbuild Versionsänderungen: Exaktes Format des Layout Codes ist weder dokumentiert noch festgeschrieben, aber Verfahren praktikabel (keine größeren Anpassungsschwierigkeiten für die awk Skripte beim Übergang von ixbuild V1 auf ixbuild V2) Seite 19

20 Erfahrungen beim ixbuild Einsatz: Resümee Seite 20

21 Unproblematische Installation, aber Anpassung der ixbuild Resourcenfiles an die spezielle Umgebung erforderlich wegen folgender Fragen: Soll man Widget Klassen als Childs anderer Klassen zulassen? Sollen im WYSIWYG Editor bei gewissen Widget Klassen Geometrie Änderungen erlaubt sein? Welche Widget Resourcen Änderungen soll der Resourcen Editor erlauben? Seite 21

22 Layout der ixbuild Resourcen ist ausführlich beschrieben, allerdings sind Änderungen bei Versionsübergängen nicht ausgeschlossen Änderungen teilweise nur so durchführbar, da nicht jede Anpassung über ixbuild Menüs erreichbar Der WYSIWYG Editor ist funktional voll ausreichend, weitere Verbesserungen seit ixbuild V2 durch Mehrfachselektion, und, sehr hilfreich, das Arbeiten mit dem symbolischen Widget Tree Seite 22

23 Offene Probleme und Fragen (eine Auswahl) Umbau einer Widget Hierarchie (kommt öfters vor) wegen unzureichender COPY Funktionen nur umständlich durchzuführen, aber Verbesserungen ab der nächsten ixbuild Version sind zugesagt Unbefriedigendes Arbeiten mit den Font Resourcen, aber Verbesserungen ab der nächsten ixbuild Version sind ebenfalls zugesagt Allgemein: Lt. Fa. Ixos sind die meisten Probleme ab V 2.1 ausgeräumt. Seite 23

24 Gesamteindruck: Zahlreiche fruchtbare Diskussionen mit einem sehr kooperativen Entwickler Individuelle und intensive Produktbetreuung Seite 24

25 NBS Ein weiteres Projekt mit ixbuild Seite 25

26 NBS (Network Backup System) Backup und Restore für UNIX Betriebssysteme (z.b. Workstations, mit Ablage der Dateien auf einem Mainframe (z.b. ein MVS System). Kopplung native über TCP/IP Protokoll (kein NFS!). Seite 26

27 Seite 27

28 Seite 28

29 Seite 29