Closed daniel-lerch closed 4 years ago
I love to see that you think about supporting Linux.
I am on Linux and I was able to get Vocup running, yet I had to remove
<System.Windows.Forms.ApplicationConfigurationSection>
<add key="DpiAwareness" value="PerMonitorV2" />
</System.Windows.Forms.ApplicationConfigurationSection>
From the app.config as Mono does not seem to support it, and it causes a exception and crash when its there.
The only other thing I have noticed is that making a change in the settings is not persistent across restarts. I dont know if this is a Linux only bug as I dont have a Windows machine to test this on.
The Settings on Linux are only saved when the Vocup.exe.conf
file is removed, when this file gets deleted .net starts to save the settings one makes into a file in .local/share/VectorData/Vocup.exe_Url_<some hash>/user.config
.
I do have experience in C#, even though I havent programmed in it for 2 years. If you need help on the Linux side, I could try to help.
Thank you for bringing up this topic with your fork. This week I spent some time optimizing Vocup for Mono but I still have issues, especially in terms of rendering and scaling. Because .NET Core 3.1 supports Windows Forms I have tried out a second solution using a self-contained app together with Wine. I had to remove some features and it still crashes sometimes:
None of these two ways are perfect for Linux but a full rewrite of Vocup with Avalonia will take much time. Which solution looks more interesting for you as Linux user?
Looking forward to Vocup 2.0 with Avalonia it would be great if you could contribute. It is not only about writing C# code but also about finding easy ways of deployment. For Windows I'm already using the Microsoft Store and #2 will bring a setup and zip file, but for Linux there are many different packet formats like DEB, RPM, Flatpak and Snap.
I would prefer the right one as it has the Icons, yet the left one has better readability of the Text.
Also I much prefer to use the tools I have on my system rather then to use Bundled stuff. I think this disliking is primary due to Electron based applications that bundle Chromium, and one having 30+ Chromium binaries on a system without the need of so many.
For packaging, I am using Gentoo Linux so I build most of the software from Source. But when I search for software that is pre-compiled I have a certain way I prefer packages:
I dislike Snap and the way Canonical tries to force you to use it, so I dont use software that is Snap only. (An Ubuntu Server update from 18.04 to 20.04 forces you to install Snap, and I dont understand why, this is why I currently test CentOS and think of migrating xD)
During the times when I used Ubuntu Desktop, I would prefer DEB before Tar binaries. I have a little bit experiance in Packaging as I have my own Ubuntu package repo with my own software.
(I am in the way to phase out my repo though as I moved from Ubuntu to Gentoo in February and I dont see any use in keeping that repo alive.)
As for my fork. The Master branch only has a code-cleanup done by IntelliJ Rider with default configurations. My custom branch only has my preferred settings and the setting I mentioned prior removed.
I will stay with .NET Framework for Vocup 1.x as .NET Core is causing too many problems on Windows and Wine. Building the .NET Core application did not work with Wine when I tested it for the last time and the output is a bundled runtime with 281 files of 130 MB.
The missing icons will be fixed with a future Mono release (mono/mono#17800). You could try to build libgdiplus from master to fix this problem. If it works I could add this step for Linux installation.
A very interesting alternative is to run the classic .NET Framework version of Vocup with Wine Mono. It looks even better than .NET Core on Wine, does not crash, contains only 9 files and can be built on Linux. The only problem with Wine Mono is that it fails to connect to GitHub API to search for updates with a TLS error.
Vocup should have limited support for Linux with v1.7.2 via Mono or Wine.
For native Linux and macOS support see #18.