Please check if this behaviour is still reproducible in a more recent
build like a RC3 or RC4. Thanks !

Yes, this is still reproducible as of RC3 (Debian package).  I login
into one computer and pull up an OOo application.  Start a VNC session
to the same machine from a remote computer, and any attempts to open
another (or the same) OOo app cause the new window to appear on
display :0, instead of the exported VNC display :1

TM->PL: as far as I know we´ve had a problem with opening staroffice
tasks in different displays in the past. Can you please have a look,
if this might be the same ? Thanks !

As long as the applications insist that only one instance can run at
any  time this problem cannot be solved.

As Philipp mentioned, this issue won´t be fixed. Of course a wish for
an enhancement may be written instead of this issue.

So let's use this one ? The enhancement wish is clear; OOo should be
capable of running multiple instances out of one installation.

reassigning as enhancement to bettina

*** Issue 15448 has been marked as a duplicate of this issue. ***

I've just run into this today, as follows:

1)My desktop machine happens to have a copy of OOo running, with a document open.

2)I'm sitting at my laptop, and receive a word document by email. I scp it to
the desktop, and open it by running oowriter over SSH.(*). This normally
displays the document fine on my laptop's screen.

3)In this instance, the oowriter command simply exited, without appearing to do
anything (and of course, the document opened on the wrong display). 

As a minimum workaround, can I suggest that if the startup script detects an
existing Ooo process, but on a different $DISPLAY, it should print a message to
stderr. I understand the reason why the document opens in the existing process,
but the principle of "least surprise" would strongly suggest printing a message.
As well as stderr, display this message (on the expected $DISPLAY) via xdialog
(or kdialog, or zenity, whichever is installed).

A suitable message might be:
 
 "You have tried to open the file $DOCUMENT on display $DISPLAY (on host $HOST).
However, an instance of OpenOffice is already running on that machine (on
display $DISPLAY2), so this file has been opened in the existing OOo process.

[If you want it to open on this $DISPLAY, please close the other document.
killall -15 oowriter will force an auto-save]"

 #is that actually true about killall -15? I hope so, but I haven't checked:-)


(*)Why do I do it this way? The desktop is much faster, I have gigabit ethernet, 
and the laptop has an issue that clicking the file menu in Ooo usually causes X
to hang.

We've run into this issue using:

 - StarOffice 8 Update 10 ( ~ OpenOffice 2.4)
 - on Sunray thin clients
 - running Solaris 8 (10 as well)
 - multiple users logged in using the same login id on different Sunrays

Note that in this case, you have multiple login sessions for the same user on a
single machine, but each user has a different $DISPLAY environment variable.

In this case, the first user to open StarOffice is fine, but the second and any
subsequent users can't open documents since they display on the first user's screen!

We've tried setting -display and (after a bit of spelunking in the source)
-clientdisplay but neither overrides OO's single minded determination to open
everything on one display.

We *CAN* open separate instances if we use the the -env parameter as follows:
-env:UserInstallation=file://$HOME/.staroffice8/<some unique identifier>.

Unfortunately, this isn't a great solution for us because it would necessitate
maintaining a larger number of separate staroffice configs (e.g. printer setup,
first start wizard, etc.). This workaround might be sufficient for users who
generally use display :0 and occasionally want a second display :1. 

Found a similar complaint related to Sunrays in the general discuss forum:

START QUOTE
-----------
For example, I have an office with SunRay terminals on a Solaris server. If I'm
there and grab my smartcard (leaving the session running on the server) and then
later on login remotely through Sun Secure Global Desktop (as I would do if
suddenly called away from the office) I can't use OpenOffice! If I open OO from
my SSGD session, the window appears on my SunRay session!

That's just the most common instance where it's annoying. It does the same thing
the other way around, including not opening in the right place when opened in a
window in SSGD and Full Desktop SSGD session at the same time, when SSH sessions
used, etc. What makes it especially annoying is that I haven't run across any
other application that exhibits the same behaviour! All the other apps are smart
enough to open on the session that fired them off!
-----------
START QUOTE

still present in OOo 3, I just run into it ...

I've just found that it happens even between different users - i.e. when user A
is working on machine X locally and has some OOo application open, then user B
ssh from machine Y to machine X as user B, and then user B opens some OOo
application on machine X, the application is not displayed on machine Y using
x11 forwarding, but the newly opened application shows to user A on his display
on machine X, thus exposing user B to a GREAT SECURITY RISK!

Problem still exists in OOo 3.2 and Staroffice 9.2.

Why is this issue still marked as "UNCONFIRMED" 9 years after first being
reported, and after multiple reports on multiple operating systems?

Are there any plans to make Openoffice respect the $DISPLAY environment variable
like any other well behaved application?

To grep the issues easier via "requirements" I put the issues currently lying on
my owner to the owner "requirements". 

*** Issue 15229 has been confirmed by votes. ***

Can someone please fix this? In this age of virtual servers and remote desktops, 
this is a bigger problem and getting bigger.

I'll volunteer to fix it if no one has 8 hours to do it.