Janek Kozicki <[email protected]> writes: > Jeremy Hankins said: (by the date of Mon, 25 Oct 2010 08:06:15 -0500) > >> Ok, how about: >> >> (get-window-by-id 0x3000024) > > user> (get-window-by-id 0x3000024) > ()
If it's nil, then nevermind about the rest. As far as I understand it, that means that sawfish has no idea that window exists. Why that would be I don't know, but I'm at a loss as to how to troubleshoot further. >> And anything else you can think of. But I'm just grasping at straws >> here. I suspect you're right, that sawfish has simply forgotten >> about the window for some reason. For all I know (if sawfish really >> is just confused about this window) you'll only get a segfault from >> this. So take appropriate precautions... ;) > > Thanks a lot. I'll try that in few days, as soon as I can afford > restarting sawfish, risking loss of coordinates of few hundred windows > :) And risk losing about 1h putting them into their right positions. Yeah.... But as I said, don't worry about it if sawfish can't even find the window given the X id. Without a reference to the sawfish window info I don't know what to suggest. The only other avenue I can think of would be to try to figure out what conditions trigger the problem. Having lots and lots of windows is evidently one part, at least, but evidently not enough in itself if you ran fine for a while without the problem showing up. Is this the first window that starts when you start sawfish? You could, for that matter, restart sawfish and see if it recognizes the window on restart. As far as I know positions (other than tabbing, perhaps?) will be preserved. If you have a way to trigger X events (e.g., refresh, or uniconify) that bypasses sawfish, you could try that as well. -- Jeremy Hankins <[email protected]>
