How interested are you in a cross-platform PKHeX?

[dstaley]

Hi there! I'm a huge PKHeX fan, and I really appreciate all the effort you've put into it. I especially love that you've moved the core logic to the PKHeX.Core package, and are up-to-date with the latest release of .NET. I've been thinking a lot lately about cross-platform .NET apps, especially having recently purchased a macOS device.

Have you thought about how you might like to see PKHeX become cross-platform in the future?

I ask because I'm willing to contribute towards making that possible, but I strongly feel that maintaining a separate fork is going to be a difficult task, especially given how complex the UI needs to be to accommodate all the functionality that PKHeX provides. I know that you've explored tools like Xamarin.Forms in the past, so it definitely seems like something you might be interested in.

One particular approach I've been toying with is performing an incremental migration to Blazor Hybrid, since Blazor views can be embedded into a Windows Forms application. With that approach, you wouldn't need to completely rewrite the app from scratch in a single go, and could instead migrate one form at a time. For example, you could start by migrating the MoveShopEditor form to Blazor Hybrid, keeping all the other forms as-is. The biggest downside I see with this approach is that Blazor, being web-based, doesn't have some of the more complex UI controls that Windows Forms does (such as tabs, sortable tables, etc.). There are component libraries out there to make that easier though! Once every form has been converted to Blazor, you can then replace the shell app with .NET MAUI, which also support Blazor. That'd give you both Windows and macOS compatibility, along with a path forward to replace the Blazor views with native views should you be interested. Alternatively, if all of the UI is written in Blazor, it's probably not too much more effort to use Blazor WASM to make a web version of PKHeX.

As a sort of middle ground approach, you could also add a new PKHeX.MAUI project, which could be a full rewrite in .NET MAUI (using Blazor, native UI, or something like Uno). I think having the cross-platform project be "official" and in the main repo would be a good way to make sure things stay somewhat in sync. The difficult thing there is that rebuilding from scratch would probably take a significant amount of effort before it's viable for even minor edits, so there might not be much incentive to work on it. I also know there's already a community implementation in MAUI, so I could understand not wanting to spend a lot of effort making the exact same thing.

All of this is basically to say I'd love to help you make PKHeX cross-platform in whatever way you're most comfortable with!

[kwsch]

Blazor WASM: won't work due to certain cryptography libraries being unsupported: codemonkey85/PKMDS-Blazor#12
MAUI: won't work on Linux, and is primarily a mobile-app styled focus
Uno/Avalonia: larger exe sizes
WinForms: works well enough on Linux & Mac if using the latest wine, or a VM.

PKHeX.Core is available on NuGet, and anyone can pull the package for use in whatever rewrite they want to attempt. The games are continuously updating, so the majority of the work is spent on PKHeX.Core rather than the GUI portion of the program. The GUI works well enough, even though it is the oldest & most un-refined code in the codebase... the PKM editor and slot manipulation is an incredibly tangled mess, and there's >100 forms/controls that would need to be addressed. I don't see any compelling reason to spend the effort rewriting the GUI into another framework, when time is better spent on other areas / projects.

[shadow-absorber]

there is no .net 8 support in wine currently
the .net 7 version has problems with plugins and crashing if using some of the settings menus

this leaves 22.12.18 as the last neatly working pkhex version for linux in wine

[kwsch]

???

there is no .net 8 support in wine currently

Yes there is. Update your installation.

[Ciflire]

i agree, now there is with latest staging release

[FrostKnight]

Yep I just tried it, seems its been like this for a while.

[codemonkey85]

Blazor WASM: won't work due to certain cryptography libraries being unsupported: codemonkey85/PKMDS-Blazor#12

FWIW, that problem was solved a while ago using JS: codemonkey85/PKMDS-Blazor@78927c0

In particular https://github.com/codemonkey85/PKMDS-Blazor/blob/main/Pkmds.Web/libman.json, https://github.com/codemonkey85/PKMDS-Blazor/blob/main/Pkmds.Rcl/wwwroot/js/fileSave.js, and https://github.com/codemonkey85/PKMDS-Blazor/blob/d1cd4784c724ec58bafdbe5d7c2c31cb462b0b86/Pkmds.Web/Program.cs#L26.

