Solved .NET Avalonia support on FreeBSD

SDK Chan

SDK Chan

I don't exactly know whether another category would more fit for this topic, but it isn't central to emulation so, I posted it here.

Avalonia is the way to go user interface for Ryujinx, since GTK 3 was not further developed at some point in time, meaning Avalonia has more user friendly features, and it looks better compared to GTK 3.
I would like to see Avalonia support in FreeBSD as it makes life easier using Ryujinx.
Ryujinx can also be used without gui, but it would be easier to configure through a GUI.

How is the state with Avalonia on FreeBSD ?
Could it eventually be made functional for FreeBSD, too ?
 
SDK Chan said:
I don't exactly know whether another category would more fit for this topic, but it isn't central to emulation so, I posted it here.
Click to expand...
"Userland programming and scripting" is probably a better fit. Maybe "Porting new software", but we'll see in what direction the thread will move.
 
Have you had a play with WinForms? Its not new or fantastic looking by any means but similar to Java's Swing compared to JavaFX, it is baked into the .NET ecosystem and is likely to be around for many generations compared to others.

It also has the benefit of being built from the graphics layer as .NET (similar to Swing) rather than being a wrapper ontop of an existing toolkit. This does help facilitate portability somewhat.
 
kpedersen said:
Have you had a play with WinForms? Its not new or fantastic looking by any means but similar to Java's Swing compared to JavaFX, it is baked into the .NET ecosystem and is likely to be around for many generations compared to others.

It also has the benefit of being built from the graphics layer as .NET (similar to Swing) rather than being a wrapper ontop of an existing toolkit. This does help facilitate portability somewhat.
Click to expand...
WinForms is on my todo list, as I progress through my C# course path.
Since it is baked into .NET, and .NET is on version 9.0.5 according to fresh ports, I assume WinForms would work on FreeBSD where Avalonia possibly wouldn't ?
It is just that cake version 5.0 got support on FreeBSD with .NET version 9 so, I wonder whether WinForms is fully supported on FreeBSD.

Ryujinx (switch-emu) has an outdated GTK3 GUI, and the newer up to date Avalonia GUI.
There were some use cases reported where Avalonia didn't work on FreeBSD.
Maybe it has changed.
As far as I know Avalonia wants to leave .NET at some point in the future, too.
I will try Avalonia first, if it doesn't work, maybe WinForms would be an alternative.
 
shkhln said:
It doesn't exist outside of Windows, so that statement is trivially true.
Click to expand...
No, what you mean to say is that it "doesn't live up to your expectations outside of Windows".

Big difference. If an emulator just needs a place to render some OpenGL graphics and a toolbar, then your own requirements for it are unrelated (and likely excessive).

Basically, if you can compromise a little, you can avoid dragging in Gtk which is a net win. Life is all about compromise ;)
 
I literally linked the repo for WinForms, you are free to find any non-Windows code in that. I'm also aware about Mono's reimplementation, but it's buggy and hasn't been ported to any actual .net versions (not sure how much work that is). It also doesn't help your argument that you substitute one independent implementation with another without mentioning any potential downsides. You even imply it's well supported, while the whole Mono thing was ditched to the Wine people, who are somewhat understaffed for that adventure.
 
shkhln said:
I literally linked the repo for WinForms, you are free to find any non-Windows code in that.
Click to expand...
It should be clear since this is a FreeBSD forums that we are not (just) discussing the Windows implementation. My link in the subsequent post to libgdiplus should have confirmed that.

