Welches GUI-Toolkit hat Zukunft?

[Unschlüssiger]

Mechanics schrieb:

Man braucht sicher nicht Jahre, um ein GUI Framework zu erlernen. Wenn man etwas Erfahrung hat, braucht man vielleicht eine Woche, dann ist man halbwegs drin und kann schon mal anfangen zu arbeiten, und dann schaut man sich immer wieder an, was man grad braucht.

Wie man innerhalb einer Woche erlernen soll, wie man ein Framework richtig einsetzt und auch das Applikationsdesign passt, ist mir schleierhaft. Normalerweise gehen schon Wochen ins Land bevor irgendeine Zeile geschrieben wird. Irgendwas zusammengeklickt bekommt man sicherlich immer, aber das ist halt nicht das Ziel.
Ich gehe erstmal davon aus, dass man erstmal viele kleine Testapplikationen machen muss um z.B. erstmal so simple Sachen auszuloten, wie man am besten für die zu erwartenden Anwendungsfälle Daten in seine Anwendung bekommt ohne das sich alles weghängt, wenn der SQL Server mal nicht erreichbar ist.

asc schrieb:

Dir ist schon bewusst das WinRT und .NET sich ganz und gar nicht gegenseitig ausschließen? Wenn ich möglichst viel Code zwischen Desktop, WinRT und Web teilen wollte würde ich (sofern es mit Ausnahme von Webclients um die MS-Plattform geht) definitiv auf .Net (Ui: WPF, WinRT und ASP.net) setzen.

Ja das ist mir klar. Nur kann ich für WinRT auch in C++ programmieren (wobei ich aber noch nicht weiss, ob reines C++ auch geht oder es doch nur C++/CLI ist). Allerdings ist bei mir eher der Fokus nicht möglichst viel Code zwischen Web und Windows, sondern zwischen Windows und Linux zu teilen. Qt kommt mir da im Moment noch am nächsten.

[Shade Of Mine]

Unschlüssiger schrieb:

Mechanics schrieb:

Man braucht sicher nicht Jahre, um ein GUI Framework zu erlernen. Wenn man etwas Erfahrung hat, braucht man vielleicht eine Woche, dann ist man halbwegs drin und kann schon mal anfangen zu arbeiten, und dann schaut man sich immer wieder an, was man grad braucht.

Wie man innerhalb einer Woche erlernen soll, wie man ein Framework richtig einsetzt und auch das Applikationsdesign passt, ist mir schleierhaft. Normalerweise gehen schon Wochen ins Land bevor irgendeine Zeile geschrieben wird. Irgendwas zusammengeklickt bekommt man sicherlich immer, aber das ist halt nicht das Ziel.

Wenn du wirklich deutlich länger als eine Woche brauchst um dich in ein neues Framework einzulesen, dann hast du echt Probleme...

[Rhombicosidodecahedron]

Nur kann ich für WinRT auch in C++ programmieren (wobei ich aber noch nicht weiss, ob reines C++ auch geht oder es doch nur C++/CLI ist).

Schlimmer, nicht C++/CLI sondern C++/CX, sieht fast genauso aus, nur ohne Umwege über .Net und greift direkt auf WinRT-Komponenten zu (was etwa COM+MitSternchen ist).

[SideWinder]

@Shade: WPF nachhaltig zu verstehen kann durchaus länger dauern, erste GUIs zusammenzuklicken natürlich nicht.

MfG SideWinder

[Shade Of Mine]

SideWinder schrieb:

@Shade: WPF nachhaltig zu verstehen kann durchaus länger dauern, erste GUIs zusammenzuklicken natürlich nicht.

Klar, aber das sind dann Details.
Nach einer Woche muss ein Programmierer vernueftige Software mit dem Framework schreiben koennen sonst ist entweder der Programmierer oder das Framework Schrott.

Nuancen und Details gibt es immer zu lernen, keine Frage.

[nix_]

Shade Of Mine schrieb:

SideWinder schrieb:

@Shade: WPF nachhaltig zu verstehen kann durchaus länger dauern, erste GUIs zusammenzuklicken natürlich nicht.

Klar, aber das sind dann Details.
Nach einer Woche muss ein Programmierer vernueftige Software mit dem Framework schreiben koennen sonst ist entweder der Programmierer oder das Framework Schrott.

Nuancen und Details gibt es immer zu lernen, keine Frage.

Dieses arrogante und immer gleiche Gefasel ermüdet mich einfach nur noch. Wieviele Sprachen man können muss, wie schnell man sie gelernt haben muss, was man wissen und können muss, wie lange ist sein Schwanz sollte ...

Nur eine Sache, dann klinke ich mich auch wieder aus:
Nach einer Woche schreibt kein Mensch vernünftige Software mit WPF, wenn ihm bis dahin nur Winforms bekannt war. Es geht nicht um kleine Frickelprogramme oder darum mit altbekannten Methoden etwas irgendwie zum laufen zu bringen, sondern um Software, die die Design-Prinzipien eines Frameworks mit hoher Qualität verwenden soll.

