[WIP] Proposal of Community-driven Tooling Roadmap Around LibreWPF

[lextm]

Goals

Microsoft doesn't publish an up-to-date roadmap for WPF, but there are a lot of new things now in the XAML landscape. So, upon ProGPU and your open source fork a new roadmap can be developed to engage with the wider community and move the entire ecosystem (open source/commercial controls and tooling) forward.

Core Assets

• ProGPU
• LibreWPF

@wieslawsoltes owns the detailed roadmap of both.

Ecosystem

Community engagement has started and more people can involve to build up the ecosystem around the core assets.

Beyond the main repos (ProGPU and LibraWPF):

• Improve DevFlow for WPF to work with LibreWPF

  Done by @lextm.

• Bring WpfDesigner to LibreWPF

  Done as part of vscode-wpf and OpenDevelop @lextm

• Improve vscode-wpf to work with LibreWPF so that developers can use VS Code as their primary development environment on macOS/Linux.

  Done, but superseded by OpenDevelop. @lextm

• Bring AvalonEdit to LibreWPF

  Done as part of OpenDevelop @lextm

• Bring AvalonDock to LibreWPF.

  Mostly done on macOS. Linux is pending.

• Bring SharpDevelop to run on LibreWPF and modernize it with VS open source components. Then this OpenDevelop project can supersede vscode-wpf and become the new default environment for cross-platform development.

  Mostly done. @lextm

• Other cross-platform tooling support, such as Hot Reload, DevTools, profiling, etc.

Future Items On the Radar

• Native AOT

  You invested a lot of time in this area with your previous projects, so I think once the compatibility goal is reached, you will shift your focus on deprecating WPF old designs and create new ones friendly to Native AOT. For example, mark the WPF DataGrid as deprecated and ship a WPF port of ProDataGrid instead.

• AXSG and WXSG both contain WPF language servers. Need to merge them into a single one.

  @lextm will rebase WXSG onto the latest AXSG to merge the changes and then use this language server in vscode-wpf and OpenDevelop).

• WXSG brings new XAML features to Microsoft WPF (.NET Framework and .NET). However, if LibreWPF evolves further and gains enough momentum to become the primary platform, then such features should be implemented directly in the main repo instead of being added via a tooling extension.

  WXSG can remain for .NET Framework projects as well as .NET projects that aren't ready to migrate to LibreWPF. @lextm

• Windows P/Invoke helper. Another WPF fork (it might be open-sourced soon) seems to ship better shims to help migrate WPF projects with specific P/Invoke calls to macOS and Linux. Merging the best parts of both WPF forks should significantly improve the developer experience.

  Will invite its author to participate in discussions once that repo goes public.

• Wine Mono might use LibreWPF as the foundation of their WPF-related work.

  @madewokherd can evaluate and decide those tasks separately.

[wieslawsoltes]

Current focus is to release first alpha/preview version of WPF on top of ProGPU allow users to test, next is continue working on stability, performance. Roadmap is planned after first getting some stability. As for name I am planning to use LibreWPF for now, will see how it goes.

[wieslawsoltes]

@lextm Please also note ProGPU is main priority, WPF on top of ProGPU is second priority, it purpose is to drive perf/quality for development of ProGPU.

[lextm]

@wieslawsoltes thanks for the comments. I updated the contents above to reflect your ownership of the core assets (ProGPU and LibreWPF), and possible community contributions from separate repos and projects.

I think even in the current state (building from source code) those two projects are already showing great potential, so look forward to seeing what comes next.

[wieslawsoltes]

@wieslawsoltes thanks for the comments. I updated the contents above to reflect your ownership of the core assets (ProGPU and LibreWPF), and possible community contributions from separate repos and projects.

I think even in the current state (building from source code) those two projects are already showing great potential, so look forward to seeing what comes next.

I am working on packaging and should release early alpha previews so people can actually try it out. Lots of work left to make it stable but better to ship fast and test.

[AbdalaMask]

I'm excited about this project and it would be best if I released my own version. net10

[wieslawsoltes]

Status audit (2026-07-15): this roadmap remains active and should stay open.

Shipped foundation:

• LibreWPF has an immutable preview release line; the current published release is 0.1.0-preview.16 at exact commit e6eba2fac3e841e91f8870ed7886d7b18649ff9a.
• ProGPU-backed package-mode SDK validation, cross-platform WPF Gallery coverage, OpenDevelop/WpfDesigner/AvalonEdit integration work, and the macOS AvalonDock/SharpDevelop lanes are now concrete rather than proposal-only.
• Upstream WPF provenance is documented by 86296793e199279f7cae83bff7c2046b1ffce66b.

Still open:

• Linux AvalonDock parity and unchanged SharpDevelop completion, including both WPF and WinForms designers.
• Hot Reload, DevTools, profiling, and broader cross-platform tooling.
• Native AOT direction and any associated control replacements.
• AXSG/WXSG language-server convergence and the other ecosystem items listed above.

The existing documentation and enhancement labels remain appropriate. I am leaving this issue open as the umbrella community roadmap and will record further completed milestones with exact commits/releases.

[wieslawsoltes]

SharpDevelop/LibreWPF milestone update (2026-07-16): the two concrete shell regressions from the current acceptance pass are fixed and verified on the pushed development branches.

Implementation:

• LibreWPF 702d5e3347186993c872ebb72cbdeaccb9da9a42 schedules portable popup settled-position correction at DispatcherPriority.Loaded, after menu layout coheres. This removes the visible main-menu offset/flash that previously moved a SharpDevelop menu through a transient negative Y position.
• SharpDevelop 0ab57458fba3e09ab9b357aa128d95c52374549c gates real hosted Project Explorer double-click routing and verifies that an item opens through the unchanged workbench path.
• SharpDevelop 3c32821aa32aec6f489e0e4d4baa077f774f0343 replaces the Windows-only URLMON binary-type probe so Project Explorer file opening works on the portable host without a platform-specific COM dependency.

Live acceptance evidence:

• Main menu settled at (10,26) without the former negative-Y transient; context menu (42,98), ComboBox dropdown (8,218), and toolbar dropdown (408,218) also passed.
• Project Browser reported hit=True, input down/up sequences 1,2, doubles=2, and opened=True for Cut.png; the process exited normally.
• No SharpDevelop process or launchd respawn service remained after the smoke.

Authoritative LibreWPF CI: run 29492562330 is terminal success at exact head 702d5e3347186993c872ebb72cbdeaccb9da9a42. The full SDK/package/no-source-change job and clean Windows AnyCPU package-launch job both passed. Artifact librewpf-ci-packages-702d5e3347186993c872ebb72cbdeaccb9da9a42 has SHA-256 8fb654b2dddc1c10eaf57e446985d7653d3468009b87100db7537321269cd6ef.

This records the completed popup and Project Explorer milestone. The umbrella roadmap remains open for the explicitly listed designer, Linux, Hot Reload/DevTools, profiling, and broader tooling work.

[wieslawsoltes]

Preview release milestone: LibreWPF 0.1.0-preview.21 is published at immutable tag librewpf-v0.1.0-preview.21 / exact commit a4a7333d99d21da2e90984c34ba00ff30689d1da.

The release incorporates the ProGPU PR #23 line through immutable ProGPU v0.1.0-preview.21, strengthens Windows package/runtime closure, and is validated by:

• cross-platform/full package Build 29572182391
• tag publication 29574626586
• NuGet-only Windows Release+Debug visible-text smoke 29578076487

The broader tooling roadmap remains open; this comment records the exact preview.21 baseline for ongoing SharpDevelop/designer/ecosystem work.