Hallo,
benneque schrieb:
@andy_m4: Der C(++)/ASM Part für GUI Entwicklung war nicht so ganz ernst gemeint
Ok. Lass ich man grade so gelten. :-)
benneque schrieb:
Bzgl. XML für die GUI, gibt es noch ein viel älteres Beispiel als XUL: HTML!
Das sehe ich anders. HTML ist bzw. war ja überhaupt nicht für die GUI-Gestaltung gedacht. HTML ist ja in erster Linie eine Auszeichnungssprache auf sematischer Ebene.
<h1> heißt ja beispielsweise nicht, dass der Text darin besonders groß dargestellt werden soll. Sondern ist eine Überschrift erster Ebene. Oder auch <strong> bedeutet ja nicht Text fettdrucken. Sondern betonen.
Wie das dann vom Browser umgesetzt wird, ist dann den seine Entscheidung. Ich weiß noch bei den ganz alten Netscape-Versionen konnte man das teilweise sogar einstellen, so dass der Nutzer dafür sorgen kann das die HTML-Seiten so angezeigt werden, wie er es für richtig oder angenehm empfindet (Ok, dass geht auch jetzt noch via User-CSS; bei Firefox & Co im Profilordner gibts nen Ordner
chrome wo man die reinpacken kann; ich nutz das sogar noch bei einigen Websites
).
Weil aber die Webseitenersteller mehr EInfluss auf die Darstellung haben wollten, kam ja dann erst soch Tags wie <font> usw. die inzwischen alle wieder rausgeflogen sind, weils dafür jetzt StyleSheets (CSS) gibt.
Einzig bei den Formular-Elementen könnte man drüber streiten ob man das als GUI-Elemente zählen kann.
benneque schrieb:
Ich gehe mal davon aus, dass Mozilla weg von XUL will, weil spätestens seit HTML5 auch damit alles möglich ist und die Welt nicht noch eine weitere XML-Basierte Markup-Language braucht, die dann vom Browser interpretiert wird.
Du zielst sicher auf
https://mail.mozilla.org/pipermail/firefox-dev/2015-July/003063.html ab.
Klingt sinnvoll. Zumal ja
gecko langfristig ohnehin durch die neue Engine
servo abgelöst werden soll. In dem Zuge könnte man dann gleich ein Schnitt machen. Ich gehe davon aus, dass
servo ohne XUL kommt.
benneque schrieb:
Wir haben damals schon für Swing unseren eigenen HTML Interpreter geschrieben, um die GUIs zu gestalten. Weil das 100x flüssiger von der Hand geht als 30 Methodenaufrufe, um ein Label einzufügen mit entsprechender Positionierung und optischer Gestaltung.
Ja. Gute Idee.
Ich war ja damals schon ganz froh, dass Sun Swing ne HTML-Komponente spendierte. Inzwischen kann man ja irgendwie alle Swing-Widgets über HTML/CSS formatieren. Nu bin ich aber schon raus aus der aktiven Java-Entwicklung. :-)
benneque schrieb:
Danach kamen wir dann zu GWT, das auch auf einen XML Dialekt setzt.
Ich fand ja an GWT ganz interessant, dass man für den server-seitigen Teil und dem Client-Teil nur eine Sprache braucht (also in dem Fall Java).
XML für GUI-Gestaltung find ich aber weiterhin ähm suboptimal. Wie gesagt. Ich will kein Sprach-Hopping.
benneque schrieb:
Dabei geht es ja auch ausschließlich um die Gestaltung von Oberflächen und nicht um deren Funktionalität.
Schon klar.
benneque schrieb:
Da kannst du dir JavaFXs FXML, Qts QML, Mozillas XUL, GWTs UiBinder oder natürlich auch HTML anschauen: Überall wird eine eigene Sprache für die Definition der GUI benutzt, weil es wesentlich einfacher ist, maschinenlesbar (für diverse grafische GUI Editoren)
Also das wäre ja wenigstens noch cool, wenn es einen sprachübergreifenden Standard gäbe. Wenn man z.B. sein FXML auch 1:1 übernehmen könnte für die Qt-Entwicklung.
Obwohl das vielleicht sogar via XSLT möglich wäre. Keine Ahnung. Vielleicht gibt es ja dazu Projekte.
Was die GUI-Editoren angeht das geht ja auch so. Nicht-XML-Quelltext ist ebenso maschinenlesbar. Also muss er ja auch schon per Definition. :-)
benneque schrieb:
und auch für Designer (die keine Ahnung von Programmierung haben) beherrschbar.
Das ist vielleicht der einzige Punkt den man gelten lassen könnte. Wobei es mir auch merkwürdig vorkommt, dass ein Designer bei Java-Quelltext wie ein Schwein ins Uhrwerk guckt aber bei sowas wie
Code:
<GridPane alignment="CENTER" hgap="10.0" vgap="10.0"
xmlns:fx="http://javafx.com/fxml"
fx:controller="fxmltableview.FXMLTableViewController">
<padding>
<Insets bottom="10.0" left="10.0" right="10.0" top="10.0" />
</padding>
</GridPane>
ist ihm alles sonnenklar. :-)
Der wird vermutlich ohnehin Tools a-la
SceneBuilder einsetzen und kommt so auch mit dem XML praktisch nicht in Berührung.
benneque schrieb:
Dank solcher Technologien kann man die Arbeit extrem gut aufteilen, ohne dass Nachteile für irgendwen entstehen.
Naja. Die XML-Syntax ist schon etwas ausufernd. Da finde ich S-Expressions schon etwas angenehmer. Beispiel HTML:
Code:
<html>
<head>
<title>Meine tolle Seite</title>
</head>
<body>
Ist noch im Aufbau ...
</body>
</html>
als S-Expression:
Code:
(html
(head
(title "Meine tolle Seite"))
(body "Ist noch im Aufbau ..."))
Für mich als Lisp-Entwickler kommt neben der Kürze natürlich noch hinzu, dass ich meine eigentliche Sprache nicht verlassen muss. Ich brauch auch keine extra Parsing-Bibliothek und dann auf die Elemente ganz natürlich zugreifen wie ich auch mit den anderen nativen Datenstrukturen in Lisp umgehe.
Aber auch in der sonstigen Welt stößt ja XML nicht auf ungeteilte Gegenliebe. Beim Datenaustausch (wofür ja XML u.a. mal geschaffen wurde) kommt ja gerne mal JSON statt XML zum Einsatz.
Ok. Vielleicht bin ich etwas XML-Verdrossen. :-)
Ich mein, ich hab damit Ende der 90er Jahre angefangen. Mit
Apache Cocoon (das Projekt gibts ja heute noch), wo man seine Daten ja in XML schreibt und Cocoon dann je nach Ausgabegerät mit einem passenden XSL dann in HTML, PDF, WML gewandelt hat. Fand ich schon cool.
Dann aber breitete sich XML immer mehr aus. In (schmerzhafter) Erinnerung ist mir noch Tomcat, wo ich als erstes wahrgenommen hab, dass dann plötzlich auch alle Konfigurationsdateien mit XML geschrieben wurden. Und mit jeder Version wurde es schlimmer. Dann kam irgendwie noch Ant hinzu. Irgendwie artete das dann in Konfigurationsorgien aus, wenn man irgendwie was aufgesetzt hat. Da hat XML ja nicht direkt was mit zu tun. Aber irgendwie pocht heute da noch was im Kopf, wenn ich das Wort XML höre oder sehe. :-)
Jedenfalls seitdem hat sich bei mir ne ziemliche Ernüchterung eingestellt was XML angeht.
benneque schrieb:
Und JavaFX GUIs empfinde ich auf halbwegs aktuellen System als extrem flott. FullHD Applikationen auf einem Tablet mit hunderten sichtbaren Elementen, Drag & Drop, Animationen, etc. pp. Keine Ruckler, keine Verzögerungen und von der Darstellungsgeschwindigkeit auf einem Level mit dem Home-Screen eines frisch aufgesetzten iPhone 6.
Heute wird ja ohnehin bei solchen Sachen wenn möglich auf GPU-Unterstützung gesetzt. Von daher sollte GUI heute generell kein Problem mehr sein.
benneque schrieb:
Natürlich frisst es mehr CPU und RAM, aber wenn die Ressourcen vorhanden sind, kann man sie ja ruhig nutzen
Jetzt weiß ich auch, warum die Smartphone-User nur am aufladen sind, während mein altes Nokia problemlos 3 Wochen durchläuft. :-)
Gruß
Andy
