Enabling Remote Development?

[Daniel-Abdi]

Hello,

I was wondering if you guys had considered enabling remote development with the new version of the Pro editor? My workload is based on containerized development environments, and usually I use VSCode to connect via the remote explorer and do all my development within the container. I was wondering if the same thing could be achieved with the LVGL Pro editor? Right now I have to either mount a shared volume on my container and try and work with it that way, or keep a local copy and sync via git. If I plan to do any development in WSL, I'd also have to run the editor within WSL rather than having just one version of the editor on my Windows machine. Any way this could be added as a feature in the future?

Thank you

[kisvegabor]

Hey,

Thank you for sharing your use case! @laszlobalint, @richardgazdik do you now if Theia supports it?

[laszlobalint]

Remote development is supported architecturally in Theia Editor, but VS Code’s specific Remote SSH extension workflow is not available out of the box.

[mrhubbs]

@Daniel-Abdi I strongly recommend the shared volume approach. The Editor's file-watching is very robust. I have had success using shared volumes for development in the past (although I haven't tried it with the Editor).

That should allow you to seamlessly editor the source files in the Editor. Would you need anything else? Do your projects have custom C code? (Which requires compiling in the Editor so it runs in the Editor live preview).

[Daniel-Abdi]

My projects do have custom C code, so compiling in the editor is generally required. I feel it's a bit cumbersome to have the entire build toolchain be in a containerized environment, and then have my debugging toolchain outside the container to be able to access it in some way, to be honest. With VSCode's remote development I can literally have everything in the exact same environment and do all my development there which is nice. I'll have to give the shared volume approach a shot, but I'd probably still have to have a VSCode session within my container to do all my debugging.

[mrhubbs]

@Daniel-Abdi Thanks for the response. I am still thinking this problem over and I'll get back to you.

[mrhubbs]

@Daniel-Abdi

I feel it's a bit cumbersome to have the entire build toolchain be in a containerized environment, and then have my debugging toolchain outside the container to be able to access it in some way, to be honest.

Let me see.. you have your build-for-target toolchain in the container. Then, to compile in the Editor, you must have installed the emsdk toolchain outside the container in your host OS. Lastly, you have your debug toolchain (3rd toolchain) and you'd like to have that inside the container as well (makes sense to me).

Okay, now I understand. Let me think... The Editor itself supports debugging in a VSCode-like way using the extensions llvm-vs-code-extensions.vscode-clangd and vadimcn.vscode.lldb. I'm not sure if that would change anything for you, though, you probably want to debug with your own toolchain that is similar to your target toolchain?

[mrhubbs]

@Daniel-Abdi We do have one option we can easily try.

The Pro Editor can connect to your container over SSH, install Node.js inside your container and run the entire Pro Editor backend inside your container (while the frontend continues to run on your host, connected over SSH). This might break something in our Editor - and it may also try to install emsdk inside your container if you compile. But it is a feature that is easy for us to turn on so you can try it.

Are you interested?

[Daniel-Abdi]

@mrhubbs

This does seem like an easy solution that'll provide exactly what I'm looking for. If it isn't too much trouble, could you try enabling it? Installing emsdk inside the container isn't really a problem for me so that's fine, but obviously if it breaks the editor then it isn't an option.

Thank you

[mrhubbs]

To be clear, having emsdk in the container will probably work. Having the Editor's frontend and backend split between different OSes might be the problem.

[mrhubbs]

I'll give you a Windows test build with this enabled in the next few business days.