PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Zukunft der GUI Entwicklung?


Gast bittet um Aufklärung
2011-09-25, 08:55:47
Früher wurde bei Anwendungen die GUI direkt in den Programmcode reinprogrammiert.

Das galt für die WinAPI, MFC und für Java Swing.
Aber heute wird die GUI mit Technologien wie XAML & Co beschrieben
und erst dann von der Programmiersprache genutzt.


Gibt es irgendwo einen Überblick dieser ganzen GUI Beschreibungstechniken/sprachen?
Was verwendet man da z.B. für Qt und GKT+?
War es da nicht AFAIK auch so, daß man die GUI mit z.B. Glade zusammengeklickt hat und dann der GUI Code Veränderbar als XML Datei gespeichert wurde?

Und wie sieht es da bei Java aus, wird da immer noch mit Swing hardcodiert oder gibt es da ähnliches wie XAML?

Monger
2011-09-25, 10:23:17
Siehe dazu auch diesen Thread (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=512836).

Diese deklarativen GUI Beschreibungssprachen sind zwar noch nicht überall verbreitet, und nicht überall gleichermaßen ausgereift, aber sie kommen. Es bringt einfach massive Vorteile, wenn man bestimmte Beziehungen auf der GUI direkt dort modellieren kann, ohne dafür speziellen Code-behind schreiben zu müssen. Das öffnet den Weg für gescheite GUI Editoren, wo der Designer sich austoben kann ohne dass er ständig einen Entwickler an seiner Seite hatte. In der Realität ist es doch bisher größtenteils so, dass der Entwickler selbst das GUI Design übernimmt - wofür er eigentlich weder die Zeit noch die Qualifikation hat.

Gast bittet um Aufklärung
2011-09-25, 10:33:55
Nutzt man solche deklarativen UIs eigentlich auch für Anwendungen die aus einer GUI mit Schaltflächen,Buttons usw. und einer Zeichenebene besteht?

Ich denke da z.B. an ein CAD Progamm.
Würden hier deklarative UIs ebenfalls Sinn machen, wenn die deklarativen UIs z.B. die Parametereingabe für die Objekte auf der Zeichenebene übernehmen sollen oder sind in solchen Spezialfällen deklarative UIs eher ein Hindernis, so daß es wohl besser wäre, die GUI gleich in den Programmcode reinzucoden.

PatkIllA
2011-09-25, 10:43:15
Das öffnet den Weg für gescheite GUI Editoren, wo der Designer sich austoben kann ohne dass er ständig einen Entwickler an seiner Seite hatte.Ein paar Knöpfe verschieben ging auch schon mit den alten Designern und ein reiner Designer ohne fundierte technische Kenntnisse bekommt auch keine brauchbare GUI hin, die wartbar bleibt, den Anforderungen in der Rechnerwelt gerecht wird und wiedervendbar ist.
Ich kenne jetzt nur XAML, aber da erreicht man vieles erst durch den geschickten Einsatz von Konvertern und/oder einem angepassten Viewmodel.

Nutzt man solche deklarativen UIs eigentlich auch für Anwendungen die aus einer GUI mit Schaltflächen,Buttons usw. und einer Zeichenebene besteht?

Ich denke da z.B. an ein CAD Progamm.
Würden hier deklarative UIs ebenfalls Sinn machen, wenn die deklarativen UIs z.B. die Parametereingabe für die Objekte auf der Zeichenebene übernehmen sollen oder sind in solchen Spezialfällen deklarative UIs eher ein Hindernis, so daß es wohl besser wäre, die GUI gleich in den Programmcode reinzucoden.Warum soll das nicht gehen? Die GUI kann sich per Datenbindung, die Werte vom Datenmmodell holen und die Werte zurückschreiben und das Modell reagiert dann auf die Änderungen entsprechend.

Monger
2011-09-25, 10:51:21
Ich hab hier mal im Forum eine WPF Anwendung gesehen, die Schaltplatinen in 3D darstellt, und dann zusätzliche Infos für jeden Chip anzeigt sobald man drauf klickt. Auf der linken Seite war da eine ListBox, auf der rechten ein paar Buttons, und in der Mitte halt der 3D Viewport.

Ich kann nur für WPF sprechen, aber es gibt bereits in .NET 4.0 einige sehr nützliche 2D und 3D Controls, wie z.B. eine Ink Canvas, oder eben ein 3D Viewport.
Wie skalierbar das ganze ist, d.h. ob das immer noch so performant ist wenn man eine ausgewachsene CAD Anwendung daraus schustert... weiß ich nicht. Aber grundsätzlich halte ich das schon für möglich.

Monger
2011-09-25, 11:04:58
Ein paar Knöpfe verschieben ging auch schon mit den alten Designern und ein reiner Designer ohne fundierte technische Kenntnisse bekommt auch keine brauchbare GUI hin, die wartbar bleibt, den Anforderungen in der Rechnerwelt gerecht wird und wiedervendbar ist.

