WPF Anwendungen in freier Wildbahn?

[Dravere]

Artchi schrieb:

Oder ist es wirklich nur für Entwickler ein Fortschritt?

Also ich sehe zuerst mal einen recht grossen Fortschritt für den Entwickler, wenn der Entwickler denn mal endlich in WPF drin ist und auch MVVM verstanden hat. Auch wenn sich WPF selber zeichnet, so zeichnet es ja trotzdem zuerst mal die Standardcontrols nach.

Für den Benutzer kann es auch einen Fortschritt geben, da man eben gewisse Dinge den Bedürfnissen des Benutzers einfacher anpassen und kombinieren kann. Meine Erfahrung in Usability ist allerdings bisher, dass ein Vorteil für einen Benutzer nicht durch ein Framework kommt. Im allgemeinen kommt der Vorteil dadurch, dass der Hersteller die Benutzungsprozesse genau analysiert und die Anwendung dementsprechend anpasst. Wenn diese Anpassung dann leicher geht, ist das natürlich von Vorteil und dies ist mit WPF gegeben.

Aber wenn du eine Liste von WPF Anwendung willst:
http://stackoverflow.com/questions/7837/what-real-world-wpf-applications-are-out-there/4456279#4456279

Grüssli

[Artchi]

Dravere schrieb:

Also ich sehe zuerst mal einen recht grossen Fortschritt für den Entwickler, wenn der Entwickler denn mal endlich in WPF drin ist und auch MVVM verstanden hat. ...

Für den Benutzer kann es auch einen Fortschritt geben, da man eben gewisse Dinge den Bedürfnissen des Benutzers einfacher anpassen und kombinieren kann.

Hier stimme ich dir natürlich voll zu! Bisher habe ich nämlich von C# und .NET Abstand gehalten, da ich in WinForms keinen Vorteil sei, wenn ich z.B. C++ Toolkits nutze.
Ich habe mich mal in WPF eingelesen, und fand schon sehr viele interessante Dinge für den Entwickler. Das es auch eine Folge für den User haben kann, stimmt natürlich.

Dravere schrieb:

Meine Erfahrung in Usability ist allerdings bisher, dass ein Vorteil für einen Benutzer nicht durch ein Framework kommt. Im allgemeinen kommt der Vorteil dadurch, dass der Hersteller die Benutzungsprozesse genau analysiert und die Anwendung dementsprechend anpasst. Wenn diese Anpassung dann leicher geht, ist das natürlich von Vorteil und dies ist mit WPF gegeben.

Ich hatte das auch nicht anders erwartet. Durch die Trennung der GUI in XML fand ich das schon sehr interessant, das man solche Anpassungen eben mal machen kann, ohne den Code anzufassen. Auch wenn es nur das Umpositionieren von Komponenten ist.

Dravere schrieb:

Aber wenn du eine Liste von WPF Anwendung willst:
http://stackoverflow.com/questions/7837/what-real-world-wpf-applications-are-out-there/4456279#4456279

Danke! Sowas habe ich gesucht.

[Artchi]

Dann noch das WorldWide Telescope von MS Research. Allerdings bin ich da eher enttäuscht, da viele Controls (vor allem die Popup-Controls) eher nach Win95 aussehen. Und ansonst auch nichts von GUI-Animationen zu sehen ist.

[asc]

Artchi schrieb:

Und ansonst auch nichts von GUI-Animationen zu sehen ist.

GUI-Animation sehe ich persönlich in vielen Bereichen (selbst in einer WPF-Anwendung) als zumeist unnötiges Spielzeug an.

[Artchi]

Ja, ich sage nicht das Animationen in jeder Anwendung von Vorteil sind (kann man auch im Windows UX Guide nachlesen). Aber WPF ist doch ehrlich gesagt dafür entworfen, um vom starren GUI weg zu kommen bzw. eine Alternative zu diesem zu haben. D.h. wenn ich eine Anwendung in WPF entwickle, dann doch mit der Intention, mehr an GUI rauzuholen, als ich es mit z.B. Windows Forms kann?

Sowas wie WorldWide Telescope ist keine Business- oder Produktivity-Anwendung, da kann man Animationen erwarten, vorallem mit WPF.

Bei einer Buchhaltungs-Anwendung gehe ich mit, das man da auf Spielereien verzichten kann. Aber dafür würde ich glaube ich kein WPF einsetzen?

[asc]

