WPF Anwendungen in freier Wildbahn?
-
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.
-
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.
-
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?
-
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.
-
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?
-
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]).
-
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.
-
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.
-
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.
-
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.
-
asc schrieb:
WinRT (wenn MS hier nichts Neues behauptet) kann z.B. nur indirekt auf Datenquellen über Services zugreifen.
Was verstehst du unter Datenquellen?
-
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. suchenAber wer macht das schon bei jedem Programm oder überhaupt einem, welches er nutzt?
Grüssli
-
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...
-
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.
-
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.
-
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.
-
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.
-
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...).
-
Zwergli schrieb:
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.
Ich hoffe, aber bei MS sehr *hust* zurückhaltenden Aussagen bin ich mir inzwischen überhaupt nicht mehr sicher. Vielleicht versuchen sie nun WinRT und Metro auf biegen und brechen zur Hauptplattform zu ernennen.
Zwergli schrieb:
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.
Wenn auch mit anderen Controls, anderen Bibliotheken, anderen Klassen-/Eigenschaftsnamen etc.
-
asc schrieb:
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.Und über welche API hat man dann Zugriff auf den ganzen Rest?
