Feature/net6

[brunzefb]

This is an alpha level implementation of QMK Toolbox using .net core/Avalonia UI framework. I only have one MCU, so my testing is limited. This version has no HID console, No Keyboard Tester, No menus. It supports the main UI and Auto Flashing.

Description

This is new code, based on the Windows version. The UI has been completely re-written using the Avalonia (WPF). This uses the MVVP pattern, and ViewModels, unlike Windows Forms can be easily unit tested. The USB detection code has been substantially changed as there is no WMI on Linux. The USB library I am using unfortunately does not seem to provide events, so a polling of known devices is done. There are some UI changes, like the Hex File control is not a combo. This is intentional, in the old version it was easy to mess up the path, not sure about multiple entries there.

I hope this can be reviewed by the community, so that we can make it more functional. There are a number of TODO items in the code.

The .net code can be published ad self-contained, meaning no .net framework would be required on the target machine. It also needs an installer and published packages to apt, yum aur etc, or as a flatpak.

Even though this is cross-platform, the code was written with Linux in mind only, more work would be needed to make it truly cross platform. (e.g. resources for all platforms). If this codebase gets feature-parity with the mac and windows ones, one can think about using this as a single codebase supporting all three platforms. The benefit is that all changes happen in one place, and apply to all platforms. I have a mac, a Windows box and Linux.

Some MCU's seem to mount like a thumb drive and one copies the bin file to the device. On linux the problem is detecting which vendor and product id maps to the newly mounted drive. lsblk lists the devices and journalctl log tells you this info, but needs root access to view on most systems. I have no good solution to this yet.

The Avalonia FileOpenDialog is broken (or I am to dumb to get it to work) - I am using a script to accomplish this.

The current code does NOT handle the BCD Revision properly, more work is needed in the UsbListener.cs class. USB Detection happens with polling all the known devices, and is done in a background thread. The Show All usb devices functionality is not supported.

COM Port detection will likely not work for AvrIspDevice and the like; I don't know enough about how this is supposed to work to fix it. Right now its hard-coded to /dev/ttyS0.

UI strings would need to an update to pull from resources which would make a localized app possible, but perhaps thats not needed here.

There is no CI/CD integration yet, one needs the .net core sdk to build.

Dependency versions of nuget packagesneed to be moved to Directory.Build.Targets, and props to Directory.Build.props.

Documentation (readme) changes would need a separate PR once this is in beta. Binaries would have to be packaged into the release as well.

The missing feaures should be easy to add.

To build and run:

1. Install the .net framework sdk 6
2. Check out the PR
3. cd to the [root]/linux/QMKToolbox folder
4. dotnet run # this will restore, build and run the GUI app.

Types of Changes

• [ X ] Core
• Bugfix
• [ X ] New feature
• Enhancement/optimization
• Documentation

Issues Fixed or Closed by This PR

• Issue Linux ever? #59 Linux Ever?

[brunzefb]

This is for reviewers to get an idea of the work. I am making more changes, will squash the commits and kill this PR and open a new one when closer.
I have added:

• Menus
• Updated the UI.

I am working on a better detection logic for USB devices, and fix the bcdDevice issues in the code.
The embedded resources won't (flash programmers) will not work as is-- in order to use their installers patch the /etc/udev/rules.d to allow non-root direct access to those usb ports. The embedded binaries are just a convenience anyways - its not hard to install a package for a specific flasher. One would have to analyze all the flash programs for dependencies and add those too - I feel like this is a lot of duplication.
2023-01-03 Update: I got the FileOpenDialog to work properly on Linux, and updated the USB detection code. For the checkbox size, the control template needs to be replaced with a custom one. This is an issue in the menus. The databinding in the menus is still not ok.

[brunzefb]

@fauxpark Any chance you could have a look and give me some feedback on this?

[brunzefb]

@jackhumbert Any chance you could have a look and give me some feedback on this?

[zvecr]

While I understand you wanting feedback, please refrain from pinging users. You have pointlessly selected one who is not active on this project.

Someone will get round to this when they have time.