Klar muss ein Designer seine GUI Controls kennen. Aber er muss dafür keinen Quellcode verstehen. Wie gesagt: bisher war die Rolle des Designers oft etwas vernachlässigt. Da hat der Entwickler selbst alles gemacht - dementsprechend bescheiden sieht viele kommerzielle Software aus. Da wird es in Zukunft eine klarere Rollenteilung geben.


Ich kenne jetzt nur XAML, aber da erreicht man vieles erst durch den geschickten Einsatz von Konvertern und/oder einem angepassten Viewmodel.

Naja, alles ist relativ. Animationen z.B. wären früher nur programmatisch denkbar gewesen, mit XAML lässt sich das auch im GUI Editor wunderbar machen.
Es gibt einige eindrucksvolle Beispiele wo nicht eine einzige Zeile im Event Handling geschrieben wird, sondern alles in XAML abgebildet ist, wie z.B. sowas ähnliches wie ein Explorer für Bilder, oder ein Texteditor mit Cut/Copy/Paste/Undo/Redo.

Die Konverter sind eine Schwachstelle, da gebe ich dir recht. Aber die bewegen sich nunmal im Randgebiet zwischen Daten und GUI. So wie du letztendlich natürlich die Daten bereitstellen musst, musst du halt auch die Konverter dazu einmalig schreiben. Wenn die Programmlogik hinten dran steht, brauchst du für Änderungen an der GUI keinen Programmierer mehr. Das ist schonmal ein dramatischer Schritt nach vorne gegenüber früher.

Gast bittet um Aufklärung
2011-09-25, 11:25:13
Naja, alles ist relativ. Animationen z.B. wären früher nur programmatisch denkbar gewesen, mit XAML lässt sich das auch im GUI Editor wunderbar machen.

Wie performant ist das dann, wenn man einen animierten Button in XAML realisiert?

Ich denke an XAML halt immer an Skripte und Beschreibungssprachen und so etwas ist ja meist deutlich langsamer als compilierter Binärcode oder Datenobjekte die bereits in Binärer Form vorliegen.

Trap
2011-09-25, 12:12:18
Ich denke an XAML halt immer an Skripte und Beschreibungssprachen und so etwas ist ja meist deutlich langsamer als compilierter Binärcode oder Datenobjekte die bereits in Binärer Form vorliegen.
XAML macht ja kaum etwas, alles was Performance braucht, wird von den Controls selbst gemacht. Bei Animation legt man in XAML ja nur fest, dass nach xy ms ein Wert in ein Control geschrieben wird und dann neu zeichnen des Controls aufgerufen wird. Das ist mit Sicherheit auch mit einem schlechten Interpreter kein Performancehinderniss.

Aber mich würden die Details auch interessieren, hat jemand einen Link wie genau XAML ausgeführt wird?

Monger
2011-09-25, 12:27:13
Aber mich würden die Details auch interessieren, hat jemand einen Link wie genau XAML ausgeführt wird?
Ich glaube, Microsoft legt diese Details ganz bewusst nicht offen - aber im Endeffekt wird damit ganz normaler IL Code erzeugt. Beim Debuggen sieht man das manchmal, dass dann eine "Window.xaml.g.vb" bzw. "cs" erzeugt wird. Man kann sich die auch ansehen, sieht halt nur äußerst hässlich aus.

Letztendlich ist das nichts anderes als ein Resourcencompiler. XAML selbst ist halt sehr eleganter syntaktischer Zucker. Man kann ja auch selbst alles in WPF prozedural runter programmieren, aber natürlich leidet dann die Übersichtlichkeit.

Gast
2011-09-26, 23:05:57
In der Realität ist es doch bisher größtenteils so, dass der Entwickler selbst das GUI Design übernimmt - wofür er eigentlich weder die Zeit noch die Qualifikation hat.

Das kommt immer darauf an, was man mit seiner Applikation bezwecken will. Lässt man die Entwickler selbst werken, dann sieht die Applikation meistens sehr einfach aus, funktioniert aber schnell und stabil, was im Bereich der Individualsoftware eindeutig der richtige Weg ist.
Schreibt man hingegen Jambaartige Klicki bunt 3D Effekt Handysoftware, die einen mit irgendwelchen Effekt erschlagen muss, weil der Inhalt meistens eher mittelprächtig ist, dann lässt man eher die Grafiker ran.

