Feature Request: Chromebook support

[millerv]

Logging this on behalf of Ed Price at Microsoft

Per this article (https://www.yahoo.com/tech/why-google-is-beating-apple-in-the-battle-for-the-142410097.html), schools are moving away from iOS/Apple devices and onto less expensive devices that run Chrome OS.

There's discussion on a related Microsoft-educator Yammer group about how we need Visual Studio Code to work on Chromebooks and related devices so educators can continue using to for teach AP Java (or other languages) Computer Science courses.

Feel free to email me or Ed Price for more info.

[csinco]

We have a previous product that VS Code is based on, called Visual Studio Online "Monaco", that may be useful to start with:
https://azure.microsoft.com/en-us/documentation/videos/building-web-sites-with-visual-studio-online-monaco/

Problem is, it is only for Azure websites. You should talk with @chrisdias about how to move forward with this Chromebook scenario.

[javagg]

@csinco Is the Visual Studio Online still under development? I think Visual Studio Online is one of the best cloud-based IDEs avaiable on the web. But it does lack some feasures compared to c9 cloud ide. What's the future of Visual Studio Online?

[ghost]

Visual Studio Online is now called Visual Studio Team Services and would be a good way to do development on Chrome OS. It uses the same text editor under the covers as VS Code. It is not just a code editor but also hosted version control, continuous integration, work item tracking (bugs, kanban board), etc, so it's not exactly comparable, but if I were developing on Chrome OS that's where I'd start. Disclaimer that I work on the VSTS team.

[jasonnolanreed]

@AlaNouri I'm not seeing a browser-based IDE as part of Visual Studio Team Services. Am I missing something, or has it been removed since December?

Thanks!

[ghost]

@jasonnolanreed I wouldn't call it an IDE but rather a text editor. You get intellisense for some files, SCM integration, syntax highlighting, markdown preview, etc. To get to the text editor for a file:

1. "Code"
2. "Explorer"
3. Select a file
4. Click "Edit"

In order to save you have to commit, you can't open multiple files other than opening them in multiple browser tabs, etc, so it isn't really optimized for doing ALL your coding in. But if I were on ChromeOS I would be happy to have the functionality it has?

[TylerLeonhardt]

Just chiming in because I'm a big fan of VSCode and I'm looking at the Chromebook Pixel as a future purchase. VSCode on ChromeOS would be amazing. How difficult would this be? I know VSCode is built on Electron, right? Which means VSCode is just a packaged web app. How simple would it be to port that over to a Chrome App (https://developer.chrome.com/apps/about_apps)?

I have a feeling I'm over simplifying this.

[DanTup]

I'd love to see it too, but I don't see it ever happening. Electron won't run on ChromeOS and I suspect Chrome extensions are way more restricted than Electron (is it even possible to run processes without using NPAPI, which is being phased out?)

(that said, you can probably make this work via Crouton or similar already, if you don't mind maintaining a Linux install!)

[jasonnolanreed]

Hey Tyler,

I have a mint 2015 Pixel with the i5 I'm not using any more and looking to
get rid of. If you're interested, I could give you a good deal on it

On Sat, May 14, 2016, 5:09 PM Tyler James Leonhardt <
notifications@github.com> wrote:

Just chiming in because I'm a big fan of VSCode and I'm looking at the
Chromebook Pixel as a future purchase. VSCode on ChromeOS would be amazing.
How difficult would this be? I know VSCode is built on Electron, right?
Which means VSCode is just a packaged web app. How simple would it be to
port that over to a Chrome App (
https://developer.chrome.com/apps/about_apps)?

I have a feeling I'm over simplifying this.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1031 (comment)

[TylerLeonhardt]

Thanks @jasonnolanreed. This is the last place I thought this would happen lol. I'm waiting for after I/O as they might be giving them out :) I'll let you know!

[jasonnolanreed]

Fingers crossed for a freebie!

On Sat, May 14, 2016, 6:33 PM Tyler James Leonhardt <
notifications@github.com> wrote:

Thanks @jasonnolanreed https://github.com/jasonnolanreed. This is the
last place I thought this would happen lol. I'm waiting for after I/O as
they might be giving them out :) I'll let you know!

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1031 (comment)

[jrood]

chromeos support, yes please

[viniciuscr]

chromeos support could start with intel´s processors,
I guess it´s easier then arm´s one.

[antony]

Just compiled and run on an Asus Chromebook P100 using crouton/Ubuntu 17.04

Everything works fine except... no actual text editor.

So close yet so far!

[myfrom]

How about porting VSCode to Android? It should be easier as Android has far less limitations than Chrome and Chromebooks can run Android apps

[Leetcore]

They said no.
http://stackoverflow.com/questions/36290113/vs-code-for-android-is-it-possible

[catgirlinspace]

I'm supporting this!

[GitTom]

This shouldn't be too difficult as the Chrome Web App environment would act as the shell for VSC much like Electron does.

Whether MS wants this is another question...

[antony]

Currently using this: https://code.headmelted.com/ which works really well aside from missing the terminal autocomplete. Whatever he is doing, it should be trivial to incorporate.

…

On Thu, 16 Mar 2017, 19:39 GitTom, ***@***.***> wrote: This shouldn't be too difficult as the Chrome Web App environment would act as the shell for VSC much like Electron does. Whether MS wants this is another question... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1031 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANXRdL150ItTcXhN93xoMXvxHX8Ie8Sks5rmY-3gaJpZM4GvREb> .

[DanTup]

This shouldn't be too difficult as the Chrome Web App environment would act as the shell for VSC much like Electron does.

Code (and the extensions) are more than HTML/CSS/JS; they have access to all sorts of things that aren't possible in Chrome web apps (nodejs and even spawning arbitrary processes). For example the extension I work on spawns a Dart VM to run the analyzer that provides all of the language support. There's no way of running doing this on Chrome OS (you'd basically need to rewrite it in JavaScript and the performance would be terrible).

As much as I'd love to see this; I don't see how it would ever happen. Even if you somehow got the editor working; it'd need effort from all the extension authors (who would have to also redo all their work and in a far more restricted environment).

[kylecordes]

@DanTup Here is how I imagine it working:

Package VSCode as a ChromeOS app; this would provide the UI (but not the supporting background processes) in a manner similar to Electron.

Some (many? all?) of the primary included background processes are JavaScript programs, usually run on Node. Shim thing as needed (hand waving here...) to run those as web workers.

The above covers, I'm guess, a large swath of VSCode users.

To get the rest, the hard part is hosting non-JS code for background processes to support various languages/plugins/features. Ideas for this:

• JS-based x86 emulator - maybe crazy, maybe working for some cases (!).
• User provides access to a server somewhere, SSH to it, tunnel the data back and forth to run there.

Of course, it's easy to describe an idea in an issue comment, much harder to execute on it...

[DanTup]

Package VSCode as a ChromeOS app

I don't think describing it in one sentence makes it easy; I think it's a huge amount of work (and you'd probably have to ditch loads of functionality that Electron has that won't work in a browser).

Some (many? all?) of the primary included background processes are JavaScript programs

Definitely not all; Dart Code runs the Dart VM. Even if we didn't use it for the language service, what happens when the user hits F5 and we need to run their porgram (or compile it, etc)?

The above covers, I'm guess, a large swath of VSCode users.

I think you are being extremely optimistic.

JS-based x86 emulator - maybe crazy, maybe working for some cases (!).

Er... I think this is getting a bit out of control now!

User provides access to a server somewhere, SSH to it, tunnel the data back and forth to run there.

If you're going to require a server, you could just use Chrome Remote Desktop (etc.) and then you don't need to do any of this work; all extensions work; etc. ?

[kylecordes]

It is true... I don't have usage stats on plugins. I am curious what percentage of Code users, use only JS-based plugins (even if they have some non-JS-based ones installed).

[headmelted]

I'm still hoping to get the ARM support into a PR on this project so it can be added to the official builds. The big problem with this has been that Travis has a frozen whitelist of APT repositories on their system, hence my not doing it until now.

There may be another way around this using the repos that are available - I'm hoping to take another crack at cross-compiler alchemy this weekend to see what I can make happen.

[SteveDesmond-ca]

@headmelted See https://github.com/stevedesmond-ca/vscode-arm for how to cross-compile VSCode for ARM

[headmelted]

@SteveDesmond-ca Thanks but I was more referring to bringing across the multiarch targeting from https://code.headmelted.com into github/Travis so as to avoid the QEMU step, at least insofar as compilation (still using the chroot for testing), so as to keep on the right side of Travis timeouts.

[shawngmc]

I feel like, architecturally, the solution to this is to split the client and server.

The UI for VSCode should be largely browser compatible; it seems like the back-end process spawning, file system access, etc. is where it breaks down. If that were abstracted to be an API, backends could fulfill it at different levels. A windows backend can offer more windows specific things (for example, terminal provider selection for Windows Susbsytem for Linux OR Powershell OR classic cmd.exe) and raw FS / process access. A Chrome OS backend may not support terminal or run it in a VM, perhaps it only provides containerized file system access. A remote backend could be configurable.

It's less 'install-and-run' than VS Code is today, but the complexity only needs to be visible in these more complex modes. Guarding against / disabling UI elements for missing features would be a pain, and I don't think that Laptop client to cloud hosted backend would be particularly performant.

[clshortfuse]

Just going to chime in since I received the notification ping. It seems as though ChromeOS will allow some sort of virtualization layer for OCI containers to run in the background. Chrome Apps/Extensions can include their own OCI containers.

If VS Code does separate from Electron and uses an abstraction as I described before that allows it accept commands, then the UI can be presented in a regular web browser window. ChromeOS will include a VSOCK communication layer for communicating with the VM container.

https://chromium.googlesource.com/chromiumos/platform2/+/9e91613d2da1b3d6cfb1c77681444e688ce99cf4/vm_tools/docs/vsock.md

I suggest we wait a bit until we start any official work on building any OCI container, but in the least, separating VS Code from Electron and allowing interface from a web browser would be a good start. It'll even allow remote workstations as described in previous comments.

[svenefftinge]

We looked into using VS Code in a browser-remote-backend scenario. But the architecture doesn't fit well, because the communication between the renderer process and all the others is very fine grained and doesn't scale well over slower networks (internet).

So we started https://github.com/theia-ide/theia. We really like VSCode and use it every day so Theia is meant to be pretty close but supports the browser scenario. It's open-source, too.

[TUSF]

A year since the last post, and ChromeOS (at least on some models) can now run Linux applications in a container by just enabling a setting. The feature is still in beta (it's even displayed as "Linux (Beta)" in the settings), but VS Code appears to work pretty great on my end.

My only issue is that occasionally (usually when switching windows) the app goes crazy and starts typing a single letter as if the key is stuck, but this appears to be a bug in the Linux container, and not VS Code.

I'm not sure if there will be further need to actively try to support ChromeOS, as long as it works within the Linux container

[natevw]

I'm not sure if there will be further need to actively try to support ChromeOS, as long as it works within the Linux container

Many Chromebooks have ARM processors. Right now the cleanest solution there is still @headmelted's unofficial community build, which does work well with the containerized Linux. So I think things are close, but until there are official ARM builds available it doesn't seem like ChromeOS support is in place yet. (xref #6442, #33620)

[magic-k]

vscode for arm64 is only available from third party builders which also means no remote development extension support. As arm chromebooks are not very powerful, using them as a lightweight vscode machine to develop remotely in the cloud or on more powerful servers is one major use case for this.
And unless arm is a official target, extension developers don't care for them which means more and more ative components that don't work on arm.
So, yes for intel CBs this issue is solved (had been already way before crostini whith crouton) but for arm64 CBs this is still open.

[headmelted]

There's a few threads for this but I'm working to bring the ARM builds up-to-date after a gap due to some family matters.

If anyone has a point-of-contact at MS who can help with renewing the VS subscription they donated previously to help out with this (it expired) it would be a big help. I can work without it, but it means reworking parts of the build setup which will take time away from getting it up-to-date with the latest code.

[headmelted]

vscode for arm64 is only available from third party builders which also means no remote development extension support. As arm chromebooks are not very powerful, using them as a lightweight vscode machine to develop remotely in the cloud or on more powerful servers is one major use case for this.
And unless arm is a official target, extension developers don't care for them which means more and more ative components that don't work on arm.
So, yes for intel CBs this issue is solved (had been already way before crostini whith crouton) but for arm64 CBs this is still open.

This is a good point with regards to the extensions. One option to resolve this (although not ideal) would be to use QEMU transparent emulation in a chroot for extensions that are x86-only (there would be a performance hit though - how much impact this would have would depend on what the extension is actually doing).

[dimkr]

See https://github.com/dimkr/vscodium/releases https://github.com/VSCodium/vscodium/releases, I've been able to produce working arm64 builds of 1.40.2, from x86_64! It seems to work OK on my arm64 Chromebook. It starts just fine and I was able to install Go support.

The build process is in rough shape and very hacky, but works. Once microsoft/node-native-keymap#16 is merged, I'll be able to clean it up: node-native-keymap insists on building natively, so arm64 builds on x86_64 are contaminated with x86_64 assembly.

[headmelted]

Builds at https://code.headmelted.com are now up-to-date and rolling again!

I’m going to work on some instructions for the QEMU emulation as I’m not sure if it’s something that should be rolled into the builds for people that don’t need/want it.

[joaomoreno]

Hi all! Starting today we have archive, deb and rpm insider packages for Linux ARM 32 and 64 bits: #106289 (comment)

Looking forward to your feedback!

[joaomoreno]

Verified by having users run this on Raspberry Pis, Chromebooks, etc.