Es sind keine Details, die nach so kurzer Zeit noch umbekannt. Nach einer Woche die Prinzipien eines großen Frameworks (oder auch einer Bibliothek) doch noch garnicht erfasst und man hat nur an der Oberfläche gekratzt.

Ich glaube größere Schwanzvergleiche als hier gibt es nur noch in der Gamer-Community. :-k

[Mechanics]

Unschlüssiger schrieb:

Wie man innerhalb einer Woche erlernen soll, wie man ein Framework richtig einsetzt und auch das Applikationsdesign passt, ist mir schleierhaft. Normalerweise gehen schon Wochen ins Land bevor irgendeine Zeile geschrieben wird. Irgendwas zusammengeklickt bekommt man sicherlich immer, aber das ist halt nicht das Ziel.

Überhaupt nicht. Learning by doing. Was ist bei den ganzen Frameworks schon großartig unterschiedlich? Alle haben irgendwelche Widgets oder Komponenten, die meist auch ganz ähnlich heißen, alle haben ähnliche Eigenschaften und irgendeinen (meist sprachspezifischen) Mechanismus, um Events abzubilden. Dann kommen natürlich frameworkspezifische Konzepte dazu (für die es oft aber auch allgeine Muster wie MVC gibt), die muss man sich natürlich vorher anschauen. Deswegen hab ich gesagt eine Woche, das ist schon eine Menge Zeit.
Danach muss man das Framework nicht perfekt beherrschen, das kommt mit der Zeit. Niemand erwartet von dir, dass du ein GUI Framework sofort komplett auswendig kennst, außer du bewirbst dich explizit als GUI-Programmierer, was eher ungewöhnlich wäre. Man fängt einfach an und macht das was man braucht, und wenn man dann eine neue Komponente braucht, die man noch nicht kennt, schaut man kurz in die Doku, wie das funktioniert und das wars.
Und alles andere hat nichts mit dem Framework zu tun. Das sind ganz allgemeine Konzepte. Wie man Daten in seine Anwendung bekommt, wenn der Sql Server nicht da ist, hat absolut gar nichts mit dem GUI Framework zu tun. Das sind ganz allgemeine Konzepte, die du so oder so behrreschen musst. Was machst du, wenn du ein Webservice schreibst, der überhaupt keine GUI hat, aber auf eine Datenbank zugreifen muss, die evtl. nicht zuverlässig verfügbar ist?

[asc]

Mechanics schrieb:

...Was ist bei den ganzen Frameworks schon großartig unterschiedlich?...

Ich finde das einige Frameworks schon massives umdenken erfordern. Imho sind die XAML-Basierten UI-Frameworks (WPF, Silverlight, WinRT) doch schon um einiges anders im Denkansatz als z.B. die klassischen Client-UI-Frameworks. Sie haben zwar durchaus Ähnlichkeiten zu anderen Techniken (wie z.B. HTML/XML), aber gehen doch wesentlich andere Wege als z.B. die MFC, VCL, WinRT...

Eine Woche sehe ich für das Erlernen eines Frameworks aber tatsächlich allgemein als wesentlich zu niedrig an, wenn die Ähnlichkeiten nicht gerade massiv sind, und vielleicht ein Framework sogar gegenüber einen anderen wesentlich vereinfacht ist (z.B. war für mich das Umlernen von MFC zur VCL tatsächlich ein Klacks [zumindest die Grundlagen], umgekehrt wäre es aber wesentlich schwerer gewesen).

Vielleicht liegt meine Einschätzung aber auch daran, das ich Frameworkwechsel selten eigenständig hatte (Meist auch ein Wechsel der Sprache, einiger Paradigmen...).

[Mechanics]

Ich rede nicht davon, ein Framework zu "erlernen", sondern davon, dass man anfangen kann sinnvoll damit zu arbeiten. Alles andere kommt mit der Zeit.
Es gibt in der Tat Frameworks, die sich relativ stark unterscheiden, z.B. MFC und WPF. Aber im Grunde ist es immer noch alles das gleiche und man muss sich nur die wichtigsten Konzepte des Frameworks anschauen. Das Hauptmerkmal von MFC ist wohl die Winapi. Wenn man die eh schon halbwegs beherrscht, ist es halb so wild. Wenn man keine Ahnung davon hat, wirds in der Tat schwierig. Aber MFC ist eh ziemlicher Schrott, von dem her kann es da schon länger dauern, da reinzukommen.
WPF ist im Detail recht komplex, jedesmal wenn ich was damit mache, muss ich mich wieder intensiv reindenken und vergesse die Details schnell wieder. Aber vom Konzept her ist es wieder nichts besonders neues oder einzigartiges und das meiste davon hat man eh schon gesehen. Als ich damit angefangen habe, hab ich einfach Buch durchgelesen, hat vielleicht paar Tage gedauert. Dann hatte ich erstmal einen Überblick, was es gibt, wie es gedacht ist, und wie man das angehen sollte. Dann hab ich auch gleich mit dem Projekt angefangen und die Details dann nebenbei gelernt.
Bis man ein Framework wirklich gut drauf hat, kann es wirklich Monate dauern, aber das wichtigste ist erstmal einen Überblick zu bekommen. Dann kann man sich immer das anschauen, was man braucht, ansonsten bringt es gar nichts, im Voraus irgendwelche Details zu lernen.

