Support for Multi Monitor Development

[nkiranrao]

Today layout can only be adjusted/docked within the primary Electron window or the browser page, however I think it will be very useful to allow the tabs in the IDE to be made detachable such that user can take that tab to the other available screens connected to the PC. Most of the modern IDE do provide this features. Can this be achieved given that its also not possible in the VS. Code built on Electron?

[hexa00]

Actually this should be possible with theia more than anything else (vscode etc). Since theia is based on a frontend/backend concept.

You can launch multiple tabs or multiple electron instances of theia one per monitor and it will work fine.

Work would need to be done however to support the drag & detach action.

[hexa00]

Also for now the electron version will still run 2 backends but this can be fixed in the future. We could check if there's a local instance running already and connect to that.

[hexa00]

Seems like electron supports this directly see: https://electron.atom.io/docs/api/screen/
So there may be no need for a second instance.

[svenefftinge]

We can for sure open multiple browser windows (with or without electron) but a view might have dependencies to other extensions and more importantly their state. So I guess it's not going to be so easy, unfortunately.

[hexa00]

But it's ok if you reset the layout no ?
All important state should be in the backend anyway?
So if you drag an editor out to another window the layout is reset on that window but you still have the editor.

[svenefftinge]

There's lots of important state in the frontend (e.g. selection, keybinding context, editor and document registry, etc.).

[hexa00]

I think we had discussed this a bit before but this would mean Theia does not support multiple clients on a backend no ?
I seem to remember you wanted that to work...

[svenefftinge]

It works with multiple user sessions, but then each frontend has their own independent session. This ticket is about extracting a view or editor into a separate window that still would be part of the frontend application it used to live in.
I'd love to see this working, too. It is just not so easy.

[hexa00]

Right OK.

[eliasvasylenko]

Okay so state-sharing issues mean we can't just deploy a front-end module into a separate window and expect it to work. This is not a problem with a straightforward solution, so we probably need a different approach.

So let's say all our basic front-end modules will still deployed in the "main" window in the same context. In this case all the state is still in the same place, a view just needs to support being presented remotely in a separate window.

I am not super familiar with the architecture of Theia, I don't know how views are contributed and if remotable presentation of (some) views can be implemented transparently against the existing plugin API. I suspect not, at least not in all cases, so let's say for the sake of simplicity that this isn't an automatic magical process; a view must implement some new (optional?) API to indicate that it supports remote presentation, otherwise it can't be dragged out of the main window.

Putting the burden on the plugin implementor does make for some duplication of work, but maybe this can be minimised with supporting API.

Does this sound feasible/desirable? Are there any alternatives?

For a simple reactive-loop style UI we're probably just rendering a single lump of html/virtual-dom with a few callbacks, and those callbacks should probably just be passing data/pure functions to some kind of dispatcher. In this case we can still render the view in the "main" window, we just serialize our html/virtual-dom and send it to a separate window to be materialized by a super-thin client. In turn this client implements a dispatcher which forwards actions/intents/whatever back to the main window, thus closing the loop.

[akosyakov]

It is interesting feature and it is feasible but it is quite involving to implement. Consider just navigation between Monaco editors, you will need to provide custom editor service in another window which forwards navigation via the host window. I would expect that the generic infrastructure is implemented by a framework and use similar communication patterns and so on, but since it is quite a refactoring it should be done by some experience Theia maintainer to avoid disturbance in the platform. Right now focus is on getting VS Code extensions compatibility done, later we can consider to implement it.

[koegel]

We are exploring options for solving this issue and will build a POC. For starters we also work on a workaround, see #9926

[sdirix]

I would like to suggest to close this issue in favor of #10526 if that makes sense to the community.

[vince-fugnitto]

Closing in favor of #10526.