Chromebook support

[askvictor]

OK - definitely in the long-term category. But given how many schools are using chromebooks, think about how many students are potentially missing out on mu :)

A few possible approaches, in (IMHO) decreasing order of feasibility:

• Linux apps on Chromebook: https://blog.google/products/chromebooks/linux-on-chromebooks/ - Google recently announced this, and you can currently run Android Studio on the Pixelbook (more laptops, including some educational focussed models seem to be available as well: https://www.xda-developers.com/apollo-lake-chromebooks-acer-asus-lenovo-dell-linux-app/ ). Does anyone has any connections with Google to see what's involved in getting this happening?
• Create an android app and use the Chromebook's android app layer. Qt5 can play Android (http://doc.qt.io/qt-5/androidgs.html) but I have little idea if it's just a matter of re-compiling, or redesigning. Then there's the whole python layer as well which complicates things considerably - though termux provides a full linux userland.
• WebAssembly

[askvictor]

On further investigation, it looks like it shouldn't be to hard to get running using the first approach (Crostini is the internal name for the linux container system). I'll be able to get my hands on a compatible chromebook soon so will have a play at getting it running. At this stage, I think USB support is non-existent, but that's being worked on. How this will look in an educational setting is still pretty fuzzy - I don't think there will be any enterprise-level controls for this for a while yet, and distribution will need to be considered (i.e. distribute an entire container, or just a deb)

[ZanderBrown]

Mu is a Python project so creating a creating an Android app would probably be complex and IIRC QWidgets isn't supported on Android and it would be a lot of work to rebuild in QtQuick which would probably require us to use PySide not PyQt (?)

WebAssembly is awesome but in one sense seems a little overkill and we would have to rebuild Qt + QScientilla + Python in WASM & somehow run Mu on top of that which seems like a lot of work (and I imagine the end result would be quite fragile)

Targeting the Linux support seems the best and should already work but would require the pip based install (at least until Mu is packaged in Debian and things trickle through), I believe Google is considering Flatpak support which should be doable (I've played with that in the past) and school friendly

[askvictor]

I've successfully got mu running on a chromebook under crostini (after first having to install pip, then sorting out a dependency problem as per #502). It would certainly be nicer to be able to install it more easily, but I think its a matter of waiting and seeing how Google implement enterprise management for crostini, as this will be the main way mu would be deployed in schools using chromebooks - once we know that, then package it up in an appropriate way.

micro:bit doesn't work yet as there is no access to the USB system from crostini, though if it were possible to download the .hex (as python.microbit.org does) then it's possible to drag this across to the microbit (from the linux filesystem to the USB device) using the stock chromeOS file manager.

[electronstudio]

Would this crostini method work on an ARM chromebook, or just Intel?

[askvictor]

No reason it shouldn't; mu is written in python so there's nothing architecture specific. Some of the dependencies might be a little trickier, but should still work. I think I got it running on a Lenovo n23 a couple of months ago but can't remember (I had some problems getting crostini running reliably on the device, and can't remember how far I got)

…

On Sat., 27 Apr. 2019, 2:47 am Richard Smith, ***@***.***> wrote: Would this crostini method work on an ARM chromebook, or just Intel? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#593 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANF7WRBYT7LUIPBMAVQHSLPSMW2ZANCNFSM4FMWRCPA> .

[carlosperate]

The main area that could be problematic is getting PyQt5 running on that platform. If crostini allows you to use Linux with a debian base then you should be able to install those dependencies using apt, the steps should be very similar to the Raspberry Pi instructions.

[electronstudio]

It's an Acer R13 belonging to a student, which supposedly supports Crostini in stable channel, but in practice the student got some error and couldn't even get Crostini to install. I will try it myself next time I see them.

[askvictor]

I've just noticed that the requirements.txt (https://github.com/mu-editor/mu/blob/master/requirements.txt) includes the following line:
qscintilla; "arm" not in platform_machine
along with some more similar. Does this mean that qscintilla is not a requirement for when installing on an ARM device, and it needs to be installed seperately?

[carlosperate]

Yes in that it needs to be installed separately, but it is still a requirement, just not one that can be installed in ARM platforms via PyPi.
That's why the Raspberry Pi instructions ask to create a virtual environment with the --system-site-packages flag.
https://mu.readthedocs.io/en/latest/setup.html#raspberry-pi