shkhln said:
I'm also aware about Mono's reimplementation, but it's buggy
Click to expand...
As mentioned, as adults we can compromise and perhaps analyze an incomplete (or buggy) toolkit to see if the (basic) UI requirements needed for an emulator can avoid the weaker parts. A rendering window and menubar are trivial requirements (and yes, Mono's Winforms had these working over a decade ago).

shkhln said:
It also doesn't help your argument that you substitute one independent implementation with another
Click to expand...
Microsoft Winforms + Mono Winforms = 2 independent Winforms implementations. Already we are starting to get resilience through multiple implementations (We ignore DotGNU's ancient Winforms implementation).

shkhln said:
You even imply it's well supported, while the whole Mono thing was ditched to Wine people, who are somewhat understaffed for that adventure.
Click to expand...
We all know that in 2025, almost no desktop GUI toolkits are well supported. Alternatives like GtkSharp and Avalonia don't even have the Lindy Effect on their side.

In terms of resilience, I would probably just wrap Glut with some .NET bindings, initialize an OpenGL context and render the UI entirely in the graphics layer. But whilst that would ensure lifespan, it is a little more initial work, especially to someone starting out.
 
kpedersen said:
A rendering window and menubar are trivial requirements (and yes, Mono's Winforms had these working over a decade ago).
Click to expand...
You forgot, or, rather, knowing you, deliberately avoided mentioning the preferences dialog(s).

kpedersen said:
We all know that in 2025, almost no desktop GUI toolkits are well supported. Alternatives like GtkSharp and Avalonia don't even have the Lindy Effect on their side.
Click to expand...
If only. It's usually something where text is not visible, etc. Looks pretty basic to me.
 
shkhln said:
You forgot, or, rather, knowing you, deliberately avoided mentioning the preferences dialog(s).
Click to expand...
Don't get hung up on trivial things. I know you tend to. You think some buttons, dropdowns and textboxes required for a preferences window is a problem? Why do you feel it deserves specific mention?

To any decent developer, this would seriously be a non-issue. How weird do you make your preferences dialogs?!

shkhln said:
If only. It's usually something where text is not visible, etc. Looks pretty basic to me.
Click to expand...
A dealbreaker for an emulator? Seriously? Most Gtk ones use a fixed size anyway.

Again, you are getting hung up on trivial crap. Remember, perfection is the enemy of good portability. The lowest common denominator approach sometimes is absolutely better than nothing at all.
 
kpedersen said:
Last time I looked it was: WinForms -> libgdiplus -> Cairo -> X11
Click to expand...
I searched a bit in the internet, and found out WinForms works on FreeBSD, but there is a requirement, the application it wraps around needs to be cross-plattform.
If Avalonia still doesn't work, at least WinForms even if it is ugly, could do the basic work, providing a surface window for drawing, and a toolbar + windows for option settings.

The definition from the WWW:
Mono:
Mono is an open-source implementation of the .NET Framework. It can be used to run .NET applications, including WinForms, on other platforms, including FreeBSD. However, Mono's WinForms implementation might not provide the exact same level of functionality as the native Windows version.
Click to expand...
If you ask me, that should be enough for Ryujinx.

kpedersen said:
Basically, if you can compromise a little, you can avoid dragging in Gtk which is a net win. Life is all about compromise ;)
Click to expand...
GTK 3 is literally dead in terms of Ryujinx.
Yes, it is still there, and it works, but it wasn't updated for months after Avalonia was introduced to the project.
The last time I build Ryujinx, and checked it, it was really messy, and some options were absent.
This also explains why the GTK 3 external is not up to date, wherefore glibc is missing, and it doesn't load in FreeBSD.
If Building Ryujinx you get luckily all options for launching it, including HEADLESS, too, through SDL2.
I didn't really try out the HEADLESS version, since my focus is still on improvement, before actually providing the emu to the masses.


kpedersen said:
In terms of resilience, I would probably just wrap Glut with some .NET bindings, initialize an OpenGL context and render the UI entirely in the graphics layer. But whilst that would ensure lifespan, it is a little more initial work, especially to someone starting out.
Click to expand...
Sounds like a good idea.
If you want to try that out, on Ryujinx, I will reach back at you, once I am done with C#, and Vulkan, and the port of Ryujinx.
As much as I like emulation, and the CORE part, I am not really a fan of UI designs.
Basically a simple, yet efficient UI would do the job since the main part relies in the CORE rather than the fancy things.
 
SDK Chan said:
Sounds like a good idea.
If you want to try that out, on Ryujinx, I will reach back at you, once I am done with C#, and Vulkan, and the port of Ryujinx.
As much as I like emulation, and the CORE part, I am not really a fan of UI designs.
Basically a simple, yet efficient UI would do the job since the main part relies in the CORE rather than the fancy things.
Click to expand...
For reference, I have a project I wote a while back that goes the other way (.NET winforms -> C++). You can perhaps use it as an example to see how this binding can be done (homogenous codebases typically are better though!).

https://github.com/osen/software-3d-renderer/blob/master/src/net_platform/net_platform/Program.cs

Do note though that the largest time-sink for this approach will be the custom OpenGL widgets. Hence why I recommend going with Winforms (or other) for now. Writing widgets isn't particularly interesting (and one day when "AI" gets better, I look forward to getting an entire suite of these things generated!)
 
kpedersen said:
Do note though that the largest time-sink for this approach will be the custom OpenGL widgets. Hence why I recommend going with Winforms (or other) for now. Writing widgets isn't particularly interesting (and one day when "AI" gets better, I look forward to getting an entire suite of these things generated!)
Click to expand...
I see, then I am going to try out Winforms, hopefully replacing Avalonia since it is kind of on a brink.
Hopefully it is not as complex as QT, changing between each major version.
 
You must log in or register to reply here.
Back
Top