Inhaltsverzeichnis 1 abstract 2 GUI Beschreibung mit XML 2.1 Vorteile 2.2 Probleme 2.3 Alternativen 2.4 Beispiel 3 Event/Aktion Handler mit Ruby Klassen 3.1 Vorteile 3.2 Probleme 3.3 Beispiel 4 Steuerelement Handling via Instanzvariablen 4.1 Vorteil 4.2 Probleme 4.3 Alternativen 4.4 Beispiel 5 Layoutmanager mit YSS 5.1 Vorteil 5.2 Probleme 5.3 Alternativen 5.4 Beispiel 6 Fragen die mich quälen 7 ressources

abstract

BlindOptic ist ein Gedankengerüst für ein Ruby Desktop Application Framework.

GUI Beschreibung mit XML

Vorteile

• Lästiges codegeklammer entfaellt. Evtl. koennen bereits tools wie Glade (wenn XML support vorhanden) genutzt werden um die GUIs zu gestalten. -- Dennis Wilson
• XML kann rein theoretisch (und laut w3c) mit CSS bearbeitet werden. Leider kann REXML das nicht von Haus aus wie es scheint. Wenn man XML und CSS kombinieren kann, haette das z.B. den Vorteil, dass man einen Basis Style definiert in dem grundlegende Layout Definitionen abgelegt sind. Mir fallen da spontan Dinge wie Abstaende zwischen Komponenten, Farben und Schriften ein. Diese Einstellungen wuerden dann lediglich einmal konfiguriert werden muessen, um auf jeder View (die das Basis CSS linkt) angewendet zu werden. -- Dennis Wilson

Probleme

• Beim Einsatz von "XML-Views" ist, dass die Komponenten noch nicht direkt auf der GUI positioniert sind. Moeglich wäre die Fixe positionierung der Komponenten mit XY Koordinaten, absolut zum direkten Parent Elemente (z.B. Button zu Panel zu Window). Das wäre der direkte und etwas unschöne Weg. Interessant wäre in einem späteren Schritt LayoutManager zu implementieren, die sich um die Berechnung der Groessen und Positionen kuemmern. -- Dennis Wilson
• Wird eine View beim deployen, waerend der Laufzeit einmal oder waerend der Laufzeit staendig in in code gewandelt bzw. geparsed?

Alternativen

• Eine auf Rubybasierende Modelierung (ähnlich zu Markaby) - bovi

Beispiel

<window title="diary">
  <listbox id="DateListbox"></listbox>
  <textbox id="EntryTextbox">hier steht später der text</textbox>
  <button id="NewEntryButton">new entry</button>
  <button id="CloseButton" action="exit">close</button>
</window>

Event/Aktion Handler mit Ruby Klassen

Vorteile

• saubere Trennung zwischen View und Logic - bovi
• natürliche Integration in Ruby - bovi

Probleme

• das Mappen auf eine solche Klasse erfordert einige etwas kompliziertere Ruby Hacks (so schwer ist es doch nicht) - bovi

Beispiel

#implement a current window (PROTOTYP)
class Diary < BlindOptic::Window

  #define xml for view
  use_view :diary

  #initialize of window
  def init
    puts ‘init‘#debug
  end

  #date list was clicked
  def DateListbox_Clicked
    puts ‘DateListbox_Clicked‘#debug
  end

  #text in textbox was changed
  def EntryTextbox_KeyPressed
    puts ‘EntryTextbox_KeyPressed‘#debug
  end

  #new entry button clicked
  def NewEntryButton_Clicked
    puts ‘NewEntryButton_Clicked‘#debug
  end

  #close button was clicked
  def CloseButton_Clicked
    puts ‘CloseButton_Clicked‘#debug
  end

end

Steuerelement Handling via Instanzvariablen

Vorteil

• natürliche Integration in Ruby - bovi
• logische Zugriffsmöglichkeit (ein Steuerelement ist ein Teil der Eventhandler-Klasse! Oder?) - bovi

Probleme

• im Moment fällt mir nix ein )-: - bovi

Alternativen

• Methode wie z.B. (getElement(:id => 'EntryTextbox')) gibt eine Referenz auf das Objekt

Beispiel

@EntryTextbox ist ein Steuerelement.

#implement a current window (PROTOTYP)
class Diary < BlindOptic::Window
  
  #define xml for view
  use_view :diary
  
  #new entry button clicked
  def ReadEntryButton_Clicked
    #output text from textbox
    puts "Text: #{@EntryTextbox.text}"
  end
  
  def CleanEntryButton_Clicked
    @EntryTextbox.clean
  end
  
end

Layoutmanager mit YSS

Idee ist die Konfiguration der Optik eines Steuerelementes über eine YAML Datei zu steuern

Vorteil

• YAML ist menschenlesbar und kann sehr leicht bearbeitet werden - bovi
• ist integraler Bestandteil von Ruby - bovi

Probleme

• Gewöhnungsbedürftig ?! - bovi

Alternativen

• CSS Like - bovi
• direkte Positionierung in der XML Deklaration (bovi: schlechte Idee von wegen Layout und Content trennen) - bovi

Beispiel

Elemente mit basic_* prefix sind globale Klassen. Andere Elemente beziehen sich direkt auf ein spezielles Element (Match auf ID Attribut).

#configurate the basic objects
basic_window:
  width: 500
  height: 500

basic_button:
  width: 5
  height: 1

basic_textbox:
  width: 37
  height: 28

basic_listbox:
  width: 20
  height: 27

#now set the coordinates
DateListbox:
  xPosition: 5
  yPosition: 5

EntryTextbox:
  xPosition: 205
  yPosition: 5

NewEntryButton:
  xPosition: 285
  yPosition: 415

CloseButton:
  xPosition: 355
  yPosition: 415

Fragen die mich quälen

bovi: Wie kann man eine GUI vernünftig testen? Es gibt meines Wissens Screenscraper die einen Bildvergleich machen. Aber das ist ja wohl nicht das Wahre. Gibt es schon irgendwelche Erfahrungsträger in diesem Bereich? Das ist unbedingt notwendig, um zu kontrollieren ob ein bestimmtes Element, welches in der XML Datei definiert ist auch vom GUI-Handler erzeugt wurde. Nur so können wir sicherstellen, dass die einzelnen GUI-Bibliotheken korrekt arbeiten.

ressources

Dritter Prototyp mit YSS in der Ruby-Mine

Zweiter Prototyp in der Ruby-Mine

Ein erster Entwurf in der Ruby-Mine

Einführung in der Ruby-Mine