Live-share: Allow hosts to share desktop windows

[lostintangent]

Live Share’s collaborative debugging support is language and platform-agnostic, and therefore, can be used when working with other devs on web apps, desktop apps, mobile apps, etc. However, in addition to just sharing an active debugging session, there are many times when it’s valuable for guests to be able to view and interact with the running app itself. The shared servers feature enables this for web apps/APIs, and databases, and shared terminals would enable this for CLI/console apps and automation scripts.

To achieve a similar experience for desktop apps (including mobile emulators), hosts would need to use a screen sharing technology such as VNC or Skype. While these products work great for this already, we may find that an integrated solution has benefits, and could explore a “Share Window” capability.

[lostintangent]

Hey everyone! We’re beginning to think about this item, and would really appreciate some feedback on the following things:

1. What kind of app are you building that would benefit most from this feature? (e.g. WPF, WinForms, Electron, native iOS mobile app, Unity game, etc.)

2. Would it be sufficient/valuable if guests were only able to view the running app (like a live “app stream” of the host’s actions)? Or would they need to be able to interact with the app (e.g. click buttons, enter text into form fields) in order for this to be useful?

Understanding these a bit further will help inform the scope/design of this feature, and whether we’d need to potentially do other work to fully optimize the target scenarios (e.g. Woukd WPF collaboration be great due to being able to share an app window, but without a collaborative XAML designer?). Thanks in advance!

[douglasmiranda]

I'm using Live Share, I'm simply amazed by it!

Since I'm always coding something that will be shown in the terminal or browser Live Share provide everything.

Now for sharing other windows, I guess in order to be consistent with the other features that terminal/port sharing, we should be able to interact in a "read/write" way.

One thing I think it would be useful and maybe ""easier"" to implement (although it would not replace the window sharing) is a quick screenshot sharing, displaying on vscode.

[ghost]

What kind of app are you building that would benefit most from this feature? (e.g. WPF, WinForms, Electron, native iOS mobile app, Unity game, etc.)

We develop for WPF and Electron so support for both of these would be brilliant.

Would it be sufficient/valuable if guests were only able to view the running app (like a live “app stream” of the host’s actions)? Or would they need to be able to interact with the app (e.g. click buttons, enter text into form fields) in order for this to be useful?

I can see it being useful to have a view-only option, but I think the real power will come when collaborators can interact with the app. For example, when we are smoke testing something to try and iron out a bug we need to be able to click around.

Would WPF collaboration be great due to being able to share an app window, but without a collaborative XAML designer?

We rarely use the XAML designer, we simply edit the XAML directly and keep the designer view closed.

[lostintangent]

@tomntech Thanks! So it sounds like for your uses, we could optimize WPF/Electron development fairly well by adding this feature? Out of curiosity: are you using VS or VS Code for the Electron development?

[ghost]

@lostintangent we use VSCode for Electron dev.

If you need a beta tester, give me a shout. Happy to test some stuff out as it’s in dev.

[lostintangent]

@douglasmiranda Thanks! For your scenarios, do you have a need for being able to share arbitrary windows? Or would shared servers/terminals satisfy your development workflow already?

[lostintangent]

@tomntech Will do! Actually, one other question: what use cases are you currently using Live Share for? You mentioned smoke testing, and I just wanted to make sure I understand a bit more about your scenario. Thanks!

[douglasmiranda]

@lostintangent The thing is, I thought it was essential for me. Then I came to the conclusion It wasn't.

But even though it's not essential for me, I'll be watching this issue too in order to understand the others' needs.

[ghost]

@lostintangent We use Live Share for a couple of things. Firstly, pair programming. The intended goal of the pair programming session could either be to deliver new functionality or to walk through functionality that has been developed to bring another team member up to speed. Secondly, when diagnosing an issue we use Live Share to independently navigate the code base to identify potential problem areas and then collaborate on a particular section to try and resolve the problem.

[lostintangent]

@douglasmiranda Great, thanks for confirming that for us! 👍

@tomntech Perfect! I think we're on the same page, and I'll ping you when we have something to explore further here. Thanks again for the feedback!

[codycraven]

With a distributed team, my primary goal is to eliminate the need of running Google Meet or a Slack call to perform pair programming. The only item requiring me to continue running those applications (in addition to Live Share) is unrelated application sharing (essentially a screen share).

Most often the application we need to share is a browser window or an application like Postman (and sometimes others). There's a big difference between sharing a port and looking at a page/interface together (with the same view).

Additionally, I often will pull up documentation while working with another developer so that they can see how I constantly refer to doc and look things up.

These scenarios could certainly be read-only for my team's use, especially if there's a way for the viewer to click or draw on the window to indicate an area of the window to look at (not for the viewer to invoke an action).

[lostintangent]

@codycraven This is really great feedback! Postman and browser sharing are good examples of where desktop sharing could be valuable to non-desktop development scenarios.

What are you using for chat as well as initiating the Live Share in the first place (sending the session URL)? I only ask since you mentioned wanting to eliminate Google Meetup and Skype entirely, so I’m just curious how you’re addressing those currently, and how we might be able to simplify that even further (e.g. integrated chat, the ability to directly invite someone into a Live Share session in-tool).

[codycraven]

@lostintangent our primary chat is Slack, however we do have access to Google Chat as well.

I have been impressed with the Slack extension identifying invites sent via Slack (an unexpected benefit of installing the Live Share Extension Pack), but wasn't something I was specifically looking for.

What I'd really like to eliminate is the need to get on a call on Slack or Google Meet (both of which support screen share). Our current workflow currently involves a developer inviting another developer to either a Slack call or Google Meet. Once audio is connected then the dev will typically share their screen then send a Live Share invite. Then we begin pairing.

If the screen sharing could be supported in Code then we could eliminate the need for Meet/Slack
call since Live Share can support audio already, we're just using Meet/Slack audio since we'll need to screen share anyways.

Even with this support we may run into one other issue which is disconnection issues we seem to encounter with Live Share. Due to our workflow, when Live Share disconnects we still maintain audio connection. Live Share disconnect happens if I add a directory to my workspace, open another directory (switch repo), or even just the occasional disconnect. This problem will be much more noticeable if we're using Live Share for our audio.

[lostintangent]

@codycraven So if we address the disconnection issues, and added screen sharing, it sounds the Live Share extension pack combination would suit your team’s workflow fairly well then?

It’s unrelated to this issue, but when do you find yourself adding another directory to a workspace during a Live Share session? If you start out sharing a back-end project and want to pull in the front-end (or vice versa)? This is a known limitation with our multi-root workspaces support, and it would be really helpful to understand this scenario a bit more.

[codycraven]

@lostintangent Live Share already is an essential part of our workflow. My team members actually stopped using other IDEs just so they could use Live Share. These are absolutely nit picky pain points that if solved would improve our workflow.

All of our work is developed as services, so the need may arise when working on backend and needing the frontend (or vise versa) or when working on a backend service and needing to make changes to another backend service (as a dependency).

It would seem to me (as an outsider not knowing the codebase or architecture), that if this is a real problem for your users it might be possible to run Live Share as another application and have it attachable to Code/VS instances. If it is possible, this would allow collaboration sessions to be started and have audio/screenshares persist across Code reloads.

[mittalyashu]

_(My opinion)_ Adding the feature of sharing the desktop windows will lose the focus of live share. There are many tools out there which we can use to share screen.

[MatFillion]

I'm interested in seeing UWP apps when debugging through "Live share". It is possible through other applications but the experience is far from seemless. We are using the XAML Hot Reload feature so seeing the app you are debugging is essential ;) As a first step, even if the "external collaborators" can't interact with the UWP app, just seeing it would be a huge step.

I'm also interested in Xamarin.iOS and Xamarin.Android scenarios (see or interact with the emulator/simulator)

[Massimo37]

I completely agree that this would be a great addition to add to LiveShare 👍