On Sun, Oct 23, 2016 at 02:44 (+0100), Dominik Vogt wrote:
> As a little bit of explanation how to read this output:
Thanks for the tutorial!
>> cre: 935(1) 0(2) 985(0)x1080(0) fw 0x00401005 w 0x06200031 ew 0x06200031
>> 'Adobe Reader'
> ^^^ ^^^ ^^^ ^^^^ ^^^^^^^^^^
> X Y Width Height Internal window id
> These are the values from the COnfigureRequest, i.e. the message
> that was generated when the application tried to change the window
> geometry. If the number is parentheses after the value if zero,
> that bit of information is unused, if it's non-zero, that part of
> the geometry was requested.
> This request looks sensible, and from that I guess your screen is
> 1920x1080 pixels (16:9).
One of my screens is, yes.
>> cre: 0(1) 0(2) 3276(4)x1048(8) fw 0x00401005 w 0x06200031 ew 0x06200031
>> 'zshguide.pdf - Adobe Reader'
> "Move window to +0+0 and resize to 3276x1048"
> The width looks weird.
The combination of the internal laptop screen and the external monitor.
(As you probably know at this point.)
>> cre: 0(1) 0(2) 3286(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031
>> 'zshguide.pdf - Adobe Reader'
> Similar, but some decorations seem to have been taken into
> account. From the requested height I assume your window window
> border is 5 pixels thick and the window title is 22 pixels high.
Sounds about right.
>> cre: 65529(1) 65481(2) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew
>> 0x06200031 'zshguide.pdf - Adobe Reader'
> ^^^^^ ^^^^^
> The program has added space for another border around the window
> by subtracting some pixels from X and Y and adding some to Width
> and Height. The coordinates have become negative, but the program
> seems to store them as "unsigned short", not as signed int as it
> should. So it gets a wraparound and requests some astronomically
> huge coordinates (which the X server limits to 16 bits again).
>> cre: 0(0) 0(0) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew 0x06200031
>> 'zshguide.pdf - Adobe Reader'
> "Resize window (without actually changing its size)
>> cre: 1433(1) 65517(2) 985(4)x1080(8) fw 0x00401005 w 0x06200031 ew
>> 0x06200031 'zshguide.pdf - Adobe Reader'
> Back to the original size with what looks like random coordinates:
> 1433/18.
> So, is this what you see, a window starting at X=1433 with a page
> that is about 3300 pixels wide?
No. Well, maybe hard to tell. The window was occupying the lower
right part of the external monitor, so perhaps it carried on to the
right off the screen for (wild estimate) 3300 - 1400 pixels.
On Sun, Oct 23, 2016 at 11:13 (+0100), Dominik Vogt wrote:
> On Sat, Oct 22, 2016 at 11:26:26PM -0300, zli...@ns.sympatico.ca wrote:
>>> If you have multiple monitors, please describe the geometry of
>>> this setup (coordinates and size of each monitor and on which one
>>> you expect the fullscreen window to appear).
>> Acroread (annoyingly) always starts spread across both screens. In
>> the above examples, I dragged it completely to the 1920x1080 screen
>> and then typed ^L to get it to go full-screen.
> At least this should be easy to get under control. Try
NOTE: I tried these by starting a FvwmConsole window and entering them
there, rather than editing my config file. If that is the Wrong Thing
to do, let me know and I'll do the experiment again.
> Style acroread fixedppos, fixedpsize
[fvwm][style_parse_and_set_window_style]: <<ERROR>> Bad style option: fixedppos
Style acroread fixedpsize
Doesn't help.
> If that doesn't help, try adding
I tried adding your line below (sort of, see below) and then the
EWMHIgnoreStateHints below, and it didn't work. So I restarted fvwm
and first tried this:
> Style acroread fixeduspos, fixedussize
Style acroread fixeduspos, fixedussize
[fvwm][style_parse_and_set_window_style]: <<ERROR>> Bad style option: fixeduspos
So then I tried
Style acroread fixedussize
> (You may or may not want the fixed...size bit.)
Not sure I understand that comment in its fullness. Sorry if I am
being thick.
This allows acroread to go into full screen mode, with two problems:
(1) it is spread across both screens, which is fairly useless, and
still isn't like the other programs I use which go into full
screen on just one screen, and
(2) I haven't mentioned this before, but another "feature" of acroread
in 2.6.6 is that once in full screen mode, it becomes
unresponsive to keyboard input. I can scroll with the mouse
wheel, but keyboard commands are ignored.
(I should have mentioned this, but it was sort of a moot point if
full-screen mode isn't working anyway.)
> And if that doesn't help either, try
> Style acroread EWMHIgnoreStateHints
> (but that will probably prefent fullscreen mode from working.)
> There's also this annoying EWMH feature that allows windows to
> activate themselves at any time. You may want to remove that or
> replace it with debug output when an application tries to do it:
> destroyfunc EWMHActivateWindowFunc
> addtofunc EWMHActivateWindowFunc
> + I echo Ignoring EWMHActivateWindowFunc $[w.id] $[w.name]
> --
> I'm now trying to identify the commit with which this strange
> placement started. Do you know of any other commit ids or dates
> between 2.6.5 and 2.6.6 that were definitely fine or broken?
No, but I see you have identified it yourself.
Thanks for all your efforts on tracking this down.
