Request for Feedback (WPF VNext)

So have you tried out .NET 4. If not, do give it a try. We have a bunch of new WPF features in .NET 4 and it was covered as part of the WPF features series. Now that we are close to release, whats next. This is where your feedback is invaluable. We listened to your feedback from 3.5 and incorporated several suggestions into .NET 4. Now its again time to ask for feedback to drive the direction for the next release. We would love to hear your comments\opinions on the following areas     

·        What are the features you would like to see in vnext of WPF? You can also vote for your features here.

·        How can we improve the curve in learning WPF? Are there things we can simplify?

·        Feedback on tooling support (IDE, Loc, Designers, perf tools,..)  

·        What do you think of the community support for WPF developers? Can we do better?

·        I have seen some posts expressing reservations adopting WPF (e.g. especially when coming from a Winforms background). In general, what hiccups\reservations (if any) do you (your team) have adopting WPF?

·        Any learnings\experiences adopting\using WPF

·        Any random feedback not covered by the above J


Send in your feedback. We are all ears J


Share this post

Comments (17)

  1. shaggygi says:

    I believe the biggest request is controls.  I would like to see the same controls ported and released that are included in the Silverlight Toolkit.  Also, get the controls added to WPF that are in WinForms (e.g. DataGridView ).  Love to see a Dock Manager included like the one in VS2010.  Thanks a bunch:)

  2. Robert says:

    Somewhat prioritized:

    Further improve cold startup. This is a major pain point.

    Reduce the need to write an insane amount of converters (expressions in binding, maybe?)

    Stop treating binding errors as warnings and throw an exception (major breaking change)

    Make it easier to bind to a property in the codebehind, maybe some syntactic sugar for ‘this’

    Intellisense for xaml bindings where applicable (Resources)

    Stop using App.xaml/StartupUri in the WPF project template, use a proper program.cs instead. Any non-trivial program will want to do stuff before launching the main window. Encourages bad code.

    Fix design-time merging of ResourceDictionaries in Cider so we don’t have to repeat the same Dictionary everywhere just to have something show up in the designer.

    A usable designer (one of the motivations for xaml in the first place, right?).

    Sorry about the long list, I couldn’t help myself. I’ve been working with WPF a lot lately.

  3. Joe says:

    Improve localization. the locabaml tool doesnt work and this should  be supported in VS.

    Also XAML 2009 features should be supported in compilers

    Better performance

  4. Thomas Levesque says:

    WPF 4.0 is pretty good, the new controls come in handy, and I especially love the fact that InputBinding.Command is now a dependency property, which makes things much easier when using the MVVM pattern.

    A few things I’d like to see in the next WPF release :

    – better support for MVVM. For instance, a built-in way to bind events to ViewModel commands

    – better designer in VS ; it almost never does what I actually want it to do, so I almost always resort to writing XAML manually. For instance, the design-time docking behavior should depend on the container : when I drag a control to a Grid, I expect it to "dock" in one of the grid cells, not to place itself in some arbitrary absolute position. In a DockingPanel, it should dock to the nearest border or fill the whole area (like document windows in VS)

    – Fix that annoying bug : when you use a custom markup extension, it breaks the designer if the ME is defined in the same assembly

    – Improve localization ! LocBaml is the worst localization tool ever : very tedious to use, lots of manual steps, you have to modify the XAML to add x:Uid tags, and so on… Why can’t it be as easy as it was in Windows Forms ? I ended up coding my own localization lib, using .resx files (which should definitely be the "official" localization technique, as it was in Windows Forms and ASP.NET). The following article contains some interesting ideas about localization using various techniques (markup extensions, attached properties…)

    – Make it easier to navigate the visual/logical trees : perhaps some extension methods on DependencyObject to find an ancestor of a given type, or enumerate all children (can be done by anyone, but it would be nice to have it built-in)

    – I second Robert’s ideas about expressions in bindings, and a "real" program entry point (Main method)

    WPF is a really cool product, but it still needs improvements to reach the same productivity level as Windows Forms

  5. I know this suggestion is radical, nonetheless…

    Re-architect Silverlight/WPF/XAML to use the DLR as it’s foundation. Thus allowing binding expressions, the elimination of ValueConverters and DependencyObjects / Dependency Properties.

    Current binding is tedious, verbose, and almost always requires the extra dependency of a ValueConverter. Dependency properties are a ridiculous hack.

    For cripe’s sake it’s 2010 already! Must we continue to suffer from the nuiances and idiosyncracies of a staticly-typed system? Let’s get with the times!

  6. John says:

    Provide better perf tools.

    Have a simple notation than XAML. Agree with THomas  -loc is a mess

  7. Aenyo says:

    Make is easier to port controls from different platforms. Better webcam support. Better design tools

  8. MF says:

    I agree with porting more of the controls that existed in Winforms to WPF. So that we can port our existing apps to WPF. Most specifically NumericUpDown (i know there are some free ones around but none of them are complete)

  9. My request involved the CLR and WPF/SL.

    I would like to be able to  make "Binding" on Interface property.

    Example : I Have a list of IPerson.

    I want to be able to bind a TextBox.Text property on IPerson.FirstName.


  10. beaugrand says:

    It seems that there are no good solution in WPF to migrate projects using virtalized listviews in thumbail mode.

    We just have a Virtalized StackPanel, that’s good, but we need a Virtalized Wrap panel for a lot of projects !  

    So please, please… make a good one (with good keyboard navigation)

  11. Fred says:

    don’t redo the terrible mistake you did with ASP.NET:

    document the background of WPF technology and publish some true good practiced sample. Not the one we have in the today’s documentation.

  12. Jonathan Weizman says:

    WPF is great but:

    *Extremely non user friendly to install

    *Slow to start

    *Can be improved on perf

    But the 2 first one are killing it

  13. Jack Ukleja says:

    * Take a serious look at the pain of implementing the observer pattern (INotifyPropertyChanged etc). There needs to be some compiler work here, or some other clever code generation from models etc to make all this plumbing simpler. Surely the DLR fits in here somewhere? – DependencyObject, Attached properties etc is to some extent trying to make a dynamic system out of a static one. Creating DPs is still pretty crude

    * Performance still needs to be improved. It still shocks me sometimes how bad the performance is for lots of things in WPF (considering the power of modern PCs). The worst things is its actually incredibly difficult working out where the bottlenecks are in WPF, especially once things leave managed code. Yes we have some WPF perf tools but I still think they are very limited, with not enough drilldown (WPFPerf.exe) or not approachable enough (like GPUView). Perf tools need to be continously improved. For the real hardcore stuff there is very little in way of understanding perf inside GPU, eg. texture loading, fill rate etc.

    * Some examples of perf improvments would be getting animations off the UI-thread as I hear they have done for Silverlight on WP7. There was also talk a few years back about having animations that could run independantly on the render thread. Allow us to use all those extra cores effectively.

  14. Please make sure that you keep WPF in sync with new features of Silverlight.  We all know that they are trending towards a unified platform in the future.  However in the meantime, control vendors like us have to develop separate codebases, each of which are sometimes forced to have different features.  

    For instance, Silverlight has the neat plane projection feature but that’s nowhere to be found in WPF so there’s no way we can write code for a 3-D UI control that can be used on both platforms.  I know we could do a full-blown 3D environment in WPF but a lot of times we want to keep things simple and just plane project a visual.

    There is a lot of momentum and innovation going on in Silverlight.  We really need the WPF platform to keep up.  Keep up the great work, we love where the platforms are going!

  15. Paulus says:

    Hi Lester,

    Here is my list:

    controls: Numeric up/down, Dataform, Accordion, Chart

    features: Autohide capability (see Toolbox in Visual Studio), Dock manager (see Visual Studio)

    themes: officialize those of Codeplex/WPF

    print: UIElement print capability (see Silverlight)

    quality control: still too many bugs in Datagrid .NET 4 considering it has been around for so long on Codeplex/WPF

    xaml syntax: suppress explicit reference to another project (dll) Use the project reference information like C# does (today : both must be synchronized manually)

    memory leakage: improve clarity of recommendations on how to avoid ML by publishing some solid guidelines (everyone has some hints nowadays: Codeplex, VS2010 lately, etc., etc.). This concern is one of the bigger topics about the ‘reservation’ to adopt WPF and could be solved just by a qualitative documentation effort.

    For future versions/products:

    Generally, WPF shines in its capability to extend controls: to be carried forward.

    To alleviate performance bottlenecks, provide parallel capabilities beyond those presently available.

    Thanks for your excellent work,


  16. We are using WPF for digital signage. The usage of one gui-thread block us in showing properly scrolling marquee text together with alternating videos and pictures. Loading a picture e.g. will block the effect of the scrolling text. We want to be able to run a control in its own thread independent of the gui-thread.

    Another annoying issue is the so-called "Airspace" problem. We cannot properly integrate eg the webbrowser into our pages.

    Make a better business case for WPF and put WPF at least at par with Silverlight. Maybe swap the product managers.

  17. Drone#7 says:

    Please give us the ability to disable the pre-multiplication by alpha of colour data in bitmaps with alpha data in them. I can understand the general need to follow a consistent method throughout the UI with alpha, but e.g. when the user knows that a specific bitmap is only ever going to be processed by their own custom pixel shader, the data should be able to be passed into the shader without any pre-processing if required. The user can easily handle the alpha calculations in the shader if they need to. This is the whole point of using pixel shaders.

Skip to main content