Artchi schrieb:

D.h. wenn ich eine Anwendung in WPF entwickle, dann doch mit der Intention, mehr an GUI rauzuholen, als ich es mit z.B. Windows Forms kann?

Ich sehe keinen Grund in ein UI-Framework zu unterstützen, bei dem nicht mit wirklichen Aktualisierungen mehr zu rechnen ist. Zudem sehe ich keine wirklichen Gründe nicht auch klassische Oberflächen mit WPF zu entwickeln, man hat zumindest die Freiheit vom harten Rahmen auszubrechen wenn man es wirklich benötigt.

Artchi schrieb:

Sowas wie WorldWide Telescope ist keine Business- oder Produktivity-Anwendung, da kann man Animationen erwarten, vorallem mit WPF.

Ich erwarte Animationen in keiner Anwendung, wenn es nicht gerade Vorteile in der Visualisierung etc. bringt. Animationen sollten nur da eingesetzt werden wo es auch einen Mehrwert bringt.

[Artchi]

Dann müsstest du auch die Progressbar verhindern. Oder wenn ich in Windows ein Fenster minimiere oder maximiere, wird auch animiert.

Die WPF wird nicht weiter entwickelt?

[asc]

Artchi schrieb:

Die WPF wird nicht weiter entwickelt?

War auf Windows Forms bezogen.

Zu WPF weiß ich nichts, befürchte aber das kurz nach WinRT tatsächlich auch WPF ein solches Schicksal erwartet.

Artchi schrieb:

Dann müsstest du auch die Progressbar verhindern. Oder wenn ich in Windows ein Fenster minimiere oder maximiere, wird auch animiert.

Ich meine unnötige Zusatzanimationen, eine Progressbar macht imho durchaus Sinn (oder wie in der Anwendung an der ich arbeite eine kleine Minianimation um zu zeigen das der Inhalt eines bestimmen Teilfensters geladen wird [asynchrones Laden über einen Service]).

[Artchi]

OK, um WinForms wäre es nicht schade. Denn im Prinzip ist das ja nur ein Wrapper um die Win32 Windows Controls. Und die wiederrum entwickeln sich ja schon ewig nicht weiter (mal davon abgesehen, das vielleicht mal das SystemLink-Control dazu kam).

Aber um die WPF fände ich es schade, da ich das Konzept dahinter und die Möglichkeiten der Animationen schon sehr gut finde.

[inflames2k]

asc schrieb:

Zu WPF weiß ich nichts, befürchte aber das kurz nach WinRT tatsächlich auch WPF ein solches Schicksal erwartet.

Vorsicht, wirf bitte keine GUI-Technik mit der WinRT in einen Topf. Die WinRT ersetzt viel mehr die WinAPI.

[asc]

inflames2k schrieb:

asc schrieb:

Zu WPF weiß ich nichts, befürchte aber das kurz nach WinRT tatsächlich auch WPF ein solches Schicksal erwartet.

Vorsicht, wirf bitte keine GUI-Technik mit der WinRT in einen Topf. Die WinRT ersetzt viel mehr die WinAPI.

WinRT liefert aber ebenso ein GUI-Framework, daher kann ich, wenn ich WPF mit WinRT vergleiche mich durchaus auf die Funktionalitäten beziehen bei denen es eine Überlappung gibt.

Anderseits ist WinRT nicht in jeden Bezug mächtiger als die WinAPI, in einigen Punkten ist es sogar erst einmal eingeschränkter, gerade in reinen Clientszenarien. WinRT (wenn MS hier nichts Neues behauptet) kann z.B. nur indirekt auf Datenquellen über Services zugreifen.

[hustbaer]

Dravere schrieb:

Woher soll ich wissen, dass etwas mit WPF funktioniert? Eine Anwendung, welche mit WPF, WinForms, Qt oder sonstige GUI-Biblitohek geschrieben wurde, kann man vielfach nicht unterscheiden.

Indem man sie im Reflector/... aufmacht und nachguckt?

Ich kann mit WPF das gleiche Aussehen wie bei WinForms erreichen. Und vielfach tue ich persönlich dies auch, da die Anwender daran gewohnt sind und damit umgehen können.

Also mich würde das auch interessieren, z.B. auch hinsichtlich Speicherverbrauch & Performance der GUI. Speziell natürlich grosse komplexe GUI-Teile.

