Rebase WPF onto master branch

[BinToss]

The WPF branch has become fairly desynced from the master branch, leading to a multitude of merge conflicts. Most are related to the Traditional Chinese and Russian locale contributions.

Contributors cannot create pull requests for this issue because the existing WPF branch will need to be completely overwritten with rebased commits.

---

Notes

• prefer WPF branch's README.md. All changes to README.md in master branch are in reference to the WPF branch.
• Adapt new translations (Russian, Traditional Chinese, Chinese Simplified) to WPF. Use ResX resources?
• Avoid modifying and renaming/moving files in one commit. Git can still infer renames/moves from file content that has little or no changes, but significant enough changes can make Git think the new revision of the file is actually a completely new file, breaking history for that file.

9b61869e changes as seen in SmartGit The files marked "modified" would instead be marked "renamed" or "renamed-modified". The "deleted" files would not be shown if the file contents were similar enough for Git to detect a "renamed" or "renamed-modified" change.

EDIT: I've taken a slightly more in-depth look at the initial commit of the WPF branch. So that's why there were so many conflicts! The first commit of the WPF branch merges the existing WPF project into the base project, removes the base project's resources, and modifies some classes to depend on WPF+SyncFusion instead of WinForms+SyncFusion.

[CodeDead]

Hi,

Thanks for you interest in helping out with this repo.

Do note that the WPF branch is experimental and was intended as an entire rewrite of the UI. However, as discussed in this issue https://github.com/CodeDead/DeadLock/issues/16 development on this branch is entirely halted and as such it will not be rebased or merged, but instead pruned. The master branch is the main one, every other branch is experimental for now. The WPF branch is not finished, nor ready for any kind of release or further development.

A rewrite using MAUI will be done when MAUI become stable, until then, the old translation process will still be valid.

[BinToss]

• https://github.com/dotnet/maui/discussions/2576 https://microsoft.github.io/microsoft-ui-xaml/about.html#controls

MAUI relies on WinUI3 for Windows targets. As such, the minimum Windows version it supports is Windows 10 Oct. 2018. Perhaps, in the future, older Windows releases will be supported via GTK bindings just like the community-supported Linux desktop targets.

The closest alternative is UNO platform which, as explained in the linked Dicsussion, tends to use a ton of memory. Aside from UNO, suitable (cross-platform) alternatives include Avalonia, GTK#, QtSharp, and Qml.NET.

For Windows-only apps that support Windows 7, WinForms and WPF are still viable even on .NET 6+.

[CodeDead]

.NET 6 upgrade would not bring any benefits to the table for DeadLock except for the marginal performance gains of .NET 6, which are trivial when it comes to this application because the end-user will not notice any of it.

If DeadLock is to receive an update, it will be a full rewrite of the UI and to gain the performance benefits of the new .NET framework together in a single update or a rewrite in something else entirely. C# isn't the be-all and end-all programming language. Nor is the goal to support older versions of Windows.

There are other options available besides the ones you mentioned. The Rust programming language, for example, is a perfectly viable alternative to .NET and can be compiled to WASM and combined with Tauri/Webview to deliver something truly unique whilst offering the benefit of not needing .NET at all. It would be tiny, perform well and not hog memory like Electron apps do.

But remember, the goal of DeadLock is not to be cross-platform as it would make no sense on macOS or Linux.