Linux Support

[Sirbucket]

You need to create a configure.sh file for linux support in order to make a makefile to install the program. WINE version cannot detect hidden files due to using a crappy file manager so no steam files.

[Sirbucket]

Basically you need to either rewrite the program to support linux or you need to change how to find files so the WINE version will work, I'd recommend creating a window where you can type the path to custom.

[CriticalFlaw]

I'm not opposed to adding Linux support, but I don't have the spare time to set up a Linux machine to develop and test this right now. If anyone else wants to take this one, they are welcome to do so.

[SlawekNowy]

This is a .NET 5 program using WPF. WPF internally uses DX9, which is already emulated by Wine. Nobody made the proof of concept yet.

Alternatively we can replace WPF with Avalonia.

Hidden files start with a dot in Linux. To avoid cross-distro imcompability we need to use ~/.steam/root symlink and go from there.

[gmemstr]

Taking a look into what can be done to natively support this. WPF not being available on Linux is a major blocker so we might need to do something else? Unsure, still in early stages of poking around.

[CriticalFlaw]

Perhaps the upcoming .NET MAUI will be the way to go. https://docs.microsoft.com/en-us/dotnet/maui/what-is-maui

[gmemstr]

Certainly seems like a good way to go, but there is no mention of Linux on that page, and I can't find any evidence that they want to support it.

[CriticalFlaw]

I should have read more into it before posting it here, my bad. You're right, it looks like Microsoft is still holding a grudge against Linux and purposely making it hard to support it. Linux features are being built into Windows but it's a one way street.

[gmemstr]

So I guess the question is, are we okay with moving to a totally different UI library/framework? It doesn't seem like there are any that are drop in replacements but I'm willing to put in the legwork to make the transition if that's something you're okay with @CriticalFlaw.

[CriticalFlaw]

I'm honestly not too keen on switching frameworks for this purpose. Instead I'm wondering if having a companion web app would be a better alternative. We may be able to carry over more of the code and have it be accessible for everyone.

[gmemstr]

A webapp would be neat, sort of the same vein as the Toonhud customiser? I 100% agree that switching frameworks isn't the best move in this case, especially since the interface for each hud is generated so it's not a super straightforward port.

[CriticalFlaw]

Could this run on the Steam Deck OS w/proton?

[PoorPocketsMcNewHold]

