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".
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.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
