On Sun, Oct 23, 2016 at 13:25 (+0100), Dominik Vogt wrote:
> On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote:
>> On Sat, Oct 22, 2016 at 23:29 (+0100), Thomas Adam wrote:
>>> On Sat, Oct 22, 2016 at 07:26:50PM -0300, zli...@ns.sympatico.ca wrote:
>>>> On Sun, Jul 17, 2016 at 15:08 (+0100), Thomas Adam wrote:
>>>>> On Sun, Jul 17, 2016 at 08:38:10AM -0300, zli...@ns.sympatico.ca wrote:
>>>>>> On Sat, Jul 16, 2016 at 23:27 (+0100), Thomas Adam wrote:
>>>>>>> On Sat, Jul 16, 2016 at 07:10:24PM -0300, zli...@ns.sympatico.ca wrote:
>>>>>>>> I recently upgraded a computer from Slackware64 14.1 to 14.2, which
>>>>>>>> bumped by fvwm version from 2.6.5 to 2.6.6.
>>>>>>>> With the new system, when I ask Adobe reader 9.5.5 to go full-screen,
>>>>>>>> I get a window with no decorations, but it only occupies about 3/4 of
>>>>>>>> the screen, off to the lower right.
> I've found the problem but I don't know how to fix it in a proper,
> i.e. portable way. In FEvent.c we have this function
> void fev_sanitise_configure_request(XConfigureRequestEvent *cr)
> {
> if (cr->value_mask & CWX)
> {
> cr->x = (((int)cr->x) & 0xffff);
> }
> ...
> if (cr->value_mask & CWHeight)
> {
> cr->height = (((unsigned int)cr->height) & 0xffff);
> }
> ...
> }
> This tries to deal with an inconsistency between the X protocol
> and the Xlib structures: In the X protocol, in the
> ConfirureWindow request, X and Y are signed "INT16" quantities and
> WIDTH and HEIGT are unsigned "CARD16" quantities, while in the
> Xlib structures they are "int" or "unsigned int".
Too bad the Xlib and the X protocol people weren't talking to each
other :-)
> The code tries to cut off the excess bits from X and Y and does it
> wrong. With 32-bit integers, if cr->x is -1:
> ((int)-1) & 0xffff = 0xffffffff & 0xffff
> = 0xffff
> = 65535
> I'm not sure how to fix this. The easiest approach would be to
> cast these values to int16_t or uint16_t from stdint.h, but I
> vaguely remember there are some portability issues with the
> inttypes.s/stdint.h headers.
Would not the casts (short) and (unsigned short) do the trick?
(Admittedly, perhaps somewhere there is a machine whose "short" is not
16 bits, but...)
On Sun, Oct 23, 2016 at 13:36 (+0100), Dominik Vogt wrote:
> On Sat, Oct 22, 2016 at 08:36:10PM -0300, zli...@ns.sympatico.ca wrote:
>> On Sun, Oct 23, 2016 at 00:20 (+0100), Thomas Adam wrote:
>>> On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote:
>>>> I cloned the git version about 15 minutes ago and compiled it, and
>>>> acroread still does not go full-screen correctly.
>>> Can you reproduce this using a more accessible program, please? I'm using
>>> FreeBSD.
>> No, I can't. That is, all other programs I use which have a
>> "full-screen" mode work fine.
> Can you please try out the branch "dv/fix-cr-merging" tha I've
> just pushed and see if the fix works for you? (For me, it does.)
And it does for me.
Mostly. (Close enough that I am happy.)
What is slightly weird is that if I have the acroread window wholly
contained on my laptop screen and go into full screen, the window
warps over to the external monitor. This does not happen with (e.g.,)
firefox or xournal.
Having said that, this fix takes care of my primary need, so I am
happy. But if you have another patch which might take care of the
warping-to-other-screen behaviour, I'll be happy to test it.
Thanks for all your efforts.
P.S. If anyone can suggest an fvwm setting so that acroread initially
opens with its window on the same screen as the mouse, rather than
split across the two screens, I'd be happy to hear it. (As might
other acroread users.)
