[ACCEPTED]-WPF without XAML-declarative

I support you in Xaml-free WPF. I love layout 7 and binding capabilities of WPF but I hate 6 XAML too. I would love that WPF could be 5 written in plain C#, some advantages:

• Object and Collection initializers could replace Xaml instantiations. (it's a pity that xaml prefers top-down than button up).
• Binding converters could be just lambdas.
• Styles could be just lambdas that modify an object after instantiation, no bloated <Setter> syntax.
• DataTemplates would be just lambdas that create controls given an object
• DataTemplateSelectors would be just a DataTemplate lambda that calls other DataTemplates.
• ItemsControl Would be just a Foreach that takes a lambda (DataTemplate) and calls it again if a new item is added to the underlying collection.
• x:Names would be just variable names.
• No need for many MarkupExtensions
  • x:Static
  • x:Type (specially with complex generics too!)
• UserControls would be just functions.

I think 4 way too much complexity was added to WPF 3 to allow it to be designed. Web development 2 has already lost this battle from the old 1 days of FrontPage to Razor.

Simplifying? No. But everything you can 22 do in XAML you can just do in code. For 21 example, here's a simple Windows Ink drawing 20 app - pretty much as simple as you could 19 possibly make it:

No saving, no changing 18 anything - but you can through code.

Sketchpad.cs

using System;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Media;
using System.Windows.Ink;

public class Sketchpad : Application {

    [STAThread]
    public static void Main(){
        var app = new Sketchpad();
        Window root = new Window();
        InkCanvas inkCanvas1 = new InkCanvas();

        root.Title = "Skortchpard";

        root.ResizeMode = ResizeMode.CanResizeWithGrip;
        inkCanvas1.Background = Brushes.DarkSlateBlue;
        inkCanvas1.DefaultDrawingAttributes.Color = Colors.SpringGreen;
        inkCanvas1.DefaultDrawingAttributes.Height = 10;
        inkCanvas1.DefaultDrawingAttributes.Width = 10;

        root.Content = inkCanvas1;
        root.Show();
        app.MainWindow = root;
        app.Run();
    }

}

Sketchpad.csproj

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="15.0">
  <PropertyGroup>
    <AssemblyName>Simply Sketch</AssemblyName>
    <OutputPath>Bin\</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Xml" />
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System.Core" />
    <Reference Include="System.Xml.Linq" />
    <Reference Include="System.Data.DataSetExtensions" />
    <Reference Include="System.Net.Http" />
    <Reference Include="System.Xaml">
      <RequiredTargetFramework>4.0</RequiredTargetFramework>
    </Reference>
    <Reference Include="WindowsBase" />
    <Reference Include="PresentationCore" />
    <Reference Include="PresentationFramework" />
  </ItemGroup>
  <ItemGroup>
    <Compile Include="SketchPad.cs" />
  </ItemGroup>
  <Target Name="Build" Inputs="@(Compile)" Outputs="$(OutputPath)$(AssemblyName).exe">
    <MakeDir Directories="$(OutputPath)" Condition="!Exists('$(OutputPath)')" />
    <Csc Sources="@(Compile)" OutputAssembly="$(OutputPath)$(AssemblyName).exe" />
  </Target>
    <Target Name="Clean">
    <Delete Files="$(OutputPath)$(AssemblyName).exe" />
  </Target>
  <Target Name="Rebuild" DependsOnTargets="Clean;Build" />
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

That's 17 all it takes. Granted, if you want to avoid 16 XAML, that basically means you're going 15 to have to write a bunch of alternate .NET 14 code, so it's kind of up to you - do you 13 want to dump of that stuff in XAML, or would 12 you rather write it in code?

I think the 11 biggest benefit to doing it within VS is 10 you get good designer support so it's typically 9 pretty easy to visually see where everything 8 is and goes. It's also probably less looking 7 up the documentation and sometimes having 6 to make a few leaps.

But WPF without XAML 5 is possible.

You don't even need Visual Studio installed 4 for this, just the .NET CLI and the Developer 3 Command Prompt. Drop these two files in 2 a folder and run msbuild and then you can run the 1 file in the Bin directory.

This question definitely needs a link to 7 the Bling UI Toolkit. It's a super-genius high-level library 6 for animation and rich UI prototyping on 5 top of WPF. Binding with button.Width = 100 - slider.Value, animation like 4 this: button.Left.Animate().Duration(500).To = label.Right, a pixel shader compiler - amazing.

Sadly, I 3 don't think the project is being worked 2 on anymore. But lots of very smart ideas 1 to give some food for thought.

There are no frameworks like this for WPF. The 22 three things that you mention in your wishlist 21 would be direct (and different) replacements 20 for the components already provided by WPF. Also, replacing 19 the binding and resource systems with your 18 versions would make the things you like 17 about WPF (animation, templating, etc.) unusable 16 as they rely heavily on the binding, resources, etc.

Here 15 are some suggestions that may improve your 14 experience.
1. Learn to deal with XAML (I 13 used to hate its guts too, but now that 12 I'm used to it its great)
2. Build your 11 own library that makes creation of the UI 10 easy for you, in code. After all, everything 9 that is done in XAML can be done in code 8 just as well.
3. If you really hate INotifyPropertyChanged, and 7 want a callback instead use a DependencyProperty 6 instead. No event for you to raise, and 5 you can have a callback and default values!
4.) Don't 4 use WPF. Even though you say you love the 3 architecture, your list of shortcomings 2 / desired 'improvements' covers almost all 1 of it.

> non-INotifyPropertyChanged binding.

To manually implement INotifyPropertyChanged in your viewmodell or modell is quite 20 a lot of manual/repitative work. However 19 I read about these alternatives

• DynamicViewModel: MVVM using POCOs with .NET 4.0 :This project aims 18 to provide a way to implement the Model 17 View ViewModel (MVVM) architectural pattern 16 using Plain Old CLR Objects (POCOs) while 15 taking full advantage of .NET 4.0 DynamicObject 14 Class. Taking advantage of the .NET 4.0 13 and the DynamicObject Class, we can create 12 a type deriving from the DynamicObject Class 11 and specify dynamic behavior at run time. Furthermore, we 10 can implement the INotifyPropertyChanged 9 Interface on the derived type making it 8 a good candidate for Data Binding.

• Update Controls .NET : WPF 7 and Silverlight data binding without INotifyPropertyChanged. It 6 discovers dependencies automatically so 5 you don't have to manage them in your View 4 Model. And it works with Winforms. Bind 3 through code using events.

• notifypropertyweaver : Uses IL weaving 2 (via http://www.mono-project.com/Cecil) to inject INotifyPropertyChanged 1 code into properties.

  • No attributes required
  • No references required
  • No base class required
  • Supports .net 3.5, .net 4, Silverlight 3, Silverlight 4 and Windows Phone 7
  • Supports client profile mode