Date: Wed, 29 Jun 2005 09:08:48 -0700 From: George Hartzell <hartzell@kestrel.alerce.com> To: Joe Marcus Clarke <marcus@marcuscom.com> Cc: gnome@freebsd.org, hartzell@alerce.com Subject: Re: Nautilus, xemacs, ssh -Y, and BadWindow messages. Message-ID: <17090.51088.201114.461851@satchel.alerce.com> In-Reply-To: <1120031937.51150.98.camel@shumai.marcuscom.com> References: <17089.32512.242397.686389@satchel.alerce.com> <1120031937.51150.98.camel@shumai.marcuscom.com>
index | next in thread | previous in thread | raw e-mail
Joe Marcus Clarke writes: > On Tue, 2005-06-28 at 09:46 -0700, George Hartzell wrote: > > Hi all, > > [...] > > There are more details in the bug. > > > > ports/82498 > > [...] > > I think Nautilus is a red herring. The real problem is most likely > gnome-settings-daemon and its tendency to merge xrdb data into your > current environment. You could hack the xrdb support out of g-s-d, or > simply override the default Emacs resource settings with your own > ~/.gnome2/xrdb/Emacs.ad file. > I don't think that this is has anything to do with resource settings. You helped me work through that back in 2003, here's a pointer to the start of that thread: http://lists.freebsd.org/pipermail/freebsd-gnome/2003-October/003503.html In this case, I can start nautilus, kill a line in an xemacs and see the error, stop nautilus, kill a line in an xemacs and not see an error, start nautilus, etc.... Using 'xlsclients -al', the nautilus window id is the closest to the window id that's reported in the error message (they're always a bit off, which I assume has to do with the way that X apps are constructed in nested windows). For instance, I just generated a pair of error messages w/ the Resource id in failed request: 0x1c0034a xlsclients -al says that the window for Nautilus is Window 0x1c00001 xwininfo and clicking on the background says: xwininfo: Window id: 0x1c0002c "Desktop" xinfinfo -id 0xc0034a says there there is no such window. And, I just noticed that every time that I generate the error message the "Resource id in failed request" increments a bit (but not by the same amount).... I started messing about in the xemacs code, changing it to use the 'PRIMARY selection instead of the 'CLIPBOARD, and that also quiets the error (I'm not sure I'm using the terms PRIMARY, CLIPBOARD, selection, etc... in the completely correct technical sense). Using ssh -Y to connect back to the same machine doesn't seem to trigger it, but ssh -Y'ing into a jail on that machine does. I haven't been able to try it yet w/out using an ssh tunnel, just setting DISPLAY to point back to the host-machine's display. That's my next simple step. I'm pretty open minded at this point, it could be an xemacs problem, an ssh problem, or a nautilus problem (or, ssh tunnelling mucking up an improper window id that xemacs generates when it sees the Nautilus background window), or.... I'm just looking for suggestions for experiments to help characterize it. For instance, running nautilus with either --no-desktop or --no-default-window does not get rid of the problem. Any interesting debugging switches, sniffing methods, etc.... would be welcome. g.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17090.51088.201114.461851>