On a dual monitor setup as dual screens (no xinerama), if openoffice is already open in one monitor, you cannot open another document in the other screen - which defeat the purpose of a dual monitor set-up, as windows cannot be transfered in dual screen setup. PS:DISPLAY variables are set correctly. Reproducible: Always Steps to Reproduce: 1. Open a text document with OO on screen0 2. Open Nautilus on screen1 3. Opening an OO Calc document from nautilus on screen1. It will open on screen0 Actual Results: OO Calc document started from Nautilus in screen1 open on screen0. Expected Results: OO Calc document should open on screen1 where it was started. emerge --info Portage 2.1.2.2 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r5 x86_64) ================================================================= System uname: 2.6.19-gentoo-r5 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ Gentoo Base System release 1.12.9 Timestamp of tree: Tue, 03 Apr 2007 02:20:01 +0000 dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.3.5-r3, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib64/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=athlon64 -O2 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://open-systems.ufl.edu/mirrors/gentoo http://prometheus.cs.wmich.edu/gentoo " MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/disk0/gentoo/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/m199 /usr/portage/local/layman/xeffects" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X aiglx alsa amd64 berkdb bitmap-fonts bonobo bzip2 cairo cdparanoia cdr cli cracklib cups daap dbus divx divx4linux dri dvd dvdr dvdread dvi emboss encode fam ffmpeg fftw firefox flac font-server foomaticdb fortran gdbm gif gimp gimpprint glitz glut gmedia gnome gnomedb gpm gstreamer gtk gtk2 hal hddtemp iconv isdnlog jpeg kerberos libg++ libnotify lm_sensors mad metar midi mikmod mng mono mozbranding mp3 mpeg nautilus ncurses network nonfsv4 nptl nptlonly nsplugin nvidia ogg oggvorbis ole openal opengl oss pam pcre pdf perl plotutils png ppds pppd python qt4 quicktime readline realmedia reflection samba sdl sensord server session sftplogging smp spell spl ssl stream svg tcpd theora threads tiff totem truetype truetype-fonts type1-fonts unicode v4l v4l2 vnc vorbis wma wmp xml xorg xscreensaver xv xvid zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia vesa fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ----- Serverlayout section of my xorg.conf Section "ServerLayout" Identifier "Dual" Screen 0 "Screen0" 1600 0 Screen 1 "Screen1" leftOf "Screen0" InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection
Adding X-herd for some insightful comments about this
Are you running separate servers for each monitor?
No. This is only one X instance with 2 screens. I attached my xorg.conf below to explain my setup. Nb: I want to add that I can open the 2nd document on the 2nd screen if I use another user so a second instance of OO is started. But if I use the same user, it seems to "reuse" the location of the first document already opened.
Created attachment 115600 [details] xorg.conf of dual monitor setup
I'm not sure much can be done here. Both screens use the same display identifier (correct?), and so it's up to the window manager to place new windows on the appropriate screen. However, since OpenOffice probably gobbles the open event and opens the window itself, it's likely up to OpenOffice to instruct the window manager to put the window where it's supposed to go. So it's my barely educated opinion that it's OO's bug, and that there's not really any workaround available.
$DISPLAY is :0.0 for the first screen and :0.1 for the second one. I filed bug in here as I am not able to determine if it was an error from the window manager or OpenOffice.
(In reply to comment #6) > $DISPLAY is :0.0 for the first screen and :0.1 for the second one. > > I filed bug in here as I am not able to determine if it was an error from the > window manager or OpenOffice. > Ah, OK, what happens if you open the document from a terminal with the $DISPLAY variable set appropriately? Can you get the behaviour you want?
I don't understand your comment, I might not have been clear... the DISPLAY variable is set correctly !! :0.0 and :0.1 are the correct values for a 2-screen setup. Besides there is no problem opening a document on either screen as long as no other document is open. The problem only arises when a document is already open somewhere else in another screen.
I guess what I mean is make sure that DISPLAY is actually being set to the correct screen before the call to OO is issued. So if you open a terminal on both screens, ensure that DISPLAY is correct for each screen, then open a document on the command line from each screen, does it behave the same way as opening the document from the GUI? What I'm trying to determine is whether the WM is getting DISPLAY right or not when calling OpenOffice the second time. I suspect so from your descriptions so far, but I want to make sure.
Yes, all previous comments about $DISPLAY were obtained from checking in terminal. And yes calling from command line gives same result as from Nautilus. In clear, as long as OO is NOT running, everything works accordingly to DISPLAY. I can open OO wherever I want using DISPLAY. But if OO is running, DISPLAY is ignored - and new window always open on the screen that OO is already running on. ------ bug restated from command line From screen :0.1 > DISPLAY=":0.0" oowriter2 open correctly on screen :0.0 If OpenOffice is already opened in screen :0.1 From screen :0.1 > DISPLAY=":0.0" oowriter2 does NOT open on :0.0 but open on screen :0.1
Alright, thanks. I do think this problem is in OO's camp. You may want to open or find a bug in OpenOffice's bugzilla (or whatever they use) and see what they say. I'm removing x11 from CC - feel free to add us again if needed.
The problem is the same if you try and open OpenOffice across two different X sessions (:0.0 and :1.0 for example). I think OpenOffice tries to reuse the already existing instance of OpenOffice to open the new document instead of always spawning a new OpenOffice. Since windows can't span multiple X servers/screens AFAIK, this will obviously always fail.
I use xinerama, and I do not have this problem. Christophe; why not use xinerama ? because of composite ? Please make a test with composite disabled, and xinerama enabled. If success, I propose a "CANTFIX". I really think you get stuck on a limitation of X11r6. I think you should have the same problem with multiple windowed apps such as Gaim, Gimp, BSVC, Rox-Filer ... especially the single task/thread ones (check number of threads and tasks for each one before reporting they work or not). Please do this test for us. On my xinerama, all my screens are identified as :0.0; still, Enlightenment 16 and 17 offer me 4 different desktops. Rox-wm use a unified one. I never tried the big ones like Gnome, KDE, but from memory, they do not handle xinerama as good as E17 does.
This is really something to file upstream, nothing we can do here.
