Investigate replacements for Python.net on Windows

[freakboy3742]

What is the problem or limitation you are having?

5 months after the release of Python 3.14, we don't have a Python.net release that supports that version. This is an annual concern; Python.net releases always lag Python releases by up to months.

Python.net is used because it gives access to Winforms; however the Winforms API has a number of notable gaps - adding icons to Tables has proven complicated (#4164); multi-column Trees and DetailLists are equally complicated.

It's not clear if Winforms is the right API with which to build a modern Windows GUI library.

Describe the solution you'd like

We need to find either:

1. A viable way to resource/assist with Python.net so that support for new Python releases doesn't lag
2. A path to making the Win32 backend viable (including, but not limited to, finding sources of information on how to build widgets, and how to simplify the developer experience). We have historically published a win32 backend - we may need to resurrect it.
3. A path to using some other GUI layer, such as WinUI3 layer (Add a WinUI3 backend #2574).

At this stage, an investigation of options is required.

Describe alternatives you've considered

Stick with Winforms and Python.net. For all the flaws, it works...

Additional context

#884 was a past manifestation of this problem. At the time, we decided to keep with Python.net; but the distribution lag and the edge cases in widget development haven't improved with time.

[johnzhou721]

Seems that for multicolumn trees unless you use custom rendering it is hard to get natively -- multicolumn trees are rarely seen in any Windows app from my experience. They're common, however, in for example, KDE.

See also #1606 for not being able to override protected virtual methods.

[mhsmith]

2. A path to making the Win32 backend viable (including, but not limited to, finding sources of information on how to build widgets, and how to simplify the developer experience). We have historically published a win32 backend - we may need to resurrect it.

I wouldn't recommend that: aside from being much more verbose than WinForms (as #2110 shows), Win32 is a low-level C API, which means a very large fraction of coding errors will cause a hard crash with no useful information.

It would probably be a more efficient use of our time to provide assistance to Python.NET where necessary, and to use Win32 only for those things that WinForms doesn't cover, as we already have in several places.

[johnzhou721]

@mhsmith Hmm... but I'd argue that Python.NET uses some CPython internals, and CPython internals is also a low-level C API, which means a very large fraction of coding errors will cause a hard crash with little useful information.

It would probably be a more efficient use of our time to investigate pure-Python ways to bridge to .NET or other solutions such as pybind11 if necessary, and to use Win32 only for those things that WinForms doesn't cover, as we already have in several places.

[freakboy3742]

I wouldn't recommend that: aside from being much more verbose than WinForms (as #2110 shows), Win32 is a low-level C API, which means a very large fraction of coding errors will cause a hard crash with no useful information.

No disagreement that win32 is more difficult to work with; but it is the underlying API that everything seems to fall back onto.

It would probably be a more efficient use of our time to provide assistance to Python.NET where necessary, and to use Win32 only for those things that WinForms doesn't cover, as we already have in several places.

AFAICT, that assistance would need to come in the form of patches, because they haven't been responsive to multiple offers of financial assistance over the years. I can't speak for anyone else, but personally, I don't have anywhere near the expertise required to assist with the problems they're having (and, again speaking personally, I don't have much personal interest in developing that expertise, either).

The bigger question I'm trying to ask here is whether Winforms is actually dead technology, and whether we should be looking at something else - and if, in doing so, we can break our dependency on a project that clearly has some maintenance constraints. However, Microsoft has muddied the waters so much that it's not clear what that "something else" would be.

[johnzhou721]

The bigger question I'm trying to ask here is whether Winforms is actually dead technology, and whether we should be looking at something else - and if, in doing so, we can break our dependency on a project that clearly has some maintenance constraints. However, Microsoft has muddied the waters so much that it's not clear what that "something else" would be.

The waters are very muddied right now, to be honest -- scrollbars have changed shape in Windows 11, yet the Windows key / search still uses the old scrollbar on the left pane. Microsoft Word's most dialogs are replaced with new, fancy styling, yet some popups aren't Windows 10, isn't Windows 7, but kind of like Windows XP styling where focused buttons have a subtle dotted border. I don't remember which dialog now, so can't screenshot.

But it seems that most of MS365 is powered by FluentUI as seen at https://developer.microsoft.com/en-us/fluentui#/... so is there any way to mix, and gradually transition components?

Although WinForms as a framework is out of date, it's still keeping up with some subtle styling changes, like this textbox in Windows 11 style:

So it's not urgent that we get a new framework used now, but it should still be something we look inot.

[freakboy3742]

Fluent is a new term for me - but given that the docs for FluentUI on Windows redirect to the WinUI3 docs, it doesn't look like there's anything new we weren't previously aware of.

[johnzhou721]

Fluent is a new term for me - but given that the docs for FluentUI on Windows redirect to the WinUI3 docs, it doesn't look like there's anything new we weren't previously aware of.

Fluent is the design language -- Fluent is to WinUI3 as Material3 is to MDC (Material Design Components) or Jetpack Compose as Cupertino and Liquid glass is to UIKit/AppKit as Adwaita is to default stylesheets in GTK3 / libadwaita is in GTK4.

I was pointing out the fact that it's not absoltuely urgent to use the new frameworks, but we should investigate as there are new components like sidebar/navigation rail.

[freakboy3742]

A friend pointed me at this blog post lamenting the state of native Windows app development - it introduced me to https://avaloniaui.net as an Open source (used by Jetbrains and Unity?) toolkit providing "missing .Net GUI options". However, it also points at this blog post, suggesting WinUI3 might be an area of Microsoft's focus in the near future...