Wie weiter?

[Ulm32b]

Ich habe jetzt auch den Releasewechsel auf 2.5 vollzogen und kann sehr gut nachvollziehen, dass einige User "etwas verschnupft" reagierten. Das Problem ist zu einem Großteil psychologischer Natur: Man hatte (vielleicht schon vor geraumer Zeit) mit Liebe zum Detail und mancher Stunde des Herumprobierens eine "perfekte" Oberfläche erstellt. Und dann kommt der "kleine/große Bruder" und wirft alle Bauklötze wieder um . . .

Nachdem ich mich aufgerafft hatte, ging es dann vergleichsweise zügig voran. In der Summe erforderte das aber mehr als einen Arbeitstag. Der Großteil dieser Zeit bestand wieder aus Herumprobieren. Die neue Option sheet > row > cell ist sicher ein Fortschritt. Ich glaube aber, dass hier noch ein Schritt nach vorne gemacht werden muss. Soweit ich es verstanden habe, lässt sich Sheet > row > cell nicht verschachteln. Wenn das ginge (d.h. in cell wieder ein neues sheet), wären die meisten Probleme gelöst. Beispielsweise erübrigten sich dann Ideen wie "Verbinden von Zellen". Derart verschachtelte Layouts sind m.E. eher die Regel als die Ausnahme. Bisher ist das ein Gebastel mit containern, vbox, hbox, sheet etc.

Grundsätzlich ist es genau richtig, nach der "wilden" Start-up-Phase jetzt Systematik in die Sache hineinzutragen und die dann auch konsequent durchzuhalten. Derzeit ist es doch so, dass manche Features nur beiläufig erwähnt werden. Beispiel: "half-transparent" als Standard-css. Irgendwo gelesen, gleich ausprobiert, freu. In der Doku Fehlanzeige. Sollte jemand auf die Idee kommen, eine Zeitschrift "FTUI-Bild" auf den Markt zu bringen, könnte er jede Woche mit reißerischen Aufmachern ("Die besten Geheim-Features"; "Pimp your Widget"; ...) werben. Lassen wir es nicht so weit kommen.

Vielleicht fassen setstate & Co dieses Thema auch deshalb mit spitzen Fingern an, weil sie ahnen bzw. wissen, wieviel Arbeit dahintersteckt. Deshalb sollte hier überlegt werden, wie eine Arbeitsteilung organisiert werden kann. Ich sehe keine Alternative, als dass die Knowhowträger die verfügbaren Features der Widgets deklarieren. Die out-of-the-box-lauffähigen Code-Schnipsel könnten dann aus der großen Gemeinde kommen.

Ebenfalls hilfreich wäre eine geschlossene Darstellung, wie man zielgerichtet eine Anordnung vornimmt (mit Vor- und Nachteilen von container, vbox, sheet, ...). Die hier bereits vorgebrachte Idee eines "Drag-and-drop"-Codegenerators halte ich wie setstate nicht für sinnvoll. Der Aufwand wäre sehr hoch und der erzeugte Code oftmals suboptimal bzw. undurchschaubar.

Bevor man hier loslegt, sollte im ersten Schritt diskutiert werden, ob und ggf. wie man das angeht.