Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pythonnet or not? #60

Closed
AstraLuma opened this issue Oct 28, 2016 · 8 comments
Closed

pythonnet or not? #60

AstraLuma opened this issue Oct 28, 2016 · 8 comments

Comments

@AstraLuma
Copy link
Contributor

Since no matter what, you need pywin32 and comtypes, is there an appreciable difference to users between using pythonnet (and the .NET API) or not (and the Win32/COM API)?

@den-run-ai
Copy link
Contributor

pythonnet can also target WPF

@AstraLuma
Copy link
Contributor Author

Does that make a difference, given that all it does is load MSHTML?

@r0x0r
Copy link
Owner

r0x0r commented Oct 28, 2016

Pythonnet does not require pywin32 or comtypes. However, if you freeze it both pywin32 and pythonnet libraries will be bundled provided you have them installed.
There is no difference from a developer point of view, which implementation you use, unless you are gonna target a really old Windows version that does not have .net included. Both use MSHTML in the end. The original motivation for the net implementation was Edge support, but as it turned out Edge is supported only in UWP apps. One can hope that Microsoft will backport Edge support to winforms. Comtypes compatibility problems with Python 3.5 until recently, so getting rid of this dependency was another factor for an alternative implementation
The net version is quite recent and is not tested properly. The application icon is missing or freezing with pyinstaller does not work out of the box, for instance. However, given how much easier is development is with .net comparing to win32, I am going to focus on the former. For example currently I have no plans for implementing load_html function for win32
The net implementation uses Windows Forms, not WPF by the way. I see no point in WPF support. UWP would be nice, but it is not possible at the moment.

To summarize all this, you can target either one, but the development of pywebview will be focused around .net in the future. I would love to hear about your experience with the net implementation.

@AstraLuma
Copy link
Contributor Author

Oh, then there's another bug: winforms.py imports a few things from win32.py and (indirectly) makes use of both pywin32 and comtypes. This does not look fixed on master.

@r0x0r
Copy link
Owner

r0x0r commented Oct 29, 2016

True, winforms.py imports a few things from win32.py and win_gen.py, but
they are no dependant on pywin32 or comtypes. What indirect use do you mean?

On 29 Oct 2016 12:53 a.m., "Jamie Bliss" notifications@github.com wrote:

Oh, then there's another bug: winforms.py imports a few things from win32.py
and (indirectly) makes use of both pywin32 and comtypes. This does not look
fixed on master.


You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#60 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABelWSWdH9NzCdmVnY590JWQvwO3w-sqks5q4m7ogaJpZM4Kju0x
.

@r0x0r
Copy link
Owner

r0x0r commented Oct 29, 2016

My bad, I see the bug now. I will refactor the code and get rid of unnecessary dependencies.

@r0x0r
Copy link
Owner

r0x0r commented Oct 30, 2016

Fixed in master. Winforms should not have any pywin32 or comtypes dependencies now.

@r0x0r
Copy link
Owner

r0x0r commented Oct 31, 2016

Fixed in 1.3

@r0x0r r0x0r closed this as completed Oct 31, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants