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

Stream existing electron apps #48

Open
sabrehagen opened this issue Sep 5, 2019 · 1 comment
Open

Stream existing electron apps #48

sabrehagen opened this issue Sep 5, 2019 · 1 comment
Labels
question Further information is requested

Comments

@sabrehagen
Copy link

From Ben's Medium writeup:

It’s important to note that in our solution, an app is simply any online resource that can be accessed and rendered in a browser by a configurable unique URL.

I'd like to use browserd for streaming existing electron apps, for example postman and dot. These apps would run in a container on a server and be streamed to a browserd/stream-consumer. This goal appears to be fundamentally different to the intention of the project which is for streaming a URL accessible web app, not an existing electron app.

From your experience on this project, do you know if it's possible to achieve my goal? Essentially SERVICE_URL would point to an electron app, however an electron app is not addressable by a URL.

@bengreenier bengreenier added the question Further information is requested label Sep 16, 2019
@bengreenier
Copy link
Owner

Short answer is yes this is possible, but requires some changes (not sure the size of em just yet, either).

The changes

await winProvider.createWindow({
would have to go, as we won't create a browser window ourselves to host the experience. then the captureWindowTitle would need to be passed, and match the window name of the process you want to capture.


which eventually chains to the actual window enumeration and filtering logic:

const matchedDevice = rawDevices.find((e) => e.name === captureWindowTitle);

At that point, you should be able to grab the window frames. The last tricky bit is mapping input, and i'm not sure our current approach allows doing this across different input windows...you'd have to see if this code

this.webContents.sendInputEvent(evt);

that uses the sendInputEvent call works on processes that aren't owned by our application handle. If it does work, great input is easy - our code may even just work. However, if it doesn't...

Well, if our existing input approach doesn't work you've probably got to look at shelling out to some OS helper that can simulate input on an OS scale. I played with xdotool a bit - it might be capable of doing such a thing.

I'd be happy to field questions for this type of work (probably via this issue thread) if you (or anyone else, for that matter) wants to give this a go.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants