GNOME Bugzilla – Bug 237001
evolution command ignores --display= option if Evo already running
Last modified: 2004-12-22 06:17:13 UTC
Package: Evolution Priority: Normal Version: GNOME2.1.3 1.2.1 Synopsis: evolution command ignores --display= option if Evo already running Bugzilla-Product: Evolution Bugzilla-Component: Shell Description: Description of Problem: Evolution runs continuously on my workstation (host A) but when I occasionally need to read/write mail on host B in a different building I would like to remotely log on to host A and issue the command % evolution --display=B:0 and have a window pop on B's display. Currently, if Evo is already running on host A, the aforementioned command will only add windows on the display of host A. Currently I must killev and start Evo again, running on host A displaying on host B. Steps to reproduce the problem: 1. On host A, start Evolution 2. On host A, give the command 'evolution --display=B:0' 3. Actual Results: A new Evolution window appears on the display of host A Expected Results: It would be nice to have the window appear on the display of host B. How often does this happen? Always Additional Information: The --display option is only a means to an end. I would be equally happy with another way to achieve this functionality. I would also propose that if the application is asked to create a window on a different display than it is already running on and is incapable of honoring this request, that it write a message suggesting alternative ways of achieving this. Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
My guess at a fix would be that the protcol that evolution uses to contact existing instances of itself should be extended to pass the value of the $DISPLAY variable and then the new window should opened using that X display. with that in place remote logins via ssh with X forwarding would 'just work' since ssh sets the DISPLAY environment variable appropriatly. This is a problem with several gnome progs, I filed a bug against galeon for exactly the same issue.
*** This bug has been marked as a duplicate of 224885 ***