[brunzefb]

Fair comment. All part of knowing project etiquette. We all work on things as time allows, same for me. This is a significant feature, and I am blocked until I get some feedback.

[tzarc]

I have some concerns:

• As it stands, the Windows build has random modifications to files and does not compile
• I see no reason why we would want to maintain two concurrent C# codebases when Avalonia is capable of supporting both Windows and Linux
• Bundling prebuilt executables is going to be fraught with danger -- there are significant constraints on the expected runtime and are going to be very distro-specific -- different glibc versions, different multilib- or non-multilib distributions, even different underlying libc implementations such as musl being used by the distro will cause program loader failures.
• The "safer" option to me would be to preinstall system-provided binaries -- in most cases they'll have equivalents available, such as avrdude and dfu-util -- you could likely replicate the prerequisites from here.

The biggest concern I have is what QMK Toolbox gives people that the CLI doesn't -- between qmk flash and qmk console, 90% of the functionality is already available on Linux as it is, especially now that qmk flash accepts binaries directly, instead of requiring full compilation.

We do appreciate the work that has gone into this implementation, and we're not saying "no" -- we're just querying the validity of some of the decisions. We usually prefer to discuss such large-scale implementations with potential developers before they embark on such work -- primarily so things don't get developed when the direction may not be consistent.

[brunzefb]

Avalonia supports all three platforms, mac, windows and Linux. This is an example of a cross Platform File manager. Work is required to make things run properly under all three OS's, but the example project shows how to go about it. One needs WPF and C# knowledge to make this work.

For me, having one code base, and one that supports unit testing is preferrable to 3 code bases - in keeping with the DRY principle.

Installing the drivers with the appropriate permissions automatically is nice for the user, but more of a convenience. Windows installs ALL drivers for known MCU's because it does not ask which one you use, typically one. On Linux, the programmers are installed by a distro-specific package, which typically allow-lists that programmer exe to access the USB directly without root access. One can compile from source on linux too. The programmers are simple, if the required .so dependencies are there, and you have the right CPU arch, it typically runs without issues, but one could test that with Virtual Box.

I did this Proof of concept mainly for myself - I want to conveniently program my keyboard under Linux with auto-flash. Yes, I can run a makefile to do this without QMK, but its more cumbersome. With QMK, I just reset my keyboard and it automatically flashes. I have achieved that goal, its running under Linux. I am sharing the code with the community. Treat it as a proposal, this PR is not intended to be merged. I am willing to work with this community to try to make one codebase possible, if the community wants it. If not, that's perfectly OK, no hard feelings. I also dont want to become the sole dev on this.

As I was coding this, I tried reaching out, but over the holidays people were busy with other things. Lets have the discussion then about what to do.

[brunzefb]

I'm a bit disappointed that a discussion is not taking place about if, and how to possibly move forward with this PR. If I don't hear something soon-ish, I will withdraw/close the PR and assume the larger community does not have an interest. This is OK, no hard feelings in that case.

[tobico]

@tzarc

The biggest concern I have is what QMK Toolbox gives people that the CLI doesn't -- between qmk flash and qmk console, 90% of the functionality is already available on Linux as it is, especially now that qmk flash accepts binaries directly, instead of requiring full compilation.

From the official docs:

The simplest way to flash your keyboard will be with the QMK Toolbox.

I would prefer to be able to do things in a simple way instead of having a more difficult experience because I'm using Linux. Thanks <3

[fauxpark]

Flashing instructions for all supported bootloaders can be found here: https://docs.qmk.fm/#/flashing

Given the issues with this PR that tzarc outlined above, I'll be closing this for the moment. The main blocker IMO is that unless and until the Toolbox gains the ability to call flashing tools external to itself (which I tried to push for here), the "Linux version" will not "just work" on any given distro. Of course we could gather the flashing tools from a bunch of different distros, but as you can see this is already a maintenance nightmare for just Windows and macOS.

I would prefer if we did not have to bundle the flashers at all, but this then calls into question the very purpose of the Toolbox...