ist der hype um wpf vorbei?
-
hustbaer schrieb:
Aber ernsthaft: WPF ist stellenweise schon etwas komplizierter als nötig.
Wenn man ne Kleinigkeit am Aussehen eines Buttons ändern möchte, dann als Antwort "da musst du nur" + 1000 Zeilen XAML Code bekommt, dann ...Sicherlich hast du hier recht. Aber im Vergleich zu Windows Forms hat man deutlich mehr und bessere Möglichkeiten. - Wir entwickeln im Unternehmen unsere Anwendungen zwar auch noch mit Windows Forms aber das eben aus Zeitgründen, da unsere Kunden Projekte am besten noch fertig haben wollen bevor wir den Auftrag haben und Windows Forms schneller zu bauen sind.
Aber betrachtet man WPF in seiner Gesamtheit und vergleicht es mit Windows Forms dann ist es aus meiner Sicht immer überlegen.
-
Hast du schon mit WPF gearbeitet?
-
inflames2k schrieb:
Sicherlich hast du hier recht. Aber im Vergleich zu Windows Forms hat man deutlich mehr und bessere Möglichkeiten. - Wir entwickeln im Unternehmen unsere Anwendungen zwar auch noch mit Windows Forms aber das eben aus Zeitgründen, da unsere Kunden Projekte am besten noch fertig haben wollen bevor wir den Auftrag haben und Windows Forms schneller zu bauen sind.
Das spricht doch eindeutig gegen WPF! Damit ist WPF doch schon gescheitert.
Es ist kompliziert und nicht intiutiv (XML ist der Horror!) für Coder. Das Argument "der Designer-Kollege macht die GUI" ist sowas von weltfremd bei Individual- und LOB-Software, das sich die MS-Leute die gesamte Desktop-GUI-Zukunft damit auf Windows kaputt gemacht haben.
In der Realität macht doch der Coder auch gleich die GUI mit. Und das am Besten in der vertrauten Sprache in der er auch das restliche Projekt macht (z.B. C#).
Ausnahme ist nur Standard-Software (Adobe, Magix und wie sie alle heißen), da mag es tatsächlich GUI-Designer in den Firmen geben. Aber nicht bei Enterprise-Software.
Genau daran ist auch JavaFX 1 bei der Java-Community gescheitert. Da musste man alles in XML und JavaScript machen. Der totale Break! Als Sun merkte, das es keiner will, zog man die Notbremse. Erst JavaFX 2 erlaubte alles komplett in Java zu coden (FXML ist nur eine Option). Und deshalb ist JavaFX 2 auch in der Java-Community angekommen und löst Swing langsam aber sicher ab.
Genau der gleiche Quatsch bei Qt: die GUIs in JavaScript? Viele Qt-Benutzer haben einen Aufstand gemacht und die Qt-Entwickler mussten zurück rudern und versprechen wieder eine C++-API parallel anzubieten. Erst dann gab es Frieden.
Und hier ist WPF noch nicht angekommen. Man könnte irgendwie ohne XAML was machen, aber so richtig ist das nicht offiziell gewollt. Und deshalb ist WPF auch gescheitert. Auch bei Euch! Ihr macht selbst neue Aufträge in WinForms, weil WPF mit seinem XAML der letzte Rotz ist.
Wenn WPF so geil wäre, wie du dir einredest, warum benutzt ihr das nicht bei neuen Aufträgen?
-
Ich habe ja nicht gesagt, dass wir es noch nie eingesetzt haben. - Klar haben wir auch schon Visualisierungen für die Kunden gebastelt, wo WPF das Mittel der Wahl war. Einfach weil es deutlich einfacher ist dynamische Anzeigen zu generieren als mit Windows Forms.
- Im groben und ganzen hast du jedoch recht, im Enterprise Bereich mit Individual-Software wird es in seiner jetzigen Form nie wirklich Verwendung finden. -
-
hustbaer schrieb:
Aber ernsthaft: WPF ist stellenweise schon etwas komplizierter als nötig.
Wenn man ne Kleinigkeit am Aussehen eines Buttons ändern möchte, dann als Antwort "da musst du nur" + 1000 Zeilen XAML Code bekommt, dann ...Ja, kenn ich
Und nein, ich habe nicht sooo viel damit gemacht, hab ich ja geschrieben 
Aber ich wüsste jetzt nicht, was besser wäre. Ich arbeite jetzt (seit Jahren) mit Qt und finds gut. Wahrscheinlich das beste C++ GUI Framework (nicht das Qt Quick Zeug, noch Qt 4). Nur ist es auch oft sehr umständlich, wenn man etwas nicht so machen will, wie in Qt vorgesehen. Unsere GUIs sind sehr komplex. Und da erreicht man schnell irgendeine Grenze, wo irgendwas nicht geht. Und dann muss man das fast alles selber schreiben. Es soll aber doch mit dem Rest zusammenspielen. Und es soll über Stylesheets anpassbar sein (und die API ist überhaupt nicht rausgelegt). Und und und... Und ich glaube, vieles davon könnte man mit WPF dann einfach "verschachteln".
Ich will kein JavaScript, deswegen interessiert mich Qt Quick überhaupt nicht. Aber ich hab kein Problem damit, XML zu schreiben. Und bei XAML ist recht klar, was man schreiben, und wie man das Layout strukturieren muss. Da ist kein Magic und kein Gefriemel (siehe HTML) dahinter.
-
KEINE MAGICK ??
Ne, das würde ich so über WPF nicht sagen
-
@inflames2k
Ich meine einfach dass die Schwächen/Probleme/Lästigen Dinge bei einigen Libraries/Technologien/... erst rauskommen wenn man etwas länger damit arbeitet. WPF gehört da mMn. dazu.
Bzw. eigentlich muss ich sagen... bei WPF hat man erstmal überhaupt keinen Plan wie irgendwas funktioniert. Dann kommt eine Phase wo man meint sich halbwegs gut zurechtzufinden. Und dann kommt man Stück für Stück auf die ganzen Probleme drauf.Ist jetzt nicht so dass ich meine WPF wäre der letzte Dreck. Aber ... SO toll ist es dann auch wieder nicht. Und vor allem nicht besonders unproblematisch/freundlich/angenehm.
-
WPF hat kein Magic? WPF ist TEUFELSZEUG!
-
Hat denn schon jemand mal ernsthaft mit UWP gearbeitet? Das verwendet ja auch XAML, vermutlich eine modernere Fassung, ist deutlich performanter als WPF [1]. Im Moment müssen ja alle noch Windows 7 unterstützen, aber so in 5-7 Jahren könnte UWP eine schöne Alternative werden.
[1] Das war bisher immer mein Ausschlußkriterium für WPF, daß ich eigentlich noch nie ein nicht träge wirkendes WPF-GUI gesehen habe, bis auf Visual Studio 2012ff, und selbst das hat seine trägen Momente.
-
Ich wette das Artchi einfach zu dumm für WPF ist und es deshalb schlecht findet.
-
Artchi schrieb:
... Das Argument "der Designer-Kollege macht die GUI" ist sowas von weltfremd bei Individual- und LOB-Software, das sich die MS-Leute die gesamte Desktop-GUI-Zukunft damit auf Windows kaputt gemacht haben.
In der Realität macht doch der Coder auch gleich die GUI mit. Und das am Besten in der vertrauten Sprache in der er auch das restliche Projekt macht (z.B. C#)...
Der WPF GUI-Designer muss nun sogar mehr über die internen Mechanismen der zugrundeliegenden Programmiersprache wissen als vorher. Wenn der Designer schon XAML beherrschen und sich in den C# Namespaces auskennen muss, kann er das Zeug auch gleich richtig lernen bzw alternativ gleich der Programmierer sein. Einen Designer der die GUI ausschließlich in Visual Studio baut kann ich mir überhaupt nicht vorstellen. Das meisste Zeug wird da ja nichtmal vom Editor unterstützt und muss von Hand in den XAML Code gebastelt werden.
-
Ich hab bisher "nur" mit WPF gearbeitet, WinForms nur nach Anfrage selten)! Ich denke man muss ich eben durchbeißen, egal welches Framework.. erst wenn man Erfahrung gemacht hat und es "etwas" kann ist man effektiv und schnell und macht spass..
Somit findet man automatisch andere Frameworks, mit denen man sich kaum auseinander gesetzt hat als kompliziert und scheisse ,weil man halt 'noch' net rafft
)Müsste ich jetzt was in WinForms machen (was wohl nich ganz so komplex ist), würde ich fluchen und länger brauchen als beim komplexen WPF)
