bunch of improvements: MacOS Stylus, Virtual Key, Reconnect, etc.

[lyonbot]

• MacOS: support emulating stylus pen, with basic pressure support
• Web Client: support "virtual key" -- floating button to send keys
• Web Client: reconnect without reload page
• Web Client: improve point sampling rate with getCoalescedEvents()
• refactoring: use sass and esbuild to build frontend stuff

[electronstudio]

I made a build incorporating your patch along with the other patches here https://github.com/electronstudio/WeylusCommunityEdition

[lyonbot]

@electronstudio the "virtual key" feature just got updated -- user may design multiple layout profiles, and sync between clients now.

[electronstudio]

@lyonbot ok i'll update soon. I have Mac and Linux builds, but I would really like to get a Windows build working. Does my Mac build run? I don't have a Mac to test it.

[lyonbot]

Tested with two MBP:

• M1 chip: need sudo xattr -dr com.apple.quarantine ~/Downloads/Weylus.app then it works, but with some weird bug (i think it's bug from autopilot-rs -- can be fixed later)
• Intel chip: not works, the CI build is in ARM arch.

[electronstudio]

I assume the xttr thing is unavoidable unless someone signs the app with a dev certificate?

I think there is still one x64 image available on Github Actions so I can do an x64 build with that.

[lyonbot]

I assume the xttr thing is unavoidable unless someone signs the app with a dev certificate?

Yes, and i think a simple shell command is okay to most users.

I think there is still one x64 image available on Github Actions so I can do an x64 build with that.

Found a solution and will test again later.

And as for the weird mouse bug, still reviewing autopilot-rs 's code.

[lyonbot]

heck! a fork of autopilot-rs is still required :(

[electronstudio]

I'm having a couple of problems building on Windows. First, Windows doesn't have bash shell. I think I've fixed this by changing your build_www function (but there might be a nicer way, I don't know Rust):

fn build_www() {
    let www_dir = Path::new("www");

    #[cfg(not(target_os = "windows"))]
    let shell = "bash";

    #[cfg(not(target_os = "windows"))]
    let shell_flag = "-c";

    #[cfg(target_os = "windows")]
    let shell = "cmd";

    #[cfg(target_os = "windows")]
    let shell_flag = "/c";


    // try `pnpm` first, then `npm`
    if !www_dir.join("node_modules").exists() {
        let pnpm_install_success = match Command::new(shell)
            .args([shell_flag, "pnpm install"])
            .current_dir(www_dir)
            .status()
        {
            Ok(e) => e.success(),
            Err(_) => false,
        };

        if !pnpm_install_success {
            let npm_install_result = Command::new(shell)
                .args([shell_flag, "npm install"])
                .current_dir(www_dir)
                .status()
                .expect("Failed to run npm or pnpm!");

            if !npm_install_result.success() {
                panic!(
                    "Failed to install npm dependencies! npm exited with code {}",
                    npm_install_result.code().unwrap_or(-1)
                );
            }
        }
    }

    let build_result = Command::new(shell)
        .args([shell_flag, "npm run build"])
        .current_dir(www_dir)
        .status()
        .expect("Failed to build www!");

    if !build_result.success() {
        panic!(
            "Failed to build www! npm exited with code {}",
            build_result.code().unwrap_or(-1)
        );
    }
}

[electronstudio]

Second, I get three cases of

error[E0004]: non-exhaustive patterns: `PointerEventType::ENTER` and `PointerEventType::LEAVE` not covered

in autopilot_device_win.rs

I could fix them by making it return 0 or whatever in those cases but I don't know if that is safe to do.

[lyonbot]

Second, I get three cases of

error[E0004]: non-exhaustive patterns: `PointerEventType::ENTER` and `PointerEventType::LEAVE` not covered

in autopilot_device_win.rs

I could fix them by making it return 0 or whatever in those cases but I don't know if that is safe to do.

Can be ignored as NO-OP. These EventType are for MacOS tablet events only (yet).

[electronstudio]

Thanks, windows build seems to be working.

[lyonbot]

@electronstudio
added some fixes to make stylus work more smoothly!

The experience improves significantly on my budget Win tablet + Krita app on MacOS

[electronstudio]

Cool, added and sent you a PR with what I'm changing to get it to build on Windows.

[electronstudio]

@lyonbot apparently getCoalescedEvents() doesn't work on iOS, can it be made optional? electronstudio#7

[lyonbot]

@electronstudio fixed getCoalescedEvents problem. Sorry for being late, had tough weeks.

[electronstudio]

Thanks, no need to rush.

[electronstudio]

@lyonbot Whenever you have time... Seems there are exceptions being thrown on the web browser console since the changes from august 10th: electronstudio#10

[electronstudio]

I can’t speak for HMH but it might be easier to get this merged if you moved parts of it out into separate PRs. Even small parts.

[electronstudio]

Possible bug report: electronstudio#13

[H-M-H]

I've already incorporated getCoalescedEvents. A separate PR with pressure support on macOS would be much appreciated.

[lyonbot]

whoops. i even thought this project is abandoned. not sure whether easy. i'll make a try

[lyonbot]

separated as these PRs:

• feat: support stylus pressure in macos #289 -- stylus pressure in MacOS
• new frontend: click-to-reconnect + accurate coordinates on HiDPI pad #290 -- refractor frontend, in-place reconnect, improve resolution of cursor position on HiDPI pad
• feat: virtual keyboard  #291 -- new feature: virtual keyboard
• chore: ci build for MacOS arm + intel #292 -- ci building pipeline added MacOS Intel version