Re: Debugging window-placement interactions

What exactly are you seeing? Are the windows simply not moved to the
correct locations? Are they not moved at all?

What *might* be a solution is to use the window rules to disable the
window history/storing of the location. Sawfish tries to restore the
locations/sizes of windows out of its history, this might interfere
with application. You can also clear the existing history through the
window ops menu (the Sawfish window menu).


On Thu, 18 Jun 2020 16:58:10 -0700
Geoff Kuenning <[email protected]> wrote:

> I'm using a program (pdfpc) that creates two full-screen windows 
> on different monitors (xinerama mode).  Unfortunately its approach 
> to window placement doesn't seem to mesh correctly with Sawfish.
> 
> My current solution is to use window-matching rules like the 
> following:
> 
>    (((WM_NAME . "^pdfpc - presentation"))
>     (ignore-program-position . #t)
>     (position 1920 . 0))
>    (((WM_NAME . "^pdfpc - presenter"))
>     (ignore-program-position . #t)
>     (position 3840 . 0))
> 
> which works, but is clumsy since I have to edit the rules whenever 
> I switch to a different display layout.
> 
> From digging into the pdfpc source, it appears that it first 
> creates each window and then moves them to their final locations. 
> (I'm not 100% certain of that; it's a Gtk application and there 
> are a lot of layers.)
> 
> I tried sniffing the X11 connection with Wireshark but didn't 
> learn much.
> 
> Is there a good way to figure out what requests are being made to 
> Sawfish and why it's not placing things where the application 
> asks?  (FWIW, I tried modifying the above rules to set 
> ignore-program-position to #f, without luck.)


-- 
Sawfish ML