Wobei man natürlich aus einem einzigen WPF Programm mit mieser Performance nicht schliessen könnte dass WPF immer miese Performance hat.
Aus mehreren Applikationen von den unterschiedlichsten Herstellern könnte man aber IMO recht gut ableiten, wie einfach oder schwer es ist mit WPF ne performante GUI hinzubekommen.

[hustbaer]

asc schrieb:

WinRT (wenn MS hier nichts Neues behauptet) kann z.B. nur indirekt auf Datenquellen über Services zugreifen.

Was verstehst du unter Datenquellen?

[Dravere]

hustbaer schrieb:

Indem man sie im Reflector/... aufmacht und nachguckt?

lol
Gut, aber dazu brauchst du nicht einmal den Reflector oder dergleichen. Kannst auch einen normalen Texteditor nehmen, darin das Programm öffnen und nach "xaml", "http://schemas.microsoft.com/winfx/2006/xaml/presentation" oder "System.Windows.Controls", usw. suchen

Aber wer macht das schon bei jedem Programm oder überhaupt einem, welches er nutzt?

Grüssli

[asc]

hustbaer schrieb:

asc schrieb:

WinRT (wenn MS hier nichts Neues behauptet) kann z.B. nur indirekt auf Datenquellen über Services zugreifen.

Was verstehst du unter Datenquellen?

Datenbanken, Dateisystem...

[hustbaer]

Hm. OK.
Und was unter Service?
Man wird ja wohl nicht über ein Web-Service auf Files oder Datenbanken zugreifen. Und über einen "Windows-Dienst" ja wohl auch nicht...
Das wäre zumindest beides doof.

[asc]

Um nochmal das mit den WinRT-Datenzugriffen zu konkretisieren:
1. WinRT kann ohne Services nur auf bestimmte Ordner zugreifen (Sandbox).
2. Alle Zugriffe die über diese Ordner hinaus gehen (Darunter zählt auch der Zugriff auf beispielsweise einen SQL Server) erfolgen über Webservices.

[Zwergli]

asc schrieb:

Zu WPF weiß ich nichts, befürchte aber das kurz nach WinRT tatsächlich auch WPF ein solches Schicksal erwartet.

Die Beziehung WinRT und WPF ist ja ein wenig komplexer. WPF bleibt ja erstmal bestehen, als UI Technologie für nicht Metro Anwendungen basierend auf .Net.

Das interessante ist ja jetzt, das man zwar mit WPF keine Metro Applikationen schreiben kann, aber sehr wohl XAML nutzen kann zum GUI Design und C# als Backendsprache.

Für den Entwickler ändert sich dadurch gar nicht arg viel. Es gibt natürlich kleine Unterschiede, aber es werden bei WinRT die gleichen Tools benutzt wie bei der .Net Variante - VS und Blend. Im großen und ganzen ändert sich die darunterliegende Technologie zwar (wobei WinRT eigentlich auch nur .Net in unmanaged Code mit COM realisiert ist), aber eigentlich wird sich das für den Entwickler fast genauso anfühlen wie früher und er kann weiterhin voll auf dem vorhandenen Wissen aufbauen.

Das ist z.B. auch der Punkt der mich immer an der ganzen "Silverlight ist tot" Diskussion gestört hat - das mag faktisch richtig sein, dass Silverlight als Pluginlösung nicht weiterentwickelt wird, aber das Entwickler mit WinRT und XAML eine vollkommen gleichwertige Lösung bekommen wird kaum erwähnt. Silverlight Programmierer können fast gleich weiterprogrammieren, nur dass die Technolgie dadrunter halt ne andere ist.

[nn]

Zwergli schrieb:

Für den Entwickler ändert sich dadurch gar nicht arg viel.

GUI-technisch nicht, was die Background-Logik angeht, ändert sich schon so einiges.

Datenzugriff wurde ja schon genannt, aber das asynchrone Programmiermodell in WinRT dürfte einige Änderungen an bestehendem C# und erst recht C++ Code erforden.

[asc]

nn schrieb:

Datenzugriff wurde ja schon genannt, aber das asynchrone Programmiermodell in WinRT dürfte einige Änderungen an bestehendem C# und erst recht C++ Code erforden.

Ich seh die Differenzen hier nicht so gravierend, wenn ich die Codeausschnitte richtig deute sehen sie fast so aus, wie ich ohnehin bereits unter WPF hantiere (Ich nutze z.B. asynchrone Services...).