Username or EmailPassword
It starts to load & render, then:
Windows Internet Explorer
Internet Explorer cannot open the Internet site http://www.informit.com/articles/article.asp?p=676359&seqNum=1&rl=1...
Then 404s out.
Works for me but you could try a slight variation I guess
Quote: "One of the four foundations in .NET 3.0 is the Windows Presentation Foundation (WPF), an overhaul of the presentation interface of all Windows applications. "
That does not make any sense. If it is .NET 3.0 it can't be the basic interface of all windows applications.
Can anyone explain what Windowms presentation Foundation) actuelly is?
1: Is it yet an other .net graphics/widget framework, which then does call gdi/Win32 to draw with windows?
2: It it a new native gfx library for windows(Avalon???) which also have a .net binding?
3: Something else??
Good questions. Vista will have native APIs for the new graphics engine, but I'm not sure what that means for XP since XP gets .NET 3.0/WPF. I'm thinking it will get the native APIs too, since I recall that some Microsoft guys were talking to the Mozilla folks about using WPF.
As far as I know, there is no public native API for WPF. There is a private one implemented in milcore.dll for use from .NET, though.
What is WPF?
It's a vector-based drawing engine that also includes support for video and rasterized images of various formats. There's also support for animation and lightweight 3D. I believe they also wrote a new text display engine for it. Right now it's only accessible through .NET and there are plans for a non-.NET API for the next version.
Here are the answers as I know them anyways.
1. It is a new .NET System.Windows.Forms, but also is much more. It's a GDI replacement. It is hardware accelerated (renders via your GPU if you have one via DirectX). It is vector based. It also has 3D capabilities.
Think Flash but HW Accelerated. But in addition its the new graphics engine for Vista. But since its a graphics library ontop of DirectX, it runs on XP as well.
2. Yes this is what has been called as Avalon. It's core technology is based on XAML. WPF/E is just a limited subset of WPF/Avalon which is going to be a smaller version for websites, mobile devices etc.
A minor correction #2: XAML isn't a core technology WPF is based on; its the other way around. XAML is comparable to "Glade" (GTK+) that can, although its not necessary to do so, be used to construct graphical UIs in WPF, much in the same way GTK+ and Glade go together.
Its possible to create the UI using code and no mark-up in WPF, but of course it limits your ability to let a designer (the people kind) work on the UI while you wire up the events and work on the back-end.
You're right about the second part, there was quite a good show on the channel 9 MSDN show, which showed one of the more cooler aspects, which is, to allow those who may not be able to programme, but know about user interface design and layout to create the front end whilst allowing the engineers to work behind the scenes on the engine that runs the whole application.
Having had a look at Office; it appears that is what they've done with Office 2007, given that its whole interface is written using Winforms 2.0 and its UI is customisable via XML files.
With more information being released, it tempts me more to move from Fedora to Windows Vista along with Office 2007 - I wouldn't have said this, but given the positive experience I had with RC2 (and post builds) on my laptop, it appears that it'll be a good release for all concerned (except maybe competition who will be playing catchup).
Yup I agree.
The legacy way of doing UI where they describe the whole:
1. Designer creates cool slick UI and passes the JPG/PSD off to developer.
2. Developer finds doing those UI effects too cumbersome so discusses with UI designer to compromise.
3. UI is developed via code & GDI, skipping alot of rich UI because its too time consuming to code.
Is now turned into variations of the following procedures:
1. Designer designs up mockups.
2. Designer after narrowing down a candidate, opens the applications solution file, creates the UI and UI events.
3. Developer opens solution file and puts the implementation code into those UI events.
1. Designer designs up mockups.
2. Developer whips up a quick UI implementing the functions etc.
3. Designer restyles the UI properly via templating etc and reworks the UI and maintains the existing code behind the UI and is able to see his results in a real working application.
Any developer or designer who works with UI can for sure see the great qualities in this work flow. No longer are such brutal compromises required, the designer can now make his ideas and thoughts happen. Also the developer doesn't have to deal with UI. Ontop they share the same build system.
Office is not written in Winforms, as far as I know. Office has always had their own forms implementation (off of which WinForms seems to have been later based). Office apps are hardcore, native applications (at least the three main ones) with bindings to .NET and their own owner-drawn control infrastructure all wrapped up in COM.
It is this way because Office wants to be independent of as many features of Windows as possible (so that it can run on all versions) and because they want it to load fast, which wouldn't happen if it had to pull in the .NET execution engine when starting up.
You do realise that you can mix native and managed code together within a sigle project; it is actually possibly to have the GUI written in Winforms, which would actually give Microsoft a much better ability to provide cross platform compatibility - given that they're only supporting Windows XP and Vista on Office 2007 anyway.
One thinks that you need to research the MSDN site on how one can mix code, and how one can write applications that can easily span Windows XP and Vista without needing to use ugly hacks and workarounds.
Here's a good source of info:
WPF is a new managed (C#) graphics API which would theoretically allow you to replace the aging native USER/GDI Win32 APIs. WPF is built from a combination of managed (C#) and native code (C++); although there is no native API exposed. WPF is designed to provide graphics hardware-acceleration to application developers but, unlike GDI, WPF leverages the latest features of graphics card GPUs (ie. pixel shaders, etc), ClearType, anti-aliased primitives & text, integration with Vista's new Desktop Window Manager (DWM), animation/timing, and remoting.
Using Terminal Server, GDI apps are pretty dumb. Some limited number of primitives are remoted over the wire but, most of the time, blocks of pixels are sent. WPF apps remote a much wider range of primitives, which permits far more efficient utilization of network bandwidth. Also, it makes it much easier to run rich content (ie. containing animations, etc) on a client without degrading quality and skipping frames.
WPF contains several elements ...
1. XAML - an XML-based markup language that allows developers to specify layout. Like HTML, XAML can specify either fixed or flow layouts. You can also supply resources (ie. images, etc) and code-behind which manipulates the GUI and does other app functions -- and then "compile" the resulting XAML into an executable "package".
2. Controls Framework - (managed code) Buttons, Images, Lists, 2D/3D drawings and primitives, etc. Supports theming, data binding, animation/timing, etc.
3. Core Components - (managed code) These are the managed building blocks that the Controls are built on top of.
4. Native Code - This layer interfaces managed code with the hardware via DirectX/D3D.
Microsoft has a new tool (Microsoft Expression) that allows you to edit XAML. Like Flash, it has timeline semantics and allows you to specify actions that are performed at discrete points in time, as well as handle fired events (button clicks, etc). So, you can not only create Flash-like animations but also full-blown WPF-based applications that are hardware accelerated. Microsoft also offers an option to work with XAML in the latest version of MS Developer Studio, albeit at a much lower level.
WPF apps run in one of two security modes: Partial-trust and Full-trust. For example, apps downloaded from the Web run in partial-trust. What this means is that they can't access the filesystem, open network connections, and do many other things because they're running in a sandbox. Full-trust apps are no different from any other app running on a local machine. Note: Full-trust does not mean that the app is given full admin privileges. The apps run with whatever privileges the current user has on the local machine.
Hope that helps.
WPF sounds like a cool idea. The problem is the .NET requirement, which has been a deal breaker for my company all along (we sell downloads as well as boxed consumer titles and .NET has no relevance to that.)
Vista may change things in 3 or 4 years if it manages enough of a market to be worth selling to and WPF is still around by then. Sort of like all the new OSX technology, except that new Apple OS's tend to be much, much more quickly adopted.
Meanwhile, do I buy into a language and UI framework I despise (C# and .NET) to make pretty programs I can't sell, in hopes that it will become viable soon and I'll be ready? I'd make more by moving to OSX now, with the bonus of a framework and preferred language that are the industry best rather than the worst, and are really no more OS specific than .NET? (okay, Interface Builder sucks rocks even compared to Visual Studio's UI designer, but I don't use either very often.)
Yes, WPF requires .NET, but this isn't quite as bad as you make it out to be. Assuming your software is "shrinkwrap," you can bundle the .NET Runtime installation package with your installer and install it if it isn't already present.
Furthermore, a version of WPF runs on Windows XP, so you can include the .NET 3.0 Runtime installer with your program, which will install both the .NET Runtime and WPF, simplifying installation.
The downside is that this doesn't help with downloadable apps (the .NET Runtime installer is ~20MB, iirc), and WPF on Windows XP doesn't support all the "bells and whistles" that it does on Vista.
"The downside is that this doesn't help with downloadable apps (the .NET Runtime installer is ~20MB, iirc), and WPF on Windows XP doesn't support all the "bells and whistles" that it does on Vista."
If you have to ship a copy of .NET with your downloadable product, I would recommend .NET 3.0: it comes in the form of a web-based downloader, so the overhead is a measly ~3 megs for the initial download. The web installer will grab whatever files are needed to get .NET up and running on that machine in the background; its a pretty fast process.
I think this method would be more preferable, since the user is less likely to abandon the download in progress -- this is my personal opinion but I think the "novice" users are more willing to wait for an installation to finish than a download to finish.
True, and if you merge it into your installation process rather than it being a seperate step, you'll find that most end users will sit there, realise that its gotta gonna take a while, so off they go for a coffee
But how can gdi and wpf live side by side in windows XP?
I mean, a gdi window, and a wpf window need to know each other so they can send correct redraw and input events, and so on. So is there something below gdi, og do gdi and wpf just talk to each other?
(Or is wpf actuelly implemented with gdi calls. That what I would have done :}
Well how does DirectX exist along side GDI? I'm sure alot of the same signalling is shared but how it renders is totally different.
Ever see a DirectX game windowed? I imagine its not much different than that except that it handles all the compatibility and signalling.