After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 226898 - evolution's behavior when DISPLAY is set remotely is wierd, to say the least....
evolution's behavior when DISPLAY is set remotely is wierd, to say the least....
Status: RESOLVED DUPLICATE of bug 224885
Product: evolution
Classification: Applications
Component: Shell
pre-1.5 (obsolete)
Other All
: Normal minor
: ---
Assigned To: Ettore Perazzoli
Evolution QA team
: 214230 225572 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-06-24 17:16 UTC by Jim Gettys
Modified: 2013-09-10 14:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Jim Gettys 2002-06-24 17:16:46 UTC 
Please fill in this template when reporting a bug, unless you know what you
are doing.
Description of Problem:


Steps to reproduce the problem:
1. Startup evolution on your local system
2. export DISPLAY=your.favorite.remote.host:0
3. Startup evolution again, on your local system

Actual Results:

evolution starts up again with its display on the local system, rather
than the remote host.

Expected Results:

That evolution should use the remote host..

How often does this happen? 

Every time.

Additional Information:

If you kill the local evolution, then it displays remotely (though the
display performance, even on a local net, is slow).
Comment 1 Ettore Perazzoli 2002-06-24 19:23:17 UTC 
It means that you are running Evolution on your local machine already,
and instead of launching another instance, it opens a new window on
the existing instance.

Unfortunately, it is impossible to get this working properly with GTK
1.2 since it doesn't have multi-display support.

We *could* run a new instance instead of using the existing one, but
then OAF would mess up (since it doesn't like multiple displays
either), and we would have to handle multiple instances accessing
~/evolution properly (which we currently don't do).
Comment 2 Ettore Perazzoli 2002-06-25 14:42:16 UTC 
*** bug 225572 has been marked as a duplicate of this bug. ***
Comment 3 Gerardo Marin 2002-10-03 17:06:33 UTC 
*** bug 214230 has been marked as a duplicate of this bug. ***
Comment 4 Rodney Dawes 2003-03-21 20:53:22 UTC 

*** This bug has been marked as a duplicate of 224885 ***