[Shade Of Mine]

asc schrieb:

Vielleicht liegt meine Einschätzung aber auch daran, das ich Frameworkwechsel selten eigenständig hatte (Meist auch ein Wechsel der Sprache, einiger Paradigmen...).

Eine komplette Development Platform zu aendern, kostet natuerlich mehr Zeit.

Aber es geht ja nicht darum der Framework Guru zu werden. Ich habe einige Frameworks verwendet die ich nicht komplett verstanden habe - da waere sicher besserer Code moeglich gewesen, aber es geht nicht um den perfekten Code, sondern um Code der gut genug ist.

Und das muss nach einer Woche moeglich sein.

Und da bin ich noch grosszuegig. Bei uns in der Firma hat man keine Woche Zeit fuer ne neue Technik. Aber in der Werbung geht alles schneller und wir haben den Vorteil dass ein Grossteil unseres Codes Fire&Forget ist. Das erleichtert natuerlich das einsetzen neuer Techniken.

[ncl]

Und genau so entstehen diese unwartbaren Frickeleien wie sie in jeder Firma zu finden sind.

[Eisflamme]

Die Frage ist, ob man halbwegs gare Software erstellen möchte, oder es wirklich um größere Architekturen geht. Bei letzteren kann es schon fatal sein, wenn man die Features vom Framework nicht korrekt ausnutzt. Denn unoptimale Ausnutzung ist bei vielen Frameworks dann eben doch Frickelarbeit. Man kriegt es hin, klar, aber sauber im Sinne von gut änderbar, erweiterbar, wartbar? Das denke ich nicht.

Ich hatte mit QT z.B. nicht viel gemacht und war jetzt auch nicht besonders tief in einem Framework drin (ja, das spielt eine Rolle, aber nicht nur). Bei der Entwicklung sind mir mehr und mehr Details erst später aufgefallen. Allein, dass man die Container richtig mit Layouts verbindet und ineinandersteckt. Das Prinzip ist altbewährt, aber bis es dann so aussieht, wie man es haben möchte, oder bis man versteht, wie QT tickt, das kann dauern.

Oder nehmen wir Threads. Klar, die kann man auch über boost verwenden. Bei QT muss man aber zum Beispiel darauf achten, dass man ein QObject erstellt und das erst in einen Thread schieben muss. Anders kann man es lösen, doch das ist dann wegen der Signalzuordnung unsauber und führt zu einigen Problemen. Das findet man nicht in einer Woche raus. Das steht nämlich auch nicht direkt in der Doku als Beispiel, sondern man muss es sich zuerst suchen - obwohl man vorher gar nicht weiß, dass es hier ein Problem gibt (generell hat die Doku einige Schwächen, was ich von vielen bemängelt las; könnte mittlerweile "behoben" sein, bezweifle ich aber).

Auch das Mime-Konzept ist seltsam, dann ist für diverse Event-Methoden noch das ein oder andere zu beachten, was je nach Framework unterschiedlich ist usw. usf.

Edit: Noch ein super Beispiel, wie ich finde: Komm Mal hinter die Facetten von Model und View beispielsweise bei einem Tree bei QT. Da gibt es diverse Abstraktionen wie QModelIndex. Um das richtig zu verwenden, muss man diverse Prüfungen machen und alle möglichen Methoden überschreiben. Dann muss man an bestimmten Stellen irgendwelche Signale senden... alles überhaupt nicht intuitiv. Und Fehler dort sind schwierig zu finden. Und verbinde das dann noch mit Drag&Drop oder anderen Konzepten/Techniken, die in QT ihre Eigenheiten haben und nicht auf das Modell selbst zugeschnitten sind, und Du hast Spaß. Eine Woche kann alleine dafür draufgehen.

Man kriegt nach einer Woche sicherlich etwas zusammengeklickt. Eine größere Software zu erstellen, die reibungsfrei funktioniert, kann aber schon ein Weilchen dauern. Und eine wirklich größere Software architektonisch sauber aufzusetzen, setzt in meinen Augen eine sehr gute Kenntnis mit den Eigenheiten des Frameworks hinaus. Denn auch die Kleinigkeiten und die Erfahrung damit beeinflussen eine große Architektur meiner Erfahrung nach maßgeblich.

Schließe mich im Grunde also somit denen an, die sagen "Eine Woche ist gar nichts".