Meine Meinung zu dem Thema ist, dass eine GUI in erster Linie effizient zu bedienen sein soll und halbwegs normal aussehen soll, auch wenn man die Auflösung ändert. Deshalb sind meine Programme auch immer nur auf das notwendigste beschränkt und es macht nicht viel Sinn das GUI seperat vom Code zu entwickeln.
Das GUI komplett im Code zu erzeugen ist aber auch der falsche Weg, da man mit einem Designer deutlich weniger Zeit benötigt und man hier eine Vorschauf Funktion hat. Da kann auch ein Programmierer, der das Projekt nicht kennt ziemlich schnell eine Kleinigkeit ändern, wenn er einfach das jeweilige Formular aufmacht und den Event Handler des jeweiligen Buttons aufruft.
Ich denke, dass Microsoft das mit den klassischen Windows Forms ganz gut gelöst hat und genau das ist, was mehr als 90% der Entwickler benötigen. Bei Spielen bzw. Software für Handys Tablets, was Microsoft mit den Metro Apps beabsichtigt, ist das natürlich etwas anderes, aber gerade die ganzen Mobile Apps bzw. Tablets sind denke ich nur eine vorübergehende Mode. Die Bedienung eines Rechners mit Maus und Tastatur hat sich nicht umsonst durchgesetzt.

Exxtreme
2011-09-27, 09:16:29
Also für Java gibt es hier eine kleine Sammlung an Frameworks:
http://java-source.net/open-source/xml-user-interface-toolkits


Es bringt einfach massive Vorteile, wenn man bestimmte Beziehungen auf der GUI direkt dort modellieren kann, ohne dafür speziellen Code-behind schreiben zu müssen. Das öffnet den Weg für gescheite GUI Editoren, wo der Designer sich austoben kann ohne dass er ständig einen Entwickler an seiner Seite hatte. In der Realität ist es doch bisher größtenteils so, dass der Entwickler selbst das GUI Design übernimmt - wofür er eigentlich weder die Zeit noch die Qualifikation hat.

Naja, gescheite GUI-Editoren gibt es ja jetzt auch schon. Die generieren Quellcode, ohne irgendwas kaputt zu machen. Gut, für irgendwelchen Klicki-Bunti-Glump eignen sie sich nicht.

Mr.Freemind
2011-09-27, 14:20:02
4Naja, gescheite GUI-Editoren gibt es ja jetzt auch schon. Die generieren Quellcode, ohne irgendwas kaputt zu machen. Gut, für irgendwelchen Klicki-Bunti-Glump eignen sie sich nicht.

So ist es, in Bezug von Java finde/fand ich den GUI Editor von Netbeans ganz nice, der jetzige bei Eclipse (Indigo) ist auch ganz ok und sie sollten reichen um auf die Schnelle "0815"-Oberflächen zu erzeugen. Ob man allerdings mit der Güte des Codes zufrieden sein sollte; sei jedem selbst überlassen.

Ich benutze generell keine GUI-Editoren, wenn man sich eine gewisse Zeit mit den Bibliotheken/Klassen auseinandergesetzt hat (bei mir Swing/QT) programmiert man das irgendwie im "flow" runter ......

Djon
2011-09-27, 21:58:36
Also für Java gibt es hier eine kleine Sammlung an Frameworks:
http://java-source.net/open-source/xml-user-interface-toolkits


Vielen Dank für den Link. Eine schöne Toolkit-Sammlung :tongue:

Gruß Djon

Monger
2011-09-28, 01:07:30
Das kommt immer darauf an, was man mit seiner Applikation bezwecken will. Lässt man die Entwickler selbst werken, dann sieht die Applikation meistens sehr einfach aus, funktioniert aber schnell und stabil, was im Bereich der Individualsoftware eindeutig der richtige Weg ist.
Schreibt man hingegen Jambaartige Klicki bunt 3D Effekt Handysoftware, die einen mit irgendwelchen Effekt erschlagen muss, weil der Inhalt meistens eher mittelprächtig ist, dann lässt man eher die Grafiker ran.

Das ist ein fieses und völlig falsches Vorurteil. Ein ordentlicher Designer weiß, dass weniger meistens mehr ist. Ganz im Gegensatz übrigens zum Entwickler, der oft genug keinen Widerspruch darin sieht, ein Programm "besser" zu machen indem man ihm sukzessive neue Features und Buttons hinzufügt. Wer mal SAP R/3 gesehen hat, wird wissen was ich meine...

Design ist eine sehr eigene Wissensdisziplin. Gibt z.B. sehr interessante Theorien darüber wie eine gescheite Symbolik auzusehen hat, damit man auf Anhieb versteht worum es geht.
Das ist für abteilungsinternes Tooling natürlich nicht so bedeutend, aber selbst da merkt man, wie ein bißchen Hirnschmalz beim Design die Menge an Fehlbedienungen gleich drastisch senken kann.

Gerade Klicki-Bunti zeigt, was für ein miserables Verständnis von Design in der Industrie vorherrscht.


