Atom on multiple unix displays


#1

I run atom both on my main display but also remoted so I can access my desktop from home. The remote server starts up my desktop on a new display server. Unfortunately if atom is already started on the main display trying to launch atom on the remote will cause the window to pop up on the wrong display.

I have to kill atom and restart it to get it to show up on the second display server and then I have the same problem when I get back to working on the main display.

Is there a way to tell atom to start a whole new process on the current display instead of asking the running process to open a new window?


#2

When you’re working on a single display at home, are you able to open multiple Atom windows?


#3

Yes. As long as I kill Atom I can open it up as many times on a single display. It doesn’t matter if it is remote or local.

Once it is open, windows will only open up on the display it was first started on.

Just to be clear these are separate display servers running on the same machine. Not dual monitors. I can actually open up my remote display on my local desktop, launch Atom and see the Atom window pop up on my desktop (and the reverse if I started Atom on my remote first)


#4

Does it work differently with Chrome? Have you tried any other Electron apps to see how they interact with your setup?


#5

Chrome works fine. I’m using the chromoting plugin as my remote desktop. I’ll try other Electron apps.


#6

I ran the hyper terminal and it opened on both displays fine.


#7

Ping. If you point me to the startup code I can take a stab at diagnosing. My guess is it is using the DISPLAY variable (or a library is) that is in the current env. Since Atom starts up as a singleton app and requests the current instance to launch the new window it would ignore the DISPLAY from the env that launched the second process.

The other culprit could be how Atom communicates to its current process. Interprocess communication on different displays should usually not jump boundaries as a user’s session is usually intertwined with their DISPLAY. If the communication mechanism shielded session boundaries Atom would start up, not see the process on the other DISPLAY and launch a new instance in the new session.

I was a long term developer and maintainer of DBUS, the Linux desktop communications bus and have a deep understanding of these types of issues. I’m wondering if you do the communications through shared workers and if they communicate across desktop sessions.


#8

I haven’t responded because I’m not an engineer or an Atom dev, so all I can do here is bring up the right diagnostics questions.

When a running Atom is given the instruction to open a new window, that’s relayed from the renderer process to the main process via IPC and is then handled by src/main-process/atom-application.coffee. Here’s documentation about how Electron handles windows.


#9

Cool great. Thanks. Is there a better forum to bring develop bugs to?


#10

As I suspected atom is using a single socket based on the username for communications with the path:

options.socketPath = path.join(os.tmpdir(), “atom-#{options.version}-#{process.env.USER}.sock”)

This should include @{process.env.DISPLAY} also if is set. I’ll file a pull request.


#11

https://github.com/atom/atom/pull/14093


#12

The repo is the only other place, and all the devs pay attention to it, so I tend to refer people to that when the problem is above my head.