>>>>> "Jules" == Jules Bean <[EMAIL PROTECTED]> writes:
Jules> Anyone have any experience of LyX with a dual-headed (:0.0 and Jules> :0.1) context? Jules> The following bug claims there is an XForms problem here: Jules> http://bugs.debian.org/119413 Jules> ..and we'd appreciate any evidence you might have either way. We did some work about a year ago to try to do the right thing when running on the non-default screen of the display (I assume this is what happens here). Obviously we had no way to check this. Here is the relevant information I found on the list: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg22347.html [the previous message mentionned here correspond to the time when we tried to fix it. Obviously we failed :)] Also, Schlomo Schapiro <[EMAIL PROTECTED]> sent a bug report about that a month ago (I cannot find it in the archives, sorry). I answered at the time but got no more details. He provided a gdb backtrace which points at #7 0x401524c9 in XLookupColor () from /usr/X11R6/lib/libX11.so.6 #8 0x805e2b9 in LyXColorHandler::getGCForeground (this=0x8374828, c=bottomarea) at ColorHandler.C:82 The relevant LyX code is if (XLookupColor(display, colormap, s.c_str(), &xcol, &ccol) == 0) { It seems to me that the parameters we use are alright. It might be some problem with different color depth on the different screens, but really I don't know much about X programming. However, he did not run lyx with -sync, so the backtrace may be bogus. What would be interesting would be to have a gdb backtrace obtained by running "lyx -sync" on the second screen. This may help understand where the problem lies. Hope this helps. Actually, if we had somebody both experiencing this problem and willing to dig into it, it is probably solvable. JMarc