(I know you won't use any of this, but someone who stumbles across this thread might appreciate it!)

[santacrab2]

I also just want to add that the MAUI project is open to contributions.

[Blood-PawWerewolf]

I just want a native Linux version so I don't have to deal with using proton on my SteamDeck (and as well as still waiting for .net 8 support)

[shadow-absorber]

same... such a shame how much a problem .net apps are on linux

[Ciflire]

I would be interested and i'm considering doing it.
I've discussed that with some of my professors and the sad thing is, the only corss platform and easy solution would be web to make a graphical application, the other 2-3 solutions are javaFx, gtk and qt (abandonned, gnome compatible only could not work well on everything, heavy af)

[shadow-absorber]

so are you still considering making a port to gtk??

[Ciflire]

i have never considered the option of porting anything to gtk, best option to me,would be web editing your save, compatible everywhere, on every platform, doesn't need compiling or anything, just an internet connection

[shadow-absorber]

also would love a linux native version... and it is probably qt or gtk for graphical toolkit for the better options... though shadow is not a great graphical program developer so can't easily do this themselves

[Gliscor]

We need Linux wizards to step on and make a Linux version.

[davidbitterlich]

Currently, there is a project trying to port Mono's WinForms to dotnet - however it's not very stable. I've messed around with PKHeX and this ported version because I was curious about how much effort would it be to enhance PKHeX to be able to run on Linux with Mono's implementation - and after many adjustments, I was finally able to run the UI project PKHeX.WinForms locally on my Ubuntu machine.

However it's very glitchy (e. g. these large tooltips are completely black), some buttons do not have visible text and when you create a new pokemon and try to add it to a box, the app will crash in method DoDragDrop when I try to drag the created pokemon into a box; right-click -> Set will cause a ArgumentNullException as it is unable to get the underlying picturebox via WinFormsUtil.GetUnderlyingControl (in ContextMenuSAV, line 139).

I think it is not worth the effort to try to port PKHeX with its Winforms to other platforms and since the other option to use PKHeX on NonWindows platforms is to use a virtual machine, there is no other way as to rewrite the UI in the long run (maybe in an own project that works independently from PKHeX) using a modern UI framework, such as Avalonia. Like it was previously said, PKHeX.Core is separated from the whole UI topic and is the technical foundation for the whole application's logic (open save files, perform changes to those files and save them back).

For those who might be interested in the porting topic, here is a short summary of my changes I did:

Playing Sounds:
On NonWindows platforms, there is no System.Media.SoundPlayer and no System.Media.SystemSounds stuff. -> I created a small wrapper project based on OpenTK to compensate this
System.Drawing:
On NonWindows platforms, System.Drawing has been deprecated in dotnet 6 and disabled on dotnet 7 and newer. Since The ported System.Windows.Forms is also based on System.Drawing (atleast an old version), I could achieve to use this for QRCoder
System.Windows.Forms:
The hugest problem when porting a WinForms app to NonWindows is that Microsoft has not created an own cross-platform implementation of WinForms. Like I said, there is a port of Mono's WinForms to dotnet 6, but it is glitchy and buggy (probably like the original project in Mono)

In my opinion, these stability issues are the blocking points and the reason why I would recommend to create a new GUI using Avalonia.

[shadow-absorber]

well you have done a lot more for the cause of a linux native version than most other people here... applaud your efforts... but yeah building a new gui for linux and mac would be neat but is far beyond shadows and most others heres capabilities

[davidbitterlich]

btw I have pushed all my changes to the codebase in my own repository.

Most of my issues I've noted above were caused by the virtual machine I used. Running Ubuntu 22.04 on a local workstation PC is causing less visual glitches (but they are not gone at all). Also right-click context menu functionality on these picture boxes representing the pokemon boxes still causes issues as the underlying identification functionality still does not really work [drag and works though] (I did not have time yet to investigate it. I believe this is caused by some crap in System.Windows.Forms and I would like to find out the cause of this so that it could be fixed upstream)

[davidbitterlich]

I did some research at the ported System.Windows.Forms code. It was directly taken over from Mono and in the official Mono, this bug was introduced - I guess one or two years ago. In current distribution packages you won't notice this issue because there's still Mono 6.12, however current git is 6.13 and this is the code which was picked up and ported to dotnet 6... For that reason, I opened a bug report at the GitHub repository of the ported System.Windows.Forms package as well as Wine Mono as it was the more active Mono fork (and is by now the only left official Mono). We will see whether this will ever be fixed and if yes, I'll continue to improve the codebase of my current branch.