[BlindOptic] YSS positioniert
In einer freien Minute habe ich nun BlindOptic um ein Layoutmanager bereichert. Das Ganze hab ich unter den wohlklingenden Namen YAML Stylesheets gestellt.
Positionierung muss sein
Wer sich die letzten beiden Sourcen mal angeschaut hat, war sicherlich von der Optik nicht allzu begeistert. Bisher habe ich in der TCL/TK Implementierung den Layoutmanager pack alles machen lassen. Dieser positioniert die Steuerelemente flexibel auf dem Fenster. Da wir aber die Elemente selbst exakt auf der Oberfläche positionieren wollen, brauchen wir eine Möglichkeit BlindOptic zu sagen, wo und wie er was positionieren soll. Das Zauberwort hierfür heißt derzeitig YSS (YAML Stylesheets). Was kann man sich darunter vorstellen? Nun schaut erstmal selber:
#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
Ich habe ganz einfach, die Layoutstruktur in YAML nachgebildet und verwende diese nun in BlindOptic. Derzeitig ist das die einfachste Möglichkeit die mir eingefallen ist, wenn jemand ne bessere Idee hat nur her damit. Ansonsten sieht meine tolle kleine Testapplikation so aus:
Schön ist was anderes doch es wird, langsam aber sicher.
Kommentar schreiben
Kommentare
Ich bitte um Entschuldigung - schon mal im Vorraus - für Folgendes: Bei pixelgenauen Werten überkommt mich ein gewisser Brechreiz. Ich weiß, CSS ist 'ne ganz tolle Sache und man kann endlich wie im Adobe Illustrator seine Elemente anordnen. Und überall sieht das dann gleich aus. Überall? Nein, ein kleines gallisches Dorf ... Naja, ihr kennt die Story. Bis jetzt läuft so ein Pixel-Hacking immer dann sauber durch, wenn die Benutzer nicht spezielle Einstellungen tätigen. Aber kaum hat jemand mal die Systemschrift ein bisschen größer, fällt er auf die Nase. Was soll das auch, dass er sich erlaubt, so dermaßen individull (man könnt ja schon fast wieder avantgardistisch sagen) zu sein? Der spinnt wohl, hat ja 'n Schaden. Eben. Genau das ist das Problem. Wenn klein azuby auf Websites geht oder so überaus geil gestylte Anwendungen ausführt, dann ist die schöne Pixel-Hackerei nämlich fürn Arsch. Weil klein azuby nämlich 'n Schaden hat und daher die Schrift größer braucht. Mal ein paar Effekte, die dann auftreten: - Elemtentgrenzen zu klein, Inhalt fällt raus oder wird abgeschnitten 1. Elementgrößen zu klein, Inhalt läuft drüber hinaus 2. Inhalte laufen ineinander 3. z. B. bei Links verrutscht sogar die anklickbare Fläche. Man fährt mit der Maus über einen Link und klickt und nix passiert. (kann man bei wetter.com beobachten) 4. Inhalte sind ganz wo anders, als sie eigentlich sein sollen, z. B. unter anderen und damit gar nicht mehr sichtbar 5. ... Die Moral von der Geschichte? azuby nutzt immer wenn es geht relative Werte und Größenverhältnisse, niemals pixelgenaue Angaben. Ich wollte euch damit nur auf EIN Problem bezüglich Usability und Accessibility aufmerksam machen, nicht die Idee kaputt reden. azuby
Danke schonmal für den Einwurf. Ich bin jetzt bei Linux GUI Apps nicht so fit. Aber im Windowsbereich ist es eigentlich gang und gebe Steuerelement Pixelgenau zu positionieren. Bei einem Resize der Oberfläche justiert man die dann erneut. Bei Webapplikationen ist es sicherlich sinnvoll sämtliche Elemente flexibel zu gestalten. Aber eine richtige GUI ist doch meißt um einiges komplexer. Und wenn ich mir so die Word Property Dialoge anschaue, sehe ich dort nix von wegen anpassbar etc. Und leider ist das wohl das mass der Dinge )-: Aber ist ein interessanter Punkt. Mal schauen wie man das ganze flexibler gestalten könnte.
Zumindest lässt sich unter Windows die Schriftgröße global verändern, wodurch sich mit großer Wahrscheinlichkeit solche Fehldarstellungen produzieren ließen (mir fallen z.B. Menüs oder Icon-Beschriftungen ein).
Du könntest doch versuchen beides zu verschmelzen? Also in der Art wie HTML das macht. Dass man das Layout so beibelässt aber dann eben sagt, hier ist ein Kontainer, da ist dies und jenes drin. Und dann per YSS nur noch sagt: Kontainer.textfeld: width: 75%
Disclaimer: Dieser Beitrag wurde von einem Laien verfasst: Außer ein paar Spielereien hatte ich bisher noch nichts mit GUI-Programmierung zu tun. Mein Wissen über GUIs ist also eher Halbwissen. 1. Du schreibst "Bisher habe ich in der TCL/TK Implementierung den Layoutmanager pack alles machen lassen.". Ich glaube das "TCL" muss da raus. 2. Wie viele (Toolkit-)Bindings gedenkst du bzw. gedenkt ihr zu unterstützen? Wichtig wären IMO Qt, Gtk, Windows sowie Cocoa, wobei man die letzten drei soweit ich das verstanden habe auch über wxWidgets (wxRuby) realisieren könnte (Bei wxRuby könnte ein Problem sein, dass dieses noch nicht sehr verbreitet ist. Hier unter Ubuntu Edgy kann man es nicht über die offiziellen Repos installieren). Eine weitere Frage ist, ob man neben Qt auch die KDE-Bindings (Korundum) unterstützen sollte (gibt es so etwas auch für gnome oder xfce?). 3. Wollt ihr die BlindOptic so entwerfen, dass das Handling auf jeder Plattform/jedem DE gleich ist, oder soll es so gelöst sein, dass sich die Anwendung immer optimal in das aktuelle DE einpasst? Beispiel: Wir nehmen an, dass sowohl Qt als auch Cocoa ein Tab-Management anbieten, welche sich jedoch in manchen Usability-Fragen unterscheiden. Wird man nun das Tab-Management von Qt übernehmen und in Cocoa eines "nachbauen", das sich genauso verhält (oder andersherum), oder wird man beide "übernehmen"? Das führt mich zu meinem nächsten Punkt: 4. Soll auch Tk als Toolkit unterstützt werden? Im Vergleich zu den anderen Toolkits wirkt es auf mich doch etwas "primitiv", es könnte also durchaus aufwendig werden, die Fähigkeiten die andere Toolkits out-of-the-box haben, in Tk nachzubauen. Falls nein, wäre es dann nicht sinnvoller schon für die Prototypen ein anderes Toolkit zu verwenden? Hier würden sich denke ich Gtk oder wxWidgets anbieten, die auf den drei wichtigsten Plattformen laufen. 5. Zum Thema absolute Anordnung: Haben die "höheren" Toolkits denn keine Unterstützung für relative Größen? (Kann man die Breite usw. nicht in Prozent bzw. einem Pendant zu em im Web angeben?) 6. Zum Thema YSS: Wird es Support für Klassen geben? Werde ich also alle Elemente mit class="foobar" über class_foobar o. ä. im YSS "stylen" können? Puh! Ganz schön viel Text für so eine kleine Textbox :) Ich hoffe ich hab' nicht allzuviele Fehler in den Kommentar fabriziert.
Noch eine Frage, die sich mir stellt: Wie werden GUI-Elemente zur Laufzeit eingefügt? Als Beispiel: Die Items in DateListbox sollen aus einer YAML-Datei ausgelesen werden. Soll es einen Ansatz ähnlich zu dem von Rails geben, also dass auch ins View-XML Ruby-Code eingebaut werden kann, oder wird das nur über diary.rb laufen (also in etwa DateListbox.insertItem(:id => foo, :text => bar))?