Ich hatte mir heute während der Fahrt von Bremen nach Hannover kurz Gedanken über einen ersten Entwurf von BlindOptic gemacht. Was entstanden ist möchte ich nun kurz zeigen und hoffe auf viel Kritik.
Wenn ich an GUI's denke, schießen mir auf Anhieb zwei Bereiche in den Kopf. Zum einen die Definition der Steuerelemente und zum Zweiten die Verwaltung der Aktionen, welche von diesen ausgeführt werden. Aufgrund dessen habe ich mich mit dieser ersten Spielerei auf diese beiden Bereiche konzentriert.
Das erste was wir hier haben, ist eine kleine XML Datei:
<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>
Nix besonderes, einfach nur ein paar fiktive Elemente die in einer GUI auftreten können. Die Aktionen werden nun in einer kleinen Klasse verwaltet, die ich wie folgt erdacht habe:
#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
Sieht auch nicht großartig komplexer aus. Es wird eine Klasse für ein Fenster definiert. Dabei gibt es eine Art Konstruktor namens init und ein paar Methoden wie z.B. NewEntryButton_Clicked welche jeweils bestimmte Aktionen verwalten. In diesem Fall den Klick auf den Button NewEntryButton. Dieser wird, wie in der XML Datei zusehen ist, über ein id Attribut identifiziert.
Wer das ganze mal mit einer TK Implementation Live sehen will, kann gerne ein wenig mit dem Sourcecode spielen. Aber bitte daran denken, dass die Fahrt von Bremen nach Hannover im Bummelzug nicht mal 1,5 Stunden dauert. Folglich erwartet nicht zuviel (-;
Als erstes hoffe ich mal, dass der eine oder andere von Euch was dazu sagen kann. Ist das ganze zu unlogisch? Habt ihr bessere Ideen? Weiterhin werde ich in den nächsten zwei Schritten versuchen, eine Art Container für die einzelnen Steuerelemente zu bauen, damit man auch ein wenig in der Implementationsklasse Diary mit den Objekten arbeiten kann. Anschließend grübel ich ein wenig über den Style. Im Moment schwebt mir ein CSS ähnliches System vor, um die Positionierungen der Elemente und die Farben anzupassen.
Kommentar schreiben
Kommentare
An und fuer sich keine schlechte Idee. Das Problem, dass ich dabei nun allerdings sehe ist, dass Tina auch erstmal Ruby und Gems installieren muss um sich ueberhaupt gedanken ueber die Installation einer Lib zu machen. Lassen wir dieses Problem erstmal bei Seite. Aus rein programmiertechnischer Sicht ist es natuerlich sehr reizvoll ein einheitliches Interface anzubieten. So ein Projekt ist mit sicherheit nicht easy und schnell abzuhaken wenn es was taugen soll, aber das weisst du sicherlich. :) Zunaechst muesste man alle Gemeinsamkeiten der verschiedenen APIs herausfinden. Zum Beispiel werden alle sowas wie Fenster, Buttons, Checkboxen etc. haben. Mit den Containern für die GUI Objekte, sehe aehnlich wie du. Ich koennte mir gut vorstellen, ein Paket "Funktionsleerer" BlindOptic (BO) Basis-Komponenten zu schreiben. Damit die konkreten Implementierungen (win32,gtk,tk,qt) Paketweise organisiert werden koennen und ein einheitliches Interface haben. Es ist natuerlich zweifelsfrei eine Herausforderung, da die APIs relativ unterschiedlich sein werden. Also nichts was man mal eben ueber einen Blogkommentar planen sollte. Wenn konkretes Interesse besteht, eine solches Projekt zu Gründen lasst es mich wissen. Bis Februar wird es im professionellen Rahmen und Umfang sicherlich nicht so einfach durchzufuehren sein. Aber auf lange sicht gesehen waere so ein Framework sicherlich ein Traum.
Danke für den Kommentar. Im Moment bin ich nur am überlegen, wie man an die Sache am besten rangeht. Die gesamte Logik dahinter sollte sich ohne Probleme austauschen lassen. Aber das Interface für den Entwickler, der eine Applikation erstellt, sollte doch stabil bleiben. Ich denke, aktuell wissen wir einfach noch zu wenig in diesem Bereich. Deshalb will ich, bevor ich großartig irgendwelche Projektseiten auf Rubyforge und Co. erzeuge, erstmal ein Grundkonzept und einen funktionierenden Prototyp der annehmbar ist. Anschließend kann man blind_optic.rb wegwerfen und es nochmal neu schreiben. Um das Problem der unterschiedlichen Widgets der einzelnen Bibliotheken entgegenzutreten, werde ich mich auf die Basisfunktionen einer GUI beschränken. Eine Textbox und einen Button hat jede Bibliothek.Das sind auch Grundkomponenten für jede Applikation. Ein TabControl hingegen ist schon etwas spezieller und wird sicherlich nicht von allen geboten. Hierfür können wir dann die Standardkomponenten nutzen um ein solches Control nachzubauen. Und sollte die eine oder andere Bibliothek ein entsprechendes Control bieten, kann man dann halt direkt die nativ Version nehmen. Wichtig ist halt, das sämtliche Mapper für die Bibliotheken einen einheitlichen Satz von Funktionen bieten. Zum Thema einfache Installation etc. ist hier noch lange nicht das Ende erreicht. Eine Bibliothek in eine exe beispielsweise zu binden ist ein Kinderspiel. Weiterhin könnte man sich vorstellen ein ähnliches Paksystem für Mac OS X und Linux zu erstellen. Wenn wir einen einheitlichen Aufbau unserer Desktop Applikationen haben, lassen sich solche Distributionen sicherlich sehr leicht erstellen.
Wir sollten vieleicht eine Projekt-Seite im Ruby Wiki einrichten, auf der wir Hintergrundwissen und Ideen zusammentragen koennen.
sehr interessant. aber fahren denn alle guis (also die ruby relevanten) mit demselben event modell? also werden überall eventlistener und click events produziert? ich selber kenne das eigentlich nur so, aber ich habe bislang auch hauptsächlich mit swing und windows forms gearbeitet. die frage wäre, benötigt man diese xml datei? oder soll es auch ein kleines scripting tool geben, das dann aus dieser xml datei das gerüst für die gui schaft? ich werde mir mal ein paar gedanken dazu machen. allerdings finde ich die kommentare hier auch nicht ideal dazu.
Okay, also wenn Ihr schon ein wenig mitspielen wollte, dann gerne. Ich hab mal eine kleine Wikiseite angelegt: http://www.rubywiki.de/wiki/BlindOptic Dort könnt Ihr ruhig alles was Euch so im Kopf rumschwirt erstmal festhalten. Das XML File ist derzeitig einfach nur ein Entwurf. Man könnte den gesamten Inhalt auch in einem String vorhalten und dann verarbeiten. Das ganze direkt in Ruby selbst zu schreiben, wäre auch ne Möglichkeit. Ähnlich zu Markaby. Ich persönlich finde XML aber eleganter.
[...] Wie gestern schon angekündigt, (ist|war) mein nächstes Spielziel ein GUI-Element innerhalb meiner kleinen Klasse ansprechbar zu machen. Das alles war in weniger als 15 Minuten erledigt, instance_variable_set sei dank aber dazu später mehr. Als erstes einmal ein kleiner neuer Codeschnippsel: [...]