I apologize for my newbie question by why do WPF apps look like web pages?
I am new to gui and still shopping for a book to learn gui programming. The push seems to be in the direction of WPF but all the screenshots of WPF applications that I've seen look like cheap web pages. Frankly I'd be ashamed to sell an app that looked like a web page.
I realize that WPF is built on XML technology but can you not build normal looking WPF apps in Visual Studio (via button("widget")) drag-n-drop? In other words an app that does not look like a web page?
How can WPF be a replacement for WinForms or the like when it doesn't provide the same standard application look?
The default look of WPF applications is admittedly rather simple, but WPF allows unprecedented control over how your application looks.
Here are some examples, all of them WPF applications.
If you are to deveop an application under .net and are able to target .net 3.5 or above, you will want to use wpf. If you don't know much about ui technology and want to work with .net, understanding windows forms is useful but not necessary. You should learn wpf regardless.
2 perks that I have found while using the framework:
- it is very easy to inject branding and custom interactivity into your app. It is then very easy to change these when your sales guy decides the want it blue, not red.
- the way components are organized on screen is relational like a webpage, not coordinate based like windows forms. This is ideal for scenarios when translated strings will change length (English to German for example). Under usual circumstances the ui will resize itself automatically at runtime to make it all fit.
If you just throw in controls and don't change the style of anything, your first wpf applications will look almost identical to native win32 applications. It is very easy to change this, but you will achieve great results regardless of the "look" you choose. Microsoft also provide the tools to create new ui components that look like native buttons. There are a host of other features that will make you grin while learning!
This is not a technical note, but at the moment wpf is a highly sellable skill and looks great on a cv! Companies want great branding in their apps. Wpf helps that happen.
WPF does provide the same appication look wich is the default look. When you drag and drop your controls onto the design surface (just like in windows forms, MFC ...) the controls look as you would expect them to look under the current theme. Chances are that you have seen quite some WPF applications without noticing. Just because they look like any other app.
The reason you might see more WPF based applications that have some sort of custom look and feel to them is simple because it is so much easier to do what ever you like to your GUI than in any other GUI framework on any platform. This is both blessing and curse. While you being absolutely flexible it is easy to do absolutely horrible stuff.
user440267, I believe that the most application in WPF are built using normal Windows. But there is an option which we don't create a window, instead we create a page, which behave like you think.
Related
I saw a lot of question on this topic and it took me some time to decide whether or not I would write another one ... but I think my question is a bit more complicated ... so here we go.
I'm currently working with a WPF application using MVVM.
The application is built with:
WPF
Prism V2
Ideablade (devforce) to access a database
Avalon dock for the docking feature
Telerik for the grid component
Views and ViewModel are generated with .tt file.
Views are generated in xaml (for WPF) files.
I know that:
Telerik has Silverlight controls
Using Prism V2 will probably help me doing a Silverlight version of the application
I don't know:
If the usage of devforce can be a show stopper
If the usage of avalon dock can be a show stopper
My question:
Appart from generating xaml for Silverlight ... where do I start ...
----EDIT----
Please, avoid any comments like "Silverlight will die" or "Silverlight xaml is a subset of WPF xaml".
It is a proof of concept and should be made using Silverlight. For the xaml, I can modify the application to use only simple ui element that can be both in Silverlight and WPF.
Depending on how you actually used Prism and other frameworks this can be a lot of work or quite easy.
I'd start at the 'bottom' because I'd expect the Models and ViewModels to be quite portable, at least that is what I have experienced so far. She fact that Silverlight more or less forces you to write async code everywhere might encourage you to investigate in (yet another) framework such as Rx
The Views could be quite a hassle; you will have to find controls that provide the same features that you are using in WPF, build them or invent something new. That can be a lot of work.
Another thing to consider is when your WPF app relies on many desktop features you might consider creating an Out of Browser Silverlight App.
As with any project try to find areas that will probably need a lot of attention and do those first; it's a waste of time to get a lot of stuff working to find out later that you will have to replace it because of an impossibility elsewhere.
I've seen the beautiful MetroTwit interface http://www.metrotwit.com/ ; I would like to know which WPF components have been used for trying to reproduce it.
MetroTwit designer here :)
All of the controls and animations were designed from scratch.
Obviously I drew a lot of inspiration from Zune, Windows Phone 7 but everything was re-templated from the default base styles. Most of the icons were made in Photoshop then converted into Expression Design to be output in XAML.
Since much of our design was with a Twitter client in mind, it's not universal for all applications. What you should really do is read up on the User Experience Design Guidelines for Windows Phone for a much broader understanding of Metro.
After you have a solid grasp of what you believe Metro to be, it's much easier to style the controls to the way that suits your application.
Look at http://metrotheme.codeplex.com/ and http://www.silverlight.net/content/samples/sl4/themes/cosmopolitan.html those are silverlight but you can use it in WPF with some changes
Background:
One of the most attactive feature of Silverlight is PlanProjection because of its ease of use and the stunning effect. Unfortunatelly, it is not available in WPF. I know that similar effects can be achieved using Viewport3D but certainly not with that simplicity.
The App:
I would like to build a Win app designed for dualscreen computer, a bit similar to PowerPoint: 1 fullscreen viewer window for the audience, and 1 regular window to control the app.
The problem:
Building the app in SL is not very appealing: Going to fullscreen always requires user confirmation due to (understandable) security reasons. Detecting primary/secondary screens, their positions is only possible with System.Windows.Forms.Screen class (pls, correct me if I am wrong), which is not available in SL.
The odd solution:
Would it be possible to write my controls in SL utilizing the fancy and simple PlanProjection features and reuse them within a WPF application?
If yes, what impact will I have on the installer? I assume that the installer would need to deploy both .NET framework and SL runtime.
Do you have alternative ideas to facilitate cherry-picking features from the two different worlds?
WPF has rich 3-D capabilities that are far greater than what Silverlight 4 can do so if PlanProjection is the main feature from SL that you require but want to create a desktop application then using WPF all the way would be the way to go. WPF can do everything that PlanProjection can do. Charles Petzold wrote an excellent book on WPF 3-D.
Just use Planerator : http://blogs.msdn.com/b/greg_schechter/archive/2007/10/26/enter-the-planerator-dead-simple-3d-in-wpf-with-a-stupid-name.aspx
I am very confused about WPF and Windows Forms. What is the usage of WPF over Windows Forms?
What is the usage of WPF?
WPF is a new platform for developing applications for Windows (and for browsers). WPF is not necessarily there to replace Windows Forms. With WPF, it is easier to add 3D, video, and animations to your application. Because it is XAML based, it is also easy to bind to XML data, for example, data from a webservice, and dynamically load it as content.
WPF also, in my opinion, better seperates the UI programming from the business logic. It is easier to have an advanced WPF designer build your UI with a tool like Expression Blend, and yourself as a programmer, focus more on the back-end. In that way, it is more like having an HTML and CSS frontender creating a slick design for your site, while you work on the back-end.
Windows Forms has (as for now) more third-party controls available though, and if you don't really have a need for the stuff that WPF brings, then you certainly don't have to switch to WPF.
Have you seen WPF or WinForms, choose wisely ?
In short, WPF is the next UI platform for Microsoft Windows. It learns a lot of lessons from previous technologies, but the risk is immaturity of tooling and third-party components.
One benefit is the separation of concerns. You can build your application without worrying too much about UI stuff like layout, colours, fonts, etc. Then you can pass it to a designer who can make it look amazing (hopefully) without needing to understand code (using Blend or some other tool).
From a purely pragmatic point of view, my choice of which framework to employ is often down to which third-party controls I need to use (although you can use a WPF control in a WinForms app, for example - using hosting controls).
One more thing I like about WPF is that the core graphics processing has been shifted from GDI+ to DirectX. That makes a huge performance benefit when you are working on 3D or heavy grid/time series plotters as it tries to consume your GPU (graphical) resources rather than CPU.
I just installed visio, and the installer almost seemed like it was built in flash.
The buttons kinda glowed when I hovered over them, and when I clicked on 'continue' the form phased out in a cool way.
I'm assuming it was built in WPF.
Anyhow, so are WPF more flash-like (visually speaking).
Do they have new properties where you can make forms phase out nicely/smoothly compared to winforms?
Disclaimer: I work for Microsoft. However, I don't work on Visio, WPF, CLR or Silverlight team. So, the following is my personal take on these technologies. If you want to quote me, don't do it implying it's the official Microsoft position. :-))
Update: Anything I say below about Flash/Flex/AIR might be wrong, as I have not worked with these technologies and what I know about them is based on what I read on the intertubes. :-) If you notice anything wrong, just shout in the comment and I'll correct it.
To the best of my knowledge, the Visio installer is not built with WPF. It's all unmanaged code; it's just people took a lot of care to make it really polished.
WPF is the new UI platform for building standalone applications for the Windows OS. It supports a declarative UI language - XAML, and related CLR types to program against. WPF is a different platform than WinForms, although it is possible to build applications that mix UI built with both. WPF supports a lot of things that WinForms does not, like bitmap effects, animations, control styling and so on and exposes them both in XAML or through code. Also, WPF relies heavily on vector graphics, as opposed to the pixel graphics in WinForms. In short, WPF is quite powerfull and allows building very snazzy UI. (Don't take my word for it, though, as I am biased; go check around for what people are saying about it or buiding with it. :-))
WPF and WinForms do not compete with Flash/Flex. WPF and WinForms are both UI frameworks for building standalone client applications. As far as I know, Flash/Flex are frameworks for building rich internet applications - RIA (though lately people started interpreting this abbreviation as rich interactive applications).
Adobe did come up with AIR about half a year (or maybe a year) ago, which allows building standalone client applications, so you could say that Adobe is trying to position Flash/Flex/AIR to compete with WPF. Of course, that's my take on it and I doubt Adobe's official positiong is anything like that.
If you want to compare particular MS technnologies with Flash/Flex, take a look at Silverlight - it's the MS RIA platform.
Silverlight is related to WPF in the sense that they share XAML and the corresponding CLR types. Silverlight supports only a subset of what WPF offers, though, as it is not targeting Windows OS only and thus is limited by the fact that it has to be portable.
Quick update to reflect the changes in the year since I've written the answer :-)
With Silverlight 3 shipped, SL and WPF are getting even closer and sharing bigger set of supported features. In addition, most of the new XAML controls are built for platform at the same time. Thus, SL/WPF are getting to a point of singularity...
Also, SL 3 supports out-of-browser applications. In that sense, SL is not only starting to compete with Flash/Flex, but it is also encroaching on AIR's turf.
And no, I still don't work on the WPF or Silverlight team. :-)
WPF is being used as a replacement for WinForms, and as a competitor to Flash in the form of Silverlight. WPF consists of an entirely new object model that sits on top of DirectX (at least the desktop version). You can create WPF windows, controls, etc, entirely using C# or another .Net language just like you can render WinForms. However, Microsoft has also created a markup language called XAML (eXensible Application Markup Language). Nodes in an XAML document (XML) map to objects in a similar fashion to the way ASP.Net maps to web controls. XAML typically exists in a .Net project alongside a code-behind style C# file (or VB.Net or whatever). The C# file interacts with the objects generated by the XAML. This is fairly consistent with the "graphics via markup, logic via code" model that Microsoft and others are pushing.
One of the overlooked features when discussing WPF is the completely awesome data-binding that Microsoft wrote for WPF. The new data binding framework is a quantum leap beyond Windows Forms 2.0 data-binding. Microsoft added a couple of new interfaces that make it much easier to make an object or collection emit data-biding events properly. They also provided a very rich set of data-binding classes. You can bind anything to just about anything else. You can bind one-way data to control, control to data, two-way control to data and back, control to control, etc.
Back on the graphics side of the house, WPF makes it fairly easy to make an existing control look like anything. WP lets you compose your own template for what a class of buttons should look like, or one button, or all buttons. Or radio buttons. Or labels. You get my drift. Imagine if CSS included the ability to define what an input button would look like using other HTML controls.
They also provide a number of layout controls. You can continue to use exact positioning like in WinForms, or you can leverage of variety of techniques to make your window act more like a web page that grows and shrinks with resizing, etc.
The downsides: It is too easy to create spectacular effects that crawl on slower machines. Some of the graphics do not take advantage of hardware of graphics cards, though Microsoft has incrementally improved support for this. I believe when 3.0 first came out drop shadows were rendered purely using software. I think 3.5 or 3.5 SP1 changed it so that WPF would utilize graphics hardware for the task. Microsoft has said they will continue to enhance WPF in this fashion.
WPF is .Net 3.0 and above, which runs on XP SP2, Vista, and Servers 03 & 08. So don't plan on deploying WPF to a customer with Win2k desktops.
Summary: If you are doing desktop programming in .Net, you should be doing it in WPF unless you are targeting Win2k. You can avoid the downsides of WPF, and there are many upsides. Microsoft will probably throw away WinForms in some future release, or at very least you will stop seeing new features, etc.
As far as Silverlight goes, the betas for SL 2.0 look good. I think that Silverlight will require some wide-spread adoption. Microsoft has already tried to get this going. The NBC Olypmics site used Silverlight, and Major League Baseball uses it for its MLB.tv product. As soon as Silverlight gets a good install base I think you will see the Microsoft side of the development world starting swinging away from Flash and to Silverlight.
Edit after using Silverlight 3 and MVVM:
I have moved away from WPF and am doing a lot of Silverlight 3 development. But I think my comments here will still apply to the WPF developer.
I have been using the MVVM pattern in my app (think MVC with a twist). The Microsoft Patterns and Practices team has released a set of libraries known as Prism that supports various aspects of MVVM. There are WPF and Silverlight versions. Take a look at MVVM and Prism if you are going to be doing WPF or Silverlight development.
You can do a lot of flash w/ Winforms, or with custom components. But if you want out-of-the-box bang-whizz availability, WPF is the way to go.
Yeah, I think the intention is to be flash-like, it seems to me that MS has set its sights on taking down Adobe.
The way I see it: WPF is to Flash as WinForms is to Flex. WPF has more emphasis on vectors and states than on programming.