You are browsing as a guest. Sign up (or log in) to start making projects!

10h 21m 50s logged

Oh my lord…I crammed a lot of features into this week. I have yet to do proper audits of the codebase as a whole, specifically related to latency optimizations. I added a lot more code that affects the WebRTC pipeline, but I at least got the core features working.


20. Automatic updates

For a while, the app relied on manual updating. It would check the latest version on Github, but users would have to go to the website, download the installer, uninstall the current version, and reinstall the newer version. This also messed up config and was a huge pain. Hence, I generated my own signing keys and used the Tauri updater plugin to automatically update apps. When the app is first launched and if an update is available, it automatically downloads and installs it without any user action.

To make this more robust, I added a progress bar while downloading the update. On Windows specifically, the app must be shut down and restarted, so a blocking modal prevents devices from joining till this is done. I originally made this modal manually, but switched to using AlertDialog from ShadCN.

Another issue I faced was the latest.json manifest. As I used custom filenames when downloading and installing updates, I had to manually patch the JSON. I learned a lot about the Tauri updater Github action through this, as I had to figure out how Tauri generated build filenames and how I could safely update them.


21. Quality of life for client devices

I finished QOL fixes on the client side:

  • Remember past devices to quickly import preferences or ban devices (all config saving is IP-based)
  • Warn if the user is attempting to connect from the same device (this app is a remote control tool, but you can’t exactly remote control yourself)
  • If the screen orientation changes, the virtual display is updated accordingly using CSS media queries to ensure a seamless experience
  • A no fullscreen mode was added so users could quickly switch apps and maintain productivity

22. Quality of life for host devices

I converted all in-app modals and error messages to JSON. This allowed me to add i18n language support, so I could easily translate my app to other languages.

To detect and ensure only a single instance of the app was running, I previously used a file lock. However, there was an issue with MSI builds falsely detecting a file lock and not opening. I switched to a basic TCP model for IPC so that multiple processes running can figure out which was there first and shut down the others.


23. More more more Mac features!

I’ve always felt a bit sad for my Mac users. I don’t have a Mac to test on, so I keep borrowing my dad’s Mac, which results in insanely slow development times. Nevertheless, I made some serious progress this week. The biggest thing was a simpler installation process. Many users would complain that they didn’t remember if they’re on Intel or Apple Silicon, so I now distribute a universal DMG.

In terms of the app itself, I added a permissions check for screen recording and input injection. It would run a live test of screen capture or key input to see if the app actually had permissions; therefore, down the road it wouldn’t cause issues. I initially tried to do a soft check without an actual test (i.e., read the settings app), but this didn’t work. The only foolproof way was to call the API itself.

The biggest feature by far was adding Mac input injection. Using accessibility APIs and a charmap similar to Windows, it would inject input onto the Mac screen. I could remotely log in from my Chromebook and get a lot of work done. I mirrored the structure and code on the Windows input injection pipeline, so no major difficulties here.


That’s it for this week! Lotta stuff added, especially for the Mac users. I have a long list of features to continue building, specifically regarding easier Windows uninstall processes, onboarding, and an overall better UX. See you soon!

0
34

Comments 0

No comments yet. Be the first!