Naja, gescheite GUI-Editoren gibt es ja jetzt auch schon. Die generieren Quellcode, ohne irgendwas kaputt zu machen. Gut, für irgendwelchen Klicki-Bunti-Glump eignen sie sich nicht.
Vielleicht bin ich ja einfach hinterwäldlerisch, aber für mich war der Begriff MVVM sehr neu. Das bildet sich doch auch im GUI Editor SEHR anders ab als wie z.B. Windows Forms MVC umgesetzt hat. Man muss ja auch erstmal hintendran ein Framework haben, was so flexible Data Bindings und Conversions direkt an der Oberfläche zulässt. Windows Forms war dazu definitiv nicht fähig, Swing meines Wissens auch nicht.

mittelding
2011-09-28, 20:56:04
Ich denke, da wird Windows 8 ganz interessant werden. Zum einen wird leider XAML zerfahren (.NET vs. WinRT), zum anderen eben HTML5 + JS für den Desktop. Auf jeden Fall eben deklarativ, Oberflächen imperativ im Code zu schreiben kommt mir nach einiger Zeit vor wie aus der Steinzeit.

Kenny1702
2011-09-28, 22:20:55
Das ist ein fieses und völlig falsches Vorurteil. Ein ordentlicher Designer weiß, dass weniger meistens mehr ist. Ganz im Gegensatz übrigens zum Entwickler, der oft genug keinen Widerspruch darin sieht, ein Programm "besser" zu machen indem man ihm sukzessive neue Features und Buttons hinzufügt.
Das ist ein fieses und völlig falsches Vorurteil. Ein ordentlicher Entwickler weiß, dass weniger meistens mehr ist.:freak:

Nichtsdestotrotz weiß ich, was du meinst.

Monger
2011-09-28, 22:38:46
Ich denke, da wird Windows 8 ganz interessant werden. Zum einen wird leider XAML zerfahren (.NET vs. WinRT), zum anderen eben HTML5 + JS für den Desktop.
Naja, das ist Marketingmäßig n bissl ungeschickt rübergekommen. Metro wird im ganz wesentlichen Maße auf Jupiter basieren, und Jupiter scheint ja Silverlight und WPF zusammenzuführen.
XAML stirbt definitiv nicht aus, eher im Gegenteil.

Edit: JS? JavaScript?? Meinst du nicht eher ASP.NET?


Das ist ein fieses und völlig falsches Vorurteil. Ein ordentlicher Entwickler weiß, dass weniger meistens mehr ist.:freak:

Nichtsdestotrotz weiß ich, was du meinst.
Formulieren wir es mal diplomatisch so: ein guter Entwickler ist zwangsläufig ein Stück weit Architekt und Designer. Geht gar nicht anders.

Trap
2011-09-28, 22:54:26
Edit: JS? JavaScript??
Ja, Javascript. Für Metro-Apps hat man die Wahl zwischen XAML mit C++/.NET und HTML5 mit Javascript: http://msdn.microsoft.com/library/windows/apps/br211386/#hello_world_with_javascript

creave
2011-09-30, 21:52:39
Naja, das ist Marketingmäßig n bissl ungeschickt rübergekommen. Metro wird im ganz wesentlichen Maße auf Jupiter basieren, und Jupiter scheint ja Silverlight und WPF zusammenzuführen.
XAML stirbt definitiv nicht aus, eher im Gegenteil.

Edit: JS? JavaScript?? Meinst du nicht eher ASP.NET?



Ne, das stimmt schon. Die Metro-gui bastelt man sich entweder aus XAML oder HTML5 + Javascript, wobei JS wohl mehr Logik als nur Gui-Logik macht.

Das mit XAML meinte er vermutlich so, dass XAML nicht mehr gleich XAML sein wird. Klassisches .NET XAML scheint nicht mehr 100% kompatibel zu sein zum neuen "Metro-XAML". Nicht die beste Analogie, aber C++ ist auch nicht unbedingt gleich C++, je nach Compiler.

Gast
2011-10-03, 18:24:42
Also einen Entwickler, der meint, dass er professionelle Desktop Software in Javascript schreiben kann, den braucht man nicht allzu ernst nehmen ;-)
Das ganze Late Binding hat vielleicht für kleinere grafische Effekte innerhalb eines Browsers noch einen Sinn, aber für gewöhnliche Desktopanwendungen sicher nicht. Die größte Gefahr besteht durch Fehler in ungetesteten Codezeilen, die noch nie durchlaufen wurden und je mehr ein Compiler hier findet, desto besser. Einmal abgesehen davon ist die Idee der Sandbox zwar im Browser sehr wichtig, hat aber bei Desktop Applikationen den Nachteil, dass man absolut keine Schnittstellen hat.

PatkIllA
2011-10-03, 18:41:37
Man muss es ja nicht direkt schreiben.
Google Web Toolkit schreibt man ja auch in Java und der Webteil kommt als HTML-Javascript raus.