You mean to say wine, as Proton is not meant to be used for Applications, really.
After installing Microsoft DotNet in the wine prefix (Create a prefix, install it via the Windows installer, as it seems winetricks doesn't support this version), it works fine.

Is perfectly able to work with the native TF2 linux directory (It's not really that different, however, you should consider renaming the downloaded hud folders to lowercase as it is case-sensitive !)

The checkboxes aren't visible however Seems a classic .net 6 thing

Note the little selection box.
The application, however, is unable to make any modifications to the downloaded HUD.

[CriticalFlaw]

@PoorPocketsMcNewHold Interesting. Thank you for looking into it. Could you please do a write up of how you set it up in Linux? It will be useful for other users who are on it.

Will need to see how the checkedbox and modifications can be fixed for that build. I'm sure the latter can be fixed someway

[DuendeInexistente]

You need to create a configure.sh file for linux support in order to make a makefile to install the program. WINE version cannot detect hidden files due to using a crappy file manager so no steam files.

Wine can work with hidden files, it's just disabled by default. Check the drive tab in winecfg.

[CriticalFlaw]

Need someone to download the latest from the master branch, compile and test in Linux. Just to get a better sense of where it's at currently.

[SlawekNowy]

Welp...

[slawomir@slawomir-hppavilionlaptop15cc5xx src]$ LANG=C dotnet build
MSBuild version 17.6.3+07e294721 for .NET
  Determining projects to restore...
/usr/share/dotnet/sdk/7.0.304/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(90,5): error NETSDK1100: To build a project targeting Windows on this operating system, set the EnableWindowsTargeting property to true. [/home/slawomir/TF2HUD.Editor/src/TF2HUD.Editor/HUDEditor.csproj]

Build FAILED.

/usr/share/dotnet/sdk/7.0.304/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(90,5): error NETSDK1100: To build a project targeting Windows on this operating system, set the EnableWindowsTargeting property to true. [/home/slawomir/TF2HUD.Editor/src/TF2HUD.Editor/HUDEditor.csproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.61

[CriticalFlaw]

Welp...

[slawomir@slawomir-hppavilionlaptop15cc5xx src]$ LANG=C dotnet build
MSBuild version 17.6.3+07e294721 for .NET
  Determining projects to restore...
/usr/share/dotnet/sdk/7.0.304/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(90,5): error NETSDK1100: To build a project targeting Windows on this operating system, set the EnableWindowsTargeting property to true. [/home/slawomir/TF2HUD.Editor/src/TF2HUD.Editor/HUDEditor.csproj]

Build FAILED.

/usr/share/dotnet/sdk/7.0.304/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(90,5): error NETSDK1100: To build a project targeting Windows on this operating system, set the EnableWindowsTargeting property to true. [/home/slawomir/TF2HUD.Editor/src/TF2HUD.Editor/HUDEditor.csproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.61

What happens if you set EnableWindowsTargeting to true in the project settings file as instructed in the error?

[SlawekNowy]

tf2hud.log
Really? Refs to windows exlusive bins?

[CriticalFlaw]

In Visual Studio, we have a post-build script to remove certain language files. Looks like the command to do so does not work on Linux. Try removing it and building again.

Here's the section in the csproj file: https://github.com/CriticalFlaw/TF2HUD.Editor/blob/master/src/TF2HUD.Editor/HUDEditor.csproj#L147

[SlawekNowy]

While now it runs, it does not like all "System.Windows" refs.

[slawomir@slawomir-hppavilionlaptop15cc5xx net7.0-windows]$ ./TF2HUD.Editor 
You must install or update .NET to run this application.

App: /home/slawomir/TF2HUD.Editor/src/TF2HUD.Editor/bin/Debug/net7.0-windows/TF2HUD.Editor
Architecture: x64
Framework: 'Microsoft.WindowsDesktop.App', version '7.0.0' (x64)
.NET location: /usr/share/dotnet

No frameworks were found.

Learn about framework resolution:
https://aka.ms/dotnet/app-launch-failed

To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.WindowsDesktop.App&framework_version=7.0.0&arch=x64&rid=manjaro-x64

This is clear due to dotnet/core#4743

[CriticalFlaw]

@SlawekNowy was this test attempted with wine?

[SlawekNowy]

No. Not yet. "dotnet build" packages native dotnet runtime into an application. I would need to package the windows one.

[SlawekNowy]

After "LANG=C dotnet build --os win" in project directory, run fails with:

0090:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0090:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0090:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0090:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
A fatal error occurred, the required library hostfxr.dll could not be found in [
Z:\usr\share\dotnet\host\fxr\7.0.9]
0138:fixme:advapi:RegisterEventSourceW ((null),L".NET Runtime"): stub
0138:fixme:advapi:ReportEventW (00000000CAFE4242,0x0001,0x0000,0x000003ff,0000000000000000,0x0001,0x00000000,000000000019FC90,0000000000000000): stub
0138:err:eventlog:ReportEventW L"Description: A .NET application failed.\n"
0138:err:eventlog:ReportEventW L"Application: TF2HUD.Editor.exe\n"
0138:err:eventlog:ReportEventW L"Path: Z:\\home\\slawomir\\TF2HUD.Editor\\src\\TF2HUD.Editor\\bin\\Debug\\net7.0-windows\\win-x64\\TF2HUD.Editor.exe\n"
0138:err:eventlog:ReportEventW L"Message: A fatal error occurred, the required library hostfxr.dll could not be found in [Z:\\usr\\share\\dotnet\\host\\fxr\\7.0.9]\n"
0138:err:eventlog:ReportEventW L"\n"
0138:fixme:advapi:DeregisterEventSource (00000000CAFE4242) stub

It seems that the path to hostfxr is a linux one. Howver no Linux path exists in the built json files. Let's try adding the .net runtime to wineprefix.

EDIT: That did not work. I have to bundle the whole dotnet runtime.

[SlawekNowy]

In linux we don't seem to bundle the whole runtime... That is pushed via special nuget packages

[SlawekNowy]

I fidlled some more. Adding "RuntimeIdentifiers" property to csproj (win-x64 and win-x86) fixed the problem.
Only self-contained builds are functional though.

[CriticalFlaw]

That shouldn't be an issue. I can mark a self-contained build as Linux specific. If this change works could you please 1. Create a PR for any changes that need to be included in the editor and 2. Do a write up of the steps needed to get this to running on Linux please?

[SlawekNowy]

Here's the thing. I presume the build I would publish would have no difference in functionality and stability as the Windows one.

This is due to a fact, that since .net core (and version 5 since) both use same underlying nuget package as an base overlay for such apps. Namely "Microsoft.NETCore.App.Host.win-x64" "Microsoft.NETCore.App.Runtime.win-x64". Internally Runtime package is copied without changes, and the AppHost one would have slight modification to run our compiled application.

Both ours and Runtime's code would be the same either way.

[SlawekNowy]

Plus now I don't even have TF2 installed right now.

[SlawekNowy]

In order to build that on linux (after removing the PostBuild step) you would have to run "dotnet publish -r win-x64 -c Release --self-contained". The command explicitely metions the RID of the runtime, configuration and the "Bundle the runtime" flag. Similiar command would be run on linux, but RID of the runtime would be by default "win-x64".

[SlawekNowy]

Additionnally the exported executable would not have an icon.

[SlawekNowy]

It's kinda worse: The executable on linux (for me) freezes on start with dxvk, or crashes without.

[SlawekNowy]

Funnily enough running build done on Linux in Windows works perfectly.

[SlawekNowy]

So we're going in circles.

[CriticalFlaw]

I think the conclusion is that unless we re-write the editor in a cross-compatible language there's no proper way to get the editor (in its current state) to work on Linux.

[Ristovski]

The only issue is the WPF GUI framework, which is not supported natively on Linux. Otherwise, there is nothing preventing it from running on Linux (that is, doing a dotnet build that targets native linux, instead of wine/windows).

Some projects opt into https://avaloniaui.net/ for this very reason.

[CriticalFlaw]

The only issue is the WPF GUI framework, which is not supported natively on Linux. Otherwise, there is nothing preventing it from running on Linux (that is, doing a dotnet build that targets native linux, instead of wine/windows).

Some projects opt into https://avaloniaui.net/ for this very reason.

A year late but thank you for the suggestion. I'm working on the next release (dev branch) and will see how feasible it is to adopt Avalonia into the codebase for Linux support