Add a WinUI3 backend #2574
Comments
|
Thanks for the suggestion - we'd love to add a WinUI3 backend; the problem is that there are no Python bindings for WinUI3. Once those bindings exist and are stable, a WinUI3 backend for Toga can be developed. |
|
Maybe I could help make one |
|
Hi @jhi2, I am a C programmer and would be happy to help. In this case, I think that the ctypes + DLL approach taken by win32more makes sense, at least to get an MVP. Generally, I am having a hard time understanding that repo, it is very complex. It sorta looks like a code generation tool PLUS some generated code, which makes usage confusing. Plus, organizing all these namespaces by way of directories is perhaps nice for repo organization but it may be not so great for Python import initialization. I have concerns about the "DLL function decorator". Perhaps win32more can be used to generate only the bindings that a Toga backend would need? Happy to help with testing or other tasks. TBH, anything other than a Microsoft supported solution will be a bit of a hack. MS probably doesn't have the money or talent for this 🙄. |
|
To see how simple the ctypes APIs can be, try this example: import ctypes as c
user32 = c.WinDLL("user32.dll")
user32.MessageBoxW(0, "Hello World", "Hello", 1)Where the documentation is from here: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-messageboxw The tedious bit is having nice wrappers with typing. I am looking into the winrt package collection: https://pypi.org/search/?q=winrt&page=1 So far I have not been able to reproduce a simpler version of what win32more is doing. I am able to import an XAML Application class but cannot create the application. |
|
The win32more interface to Compare to the interface generated by WinRT: @typing.final
class Application_Static(type):
@typing.overload
def load_component(cls, component: typing.Optional[winrt.system.Object], resource_locator: typing.Optional[windows_foundation.Uri], /) -> None: ...
@typing.overload
def load_component(cls, component: typing.Optional[winrt.system.Object], resource_locator: typing.Optional[windows_foundation.Uri], component_resource_location: microsoft_ui_xaml_controls_primitives.ComponentResourceLocation, /) -> None: ...
def start(cls, callback: typing.Optional[ApplicationInitializationCallback], /) -> None: ...
@_property
def current(cls) -> typing.Optional[Application]: ...
@typing.final
class Application(winrt.system.Object, metaclass=Application_Static):
@staticmethod
def _from(obj: winrt.system.Object, /) -> Application: ...
def __new__(cls: typing.Type[Application]) -> Application: ...
def exit(self) -> None: ...
def add_unhandled_exception(self, handler: typing.Optional[UnhandledExceptionEventHandler], /) -> windows_foundation.EventRegistrationToken: ...
def remove_unhandled_exception(self, token: windows_foundation.EventRegistrationToken, /) -> None: ...
def add_resource_manager_requested(self, handler: windows_foundation.TypedEventHandler[winrt.system.Object, ResourceManagerRequestedEventArgs], /) -> windows_foundation.EventRegistrationToken: ...
def remove_resource_manager_requested(self, token: windows_foundation.EventRegistrationToken, /) -> None: ...
@_property
def resources(self) -> typing.Optional[ResourceDictionary]: ...
@resources.setter
def resources(self, value: typing.Optional[ResourceDictionary]) -> None: ...
@_property
def requested_theme(self) -> ApplicationTheme: ...
@requested_theme.setter
def requested_theme(self, value: ApplicationTheme) -> None: ...
@_property
def high_contrast_adjustment(self) -> ApplicationHighContrastAdjustment: ...
@high_contrast_adjustment.setter
def high_contrast_adjustment(self, value: ApplicationHighContrastAdjustment) -> None: ...
@_property
def focus_visual_kind(self) -> FocusVisualKind: ...
@focus_visual_kind.setter
def focus_visual_kind(self, value: FocusVisualKind) -> None: ...
@_property
def debug_settings(self) -> typing.Optional[DebugSettings]: ...
@_property
def dispatcher_shutdown_mode(self) -> DispatcherShutdownMode: ...
@dispatcher_shutdown_mode.setter
def dispatcher_shutdown_mode(self, value: DispatcherShutdownMode) -> None: ...Here's the C# doc: https://learn.microsoft.com/en-us/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.application?view=windows-app-sdk-1.5 |
|
If you're calling APIs in user32, you're not calling WinUI3 API; you're calling the 1995 era win32 API. It's also available using the win32api package, which is mostly a set of convenience wrappers around the win32 API. It may be possible to use ctypes to call WinUi3 libraries, but the API calls and libraries will be different. |
Yes! The intention is to show how easy it is to make calls to any DLL from python. Presently I'm trying to track down how win32more is hooking into the new APIs. This decorator is on Application::Start: It's getting the "Start" function from this: Seems like the magic is in the RoGetActivationFactory, which I've not heard of before: https://learn.microsoft.com/en-us/windows/win32/api/roapi/nf-roapi-rogetactivationfactory |
xaml = ctypes.WinDLL("windows.ui.xaml.dll")Is actually loading something... not sure what - can't find any function pointers. |
|
If you're digging into this, I'd pay particular attention to this comment on the WinUI3 ticket I've referenced earlier in this discussion. @zooba is a Microsoft employee and member of the CPython core team; his offer around co-developing bindings should not be ignored or taken lightly. |
|
Yeah, this is a really deep hole to dive into :) I was lucky to spend my intern project at MSFT (in 2011) working on this stuff while the APIs were being developed, and I don't think any of the low-level intro material we had ever made it public. Basically, all the WinRT APIs are approx. COM, which means you don't load them as normal C APIs. The WinUI3 is based around these same APIs, but are registered somewhat differently. I haven't dug too far into all the details, but it's more convenient (and more wasteful of memory and disk space) than the original Windows 8 UWP APIs. But having now implemented 4 different approaches of accessing it from Python, the one I think is best is to just generate C++ code to do all the GUI side and have it call back into Python. I've implemented something along these lines here2. It was pretty easy to translate some existing C# samples into Python, but I haven't really tried it at scale (though it already scales so much better than previous efforts that I'm sure it'd be fine). There might be something of value in there for you. Footnotes |
I like the "MS probably doesn't have the money or talent for this 🙄" That's why they invented Rectify11 haha. |
|
|
I will use cTypes |
Literally, cannot wait until AI is "over". But then there will be the "next thing" that takes resources away from luxuries like being able to produce and distribute signed applications.
Will take a look! Also, consider testing this as the backend instead of win32more: https://github.com/zooba/pymsbuild-winui |
|
Very maybe we can get ctypes - I'll have to fiddle. >>> com = ctypes.WinDLL("combase.dll")
>>> com.RoGetActivationFactory
<_FuncPtr object at 0x000001F9BE423790> |
|
No, it still seems foolish to try: https://learn.microsoft.com/en-us/windows/win32/api/roapi/nf-roapi-rogetactivationfactory#syntax
|
|
I would just want to call C++ code from ctypes. I found a way to call Python from C/C#/C++(Python.h) |
Really? how will u sign them? Linux? |
This might be nice, but I'll recommend pymsbuild-winui or win32more for generating the bindings. I think it might be possible with ctypes but feels hacky. I mean, it's all hacky. That RoGetActivationFactory will provide a function pointer, but I'm not sure how to bind it to a python function. Maybe with this: https://docs.python.org/3/library/ctypes.html#callback-functions |
|
You'll actually want function prototypes, but you might also be able to find a COM library that implements the core functionality (e.g. the (And to be clear, I'm only recommending this for research purposes. There's just no way to build everything you'll need with |
|
Presently leaning toward a proof of concept that is a PyPI package with static libs based on pymsbuild-winui. One goal is to avoid developers needing to install the VS toolchains. |
|
|
I DO NOT LIKE the setup of pymsbuild-winui |
It's not setup as a package yet, so that would be the work, AFAICT. I really hope to have some time to look into this soon! |
|
I have a remarkable new breakthrough, based on the foundation that WinUI3 is a COM object. I will come out with the code soon here. |
|
Here is the code I promised: pip install pywin32 import win32com.client
Microsoft.Ui.Xaml = win32com.client.Dispatch("Windows.Ui.Xaml")
#WinUI3 is now accessable |
|
Anyone what? What response are you expecting? You've posted a snippet of code that suggests that the WinUI3 API may be accessible - using an approach that didn't occur to a Microsoft employee who worked on the problem while working at Microsoft. Even if we assume that the approach you've described does work - there is a huge gap between "here's how you can access the WinUI3 libraries" and "Here's a WinUI3 backend for Toga.". It definitely didn't happen in the 30 minutes between you posting the proposed solution and responding "Anyone?". |
I can look it over. Think of this as an exploratory phase where we're looking for cleanest starts of a minimum viable product. Ideally, we reproduce this in "pure" python: https://github.com/sotanakamura/winui3-without-xaml I'll be fiddling presently, so feel free to send examples of what you have so far. |
|
Can't the Toga code generate the xaml? |
That would be one approach. |
|
Look over what? You've provided 3 lines of code. I'm sceptical that the approach you've described will work - because if something that simple would work, I feel like @zooba would have suggested it. However, I have no particular expertise with COM, WinUI3, or Windows in general, so I'm not really in a position to provide any sort of critical analysis of the approach. Adding a WinUI3 backend isn't on my roadmap for this quarter - nor is it likely to be on my roadmap in the foreseeable future. If this is something that interests you, than I'm able to provide advice on how to go about building a WinUI3 backend; and I'm willing to review code in the form of PRs against the Toga repo - but until there's working WinUI3 code that can run, there's not much more I'm in a position to offer. And - answering your follow up question - no, Toga can't use a XAML approach. Toga needs to be able to programmatically drive the construction of widgets. Generating markup isn't an approach that is fundamentally compatible with Toga. |
Traceback (most recent call last): |
|
Is there any way to fix this |
I was hoping that you already had 🤣! I am seeing the same thing, and I suspect that it's (one of) the reason that we're being steered towards alternatives by zooba. |
|
@jhi2 Found this little tool: |
|
I have built the example applications from https://github.com/zooba/pymsbuild-winui Unfortunately I didn't take notes, but after some fiddling, I'd suggest the following workflow:
Other thoughts
Next steps
|
Nice! |
|
have you seen https://pypi.org/project/winrt/ |
|
@jhi2 The Python WinRT projection is the subject of literally the first comment on the WinUI3 thread. AIUI, it can't be used for exposing WinUI3 APIs because you can't build an automated binding to C++. |
|
Can't say I've seen those. Last time I looked, winrt didn't have any GUI bindings at all; and from my discussions with people at MS, it wasn't plausible to add them, either. If that isn't the case any more, then it might be possible to build a WinUI3 backend using winrt as the binding. |
winrt was my original starting point and I was unable to replicate the win32more example. Specifically, this call was my stopping point: https://learn.microsoft.com/en-us/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.application.start?view=windows-app-sdk-1.5#microsoft-ui-xaml-application-start(microsoft-ui-xaml-applicationinitializationcallback) |
|
Hey, for my app, can you make a win32more-like binding for my app for pymsbuild-winui. submit as pr to jhi2/PyUI3 |
|
@jhi2 I'm not looking for more projects to contribute to. I'd certainly like a WinUI3 binding to exist, but it's not a priority for me at present, partially because Toga has a binding that works on Windows, and partially because I don't use Windows as a platform myself. If you want a WinUI3 binding, you'll need to either develop it yourself, pay for someone else to develop it for you, or wait for someone else to develop it for you. |
Go ahead and tag me on a discussion or issue on that repo to continue this discussion. I should not have criticized win32more so much... it does seem to be providing a programmatic interface to WinUI3 which is more than other attempts have yielded. Perhaps it's complexity is necessary and something that can be improved over time. Anyway, keep going with that and see what you can do! But let's work outside of Toga until there's something to offer Toga. |
|
Yeah, an error. I'll tag u. |
pywin32more makes it a solved problem. It's an impressive Python binding/projection for most of WinApi, including the core bits from the 90s, as well as WinUI3, and most everything else that's available via COM. What's even more impressive is that it's a Python-only package. It does everything via ctypes. On top of those it adds runtime type checking, and has type annotations for the entire API. Of course it's machine generated, and the generator is quite clever. The projection is lazy-loaded, so that you only pay for the identifiers that you use and nothing more. Note that from win32more.xaml import XamlApplication
from win32more.Windows.Foundation import Uri
from win32more.Microsoft.UI.Xaml import (
HorizontalAlignment,
ThicknessHelper,
VerticalAlignment,
Window,
)
from win32more.Microsoft.UI.Xaml.Controls import (
Button,
HyperlinkButton,
StackPanel,
TextBlock,
)
from win32more.Microsoft.UI.Xaml.Media import (
DesktopAcrylicBackdrop,
)
class App(XamlApplication):
def OnLaunched(self, args):
window = Window()
self.window = window
window.SystemBackdrop = DesktopAcrylicBackdrop()
stackPanel = StackPanel()
stackPanel.HorizontalAlignment = HorizontalAlignment.Center
stackPanel.VerticalAlignment = VerticalAlignment.Center
title = TextBlock()
title.Style = App.Current.Resources.Lookup("TitleTextBlockStyle")
title.Text = "WinUI 3 in Python Without XAML!"
title.HorizontalAlignment = HorizontalAlignment.Center
project = HyperlinkButton()
project.Content = "Github Project Repository"
project.NavigateUri = Uri("https://github.com/sotanakamura/winui3-without-xaml")
project.HorizontalAlignment = HorizontalAlignment.Center
button = Button()
button.Content = "Click Me"
button.Click += lambda sender, args: button.put_Content("Thank You!")
button.HorizontalAlignment = HorizontalAlignment.Center
button.Margin = ThicknessHelper.FromUniformLength(20);
window.Content = stackPanel
stackPanel.Children.Append(title)
stackPanel.Children.Append(project)
stackPanel.Children.Append(button)
window.Activate()
def ButtonClick(self, sender, args):
sender.as_(Button).Content = "Thank You!"
if __name__=="__main__":
XamlApplication.Start(App)
|
win32more uses ctypes only. It's pure Python, machine-generated using a generator written in Python from JSON API description available elsewhere. Pretty much all of Windows API that is available from C is covered, and WinUI is definitely available via C, since COM works in C just fine, albeit it's a pain to use without generated code. |
WinUI and WinRT have C++ projections, they are not C++-native. The C++ code drops down to good old COM, so there's little benefit to the C++ shim if we want to use it from Python. C# does the same. We might as well use the same COM interfaces that the C++ projection uses, but expose them Pythonically as Python classes etc. And that's what pywin32more does - it uses low-level COM directly, via ctypes. And it exposes the non-COM Win32Api as well. Since it's machine-generated, it provides all the constants, structures and functions that the C Win32 headers provide. Using it feels fairly natural to me. At the moment, there is no other Python projection of Windows APIs that is competitive IMHO. |
|
Tagging @th3w1zard1 on this; it looks like pywin32more might implement the sort of reflective binding that we've been discussing in the context of #2786. That might make it a better match than comtypes for that work, while also leaving the door open for a full WinUI3 backend. |
|
From what I've researched, yes pywin32 is a solution and can directly replace comtypes. I've spent several weeks on the ifileopendialog/ifilesavedialog, learning com programming and trying to figure out how the heck it would work through Python. One of the first things I've tried was looking into pywin32, as many stackoverflow posts I came across were using it. I came across several problems:
There were a few benefits such as:
Looking through their codebase, I seriously could not figure out how to wrap the com interface. I experimented around with interop from comtypes <--> pywin32. and anytime I would come across such a stackoverflow post it would either never integrate or the code just wouldn't make sense. Naturally the next thing I tried was to see if my code would run in C++. Sure did. So the issue straight up seemed to be and finally that is when I considered tldr if there are users highly familiar with pywin32 and can properly document toga's interaction with it, and provide a plan forward, I think it's a far better solution than edit: the early versions of my code still linger at the back of my mind as I keep thinking 'there's literally zero reason this is not working right now comparing to the C/C++'. It's exciting I might be getting an answer and the understanding of why I couldn't get my code working :) |
To clarify - |
My COM post was about the former. |
Yeah exactly... so what am I missing here? Could we talk about what is happening to this and #2786 ...? I'd like to know if it'd be worthwhile to continue holding off with |
|
py-win32more is a projection of the full Windows API. It includes pretty much everything documented by MS. It’s not just a way to consume winrt api. It is a Python way of using Windows. I am using it professionally. It covers everything that comes in Windows SDK headers. It also has runtime type checking that helps avoid crashes that the dynamicism of Python would otherwise make easy to run into.pywin32 is a small projection of WinAPI - it covers a small part of it, maybe 20%? comtypes is just a framework one could use to consume winrt (with some pain). You’d still be typing in the signatures of stuff.As far as I am concerned, win32more is THE way to use Windows APIs in Python. There’s another professional projection of WinAPI that includes winrt stuff - Microsoft’s own winrt package on pip. Caveat emptor as MS had a tendency of dropping OSS projects randomly.If win32more’s strength is the simplicity of implementation, complete coverage of the APIs, and ease of vendoring if ever needed, winrt’s strength is the example code - there is a lot of it, and it’s pretty good. In most cases, „translating” it to win32more is trivial and takes changing the imports. Other minor adjustments may be needed too.I have more trust in win32more’s longevity than winrt’s. Should the worst happen, I am familiar enough with it to continue maintaining it. I have a fairly large internal project that uses it.I’ve looked at how much work it would be to get a proof of concept WinUI 3 backend for toga that can get at least a few of the more complex examples working. I’ll now shut up and work on that instead. Expect a PR for the PoC so that we can at least have something concrete to talk about :)2. nov. 2024 kl. 5:22 am skrev Benjamin Auquite ***@***.***>:
From what I've researched, yes pywin32 is a solution and can directly replace comtypes.
To clarify - pywin32 and py-win32more/win32more are two different projects. The discussions on this ticket have been about the latter.
My COM post was about the former.
Yeah exactly... so what am I missing here?
Could we talk about what is happening to this and #2786 ...? I'd like to know if it'd be worthwhile to continue holding off with comtypes if we believe something better could be implemented here?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
I'm not sure who this question is directed at - but personally, I have no idea why pywin32 is being mentioned at all.
From my personal perspective - nothing is happening here. This ticket exists to flag the fact that yes, we'd like a WinUI3 backend. It's not on my own roadmap, nor is it likely to be in the near future. However, if someone were to contribute a WinUI3 backend, I'd look at it. To that end, the fundamental issue that needs to be resolved at this point is the interface that will be used to implement the Python-WinUI3 bridge. The Winforms backend uses python.net. That provides a way to invoke Winforms APIs from Python in a format where it's obvious how to read official Winforms documentation and turn that into Python code. I don't use Windows on a daily basis, and I'm not deeply familiar with Windows GUI programming, but I can use Python.net to read Winforms documentation and implement Toga's APIs. What is the equivalent for WinUI3? Based on what has been said in this thread, win32more sounds (to me) like the most viable option - but I'm saying that on the basis of no practical experience, and a single example app presented above. I haven't explored what (if any) limits the win32more approach has when it comes to more complicated widgets, the stability/maintainablity of the win32more project, or whether it addresses any of the issues that currently face the winforms backend (e.g., support for ARM architectures, support for widgets like DetailedList or Tree, or modern dialog support). As for #2786 specifically - nothing has changed since my last comment. The most pressing issue is that the testbed tests are currently failing. That needs to be resolved. I've already provided some pointers; if you need something more specific to get unstuck then you'll need to indicate where you need help. |
(Ticket content has been edited significantly from the original to provide better guidance on the feature request)
What is the problem or limitation you are having?
Toga's look and feel on Windows currently uses Winforms, which doesn't reflect the current look and feel of Windows apps.
Describe the solution you'd like
We should add a WinUI3 backend.
Describe alternatives you've considered
Continue to use Winforms.
Additional context
The prerequisite for this backend is the development of Python bindings for WinUI3.
The text was updated successfully, but these errors were encountered: