Automatic download+execute of a program on Chromebook (and other platforms?)

[agordon]

First let me say that I like the "makecode" platform very much, and I'm excited to switch my students from LabView/EV3 to MakeCode. I've been using MakeCode for MicroBit with great success.

The MakeCode/Microbit recently(?) introduced the option to program the microbit directly using "pair device" option and the WebUSB API - making microbit programming even more fun.

I was wondering if/when you plan to use similar functionality for MakeCode/EV3.
Currently, programming requires downloading a .uf2 file then switching for file-viewer then drag&drop the file etc.
It's not the end of the world, but it's a show-stopper and I can't convince my co-teachers to switch to MakeCode because of it (given that LabView/EV3 works seamlessly, both with USB and with Bluetooth).

This relates to two issues:
First, @abchata's comment about "low criction", here: #873 (comment)
Second, an oppossite request about adding ability to download and store but not execute a program (#978).

Thanks!
gordon

[pelikhan]

Have you tried our Bluetooth support? https://makecode.mindstorms.com/bluetooth

[agordon]

Hello Peli de Halleux (@pelikhan) ,

I tried it - doesn't work from my chrome book.
When I click on the "download" button, then "bluetooth" button, the dialog box appears with
makecode.mindstorms.com wants to connect to a serial port but the
content of the dialog box says no compatible devices found.

I'm using EV3 firmware 1.10E ,
Chroms OS 79, "experimental features" flag enabled, the EV3 is paired to the chromebook.
For comparison, the Lego Mindstorms EV3 chromeapp (on the same chromebook) is able
to upload programs to the same EV3 brick - so it is not a bluetooth error.

But - no less important:
While using bluetooth is possibly nice when working at home, I expect it to become problematic
if used in a classroom with 15 kids. In FLL competitions, it is common for the organizers to ask teams to DISABLE bluetooth and use only USB due to interferences.
So even if/when bluetooth works - a USB-based solution is much preferable.

[JakubVanek]

This has most likely the same cause as #980