Re: Debugging window-placement interactions

What I was seeing was that the both windows appeared on the 
monitor that the cursor was on when I launched the program.

However, the pdpfc maintainer has now offered a cure: there's an 
option to deal with the issue.  From the documentation:

       move-on-mapped
              Dual-monitor  full-screen window placement is a 
              tricky business.
              Some window managers (e.g., FVWM) ignore the 
              placement  if  made
              before  the  window  is  shown. This option enables 
              a workaround
              (bool, Default is false).

If I understand the code correctly, when this option is enabled, 
it waits for a GTK map-event and then issues an explicit request 
to move the window to its correct location.

So, problem solved.  Thanks for the help!

> 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
>

-- 
    Geoff Kuenning   [email protected] 
    http://www.cs.hmc.edu/~geoff/

XML: verbose obfuscation in the service of simple key-value pairs.

-- 
Sawfish ML