Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow hosts to share desktop windows #236

Closed
lostintangent opened this issue Apr 24, 2018 · 21 comments
Closed

Allow hosts to share desktop windows #236

lostintangent opened this issue Apr 24, 2018 · 21 comments

Comments

@lostintangent
Copy link
Member

lostintangent commented Apr 24, 2018

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
Copy link
Member Author

lostintangent commented Sep 6, 2018

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
Copy link

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
Copy link

ghost commented Sep 6, 2018

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
Copy link
Member Author

@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
Copy link

ghost commented Sep 6, 2018

@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
Copy link
Member Author

@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
Copy link
Member Author

@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
Copy link

@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
Copy link

ghost commented Sep 6, 2018

@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
Copy link
Member Author

@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
Copy link

codycraven commented Sep 16, 2018

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
Copy link
Member Author

lostintangent commented Sep 16, 2018

@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
Copy link

codycraven commented Sep 17, 2018

@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
Copy link
Member Author

@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
Copy link

@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
Copy link

(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.

@fubaduba fubaduba pinned this issue Aug 23, 2019
@aletsdelarosa aletsdelarosa unpinned this issue Oct 14, 2019
@MatFillion
Copy link

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
Copy link

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

@iTrooz
Copy link

iTrooz commented Jul 13, 2021

I don't think this has been discussed anywhere, so here is my suggestion : why not allowing the guest to run code from his own computer ?
I know (think) that as of now, the files are not saved on the guest computer. Maybe an option "download the entire project and run code locally" would be a solution.

In general, I think this would be better for developers because we are (at least that's how I feel) expecting the code to run on our own computer sometimes.

@adamvanaken
Copy link

@iTrooz this, or something similar, feels like the right approach. If a colleague and I are trying to pair-program a WPF app, for example, we probably both already have the means to run the project (build-chain eg.). The Live Share guest just needs to be allowed to execute the project.

Mikejo5000 added a commit that referenced this issue Feb 2, 2022
@fubaduba
Copy link
Contributor

We’re not able to prioritize this issue over the other higher-impact issues we receive every week, based on the votes and comments from others in the community and our understanding of the issue. We understand this may be disappointing; we've all been there, whether in this project or others we've contributed to. However, rest assured that we love your input. If you feel it deserves to stay open, then clarify your use case and contact us to let us know how severe it’s for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests