Re: regression from 2.6.5 to 2.6.6 ?

2016-10-25 Thread Dominik Vogt 
On Mon, Oct 24, 2016 at 09:59:56PM +0100, Dominik Vogt wrote:
> On Sun, Oct 23, 2016 at 11:39:14AM -0300, zli...@ns.sympatico.ca wrote:
> > On Sun, Oct 23, 2016 at 13:25 (+0100), Dominik Vogt wrote:
> ...
> > > 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.
> 
> I've overwritten the branch with a new, hopefully portable version
> of the patch.  Can you please try it again?

The fix is on master now, but master is broken at the moment.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-24 Thread zlists 
On Mon, Oct 24, 2016 at 21:59 (+0100), Dominik Vogt wrote:

> On Sun, Oct 23, 2016 at 11:39:14AM -0300, zli...@ns.sympatico.ca wrote:
>> On Sun, Oct 23, 2016 at 13:25 (+0100), Dominik Vogt wrote:
> ...
>>> 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.

> I've overwritten the branch with a new, hopefully portable version
> of the patch.  Can you please try it again?

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

> Is that something new or has it always been this way?

> I'll have a look at how acroread actually does the transition to
> fullscreen mode.  Maybe it's doing something differently.

I can only say that I'm 99% sure that is new with 2.6.6.  I tried it
on a desktop with two equal-sized monitors and it jumped to the
rightmost monitor (and my laptop's external monitor is to the right).

Maybe fvwm+acroread is some sort of right-wing sort of thing.  (One
might hope not, depending on one's views.)

Cheers.

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-24 Thread Dominik Vogt 
On Sun, Oct 23, 2016 at 11:39:14AM -0300, zli...@ns.sympatico.ca wrote:
> On Sun, Oct 23, 2016 at 13:25 (+0100), Dominik Vogt wrote:
...
> > 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.

I've overwritten the branch with a new, hopefully portable version
of the patch.  Can you please try it again?

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

Is that something new or has it always been this way?

I'll have a look at how acroread actually does the transition to
fullscreen mode.  Maybe it's doing something differently.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-23 Thread Viktor Griph 
2016-10-23 17:05 GMT+02:00 Dominik Vogt :
> On Sun, Oct 23, 2016 at 04:39:53PM +0200, Viktor Griph wrote:
>> Den 23 okt. 2016 14:36 skrev "Dominik Vogt" :
>> > void fev_sanitise_configure_request(XConfigureRequestEvent *cr)
>> > {
>> > if (cr->value_mask & CWX)
>> > {
>> > cr->x = (((int)cr->x) & 0x);
>> > }
>> > ...
>> > if (cr->value_mask & CWHeight)
>> > {
>> > cr->height = (((unsigned int)cr->height) &
>> 0x);
>> > }
>> > ...
>> > }
>> >
>> > 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) & 0x = 0x & 0x
>> > = 0x
>> > = 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.
>>
>> Instead of setting the excess bits to 0 we need to set them to 1 for the
>> negative case.
>>
>> What about
>> if (cr->x & 0x8000)
>> {
>> cr->x = (((int)-1) ^ 0x7fff) | (((int)cr->x) & 0x7fff);
>> }
>> else
>> {
>>  cr->x = (((int)cr->x) & 0x);
>> }
>>
>> The negative case could be simplified to
>>
>> (((int)-1) ^ 0x7fff) | ((int)cr->x)
>>
>> Or
>>
>> ((int)-1)<<16|((int)cr->x)
>
> I never can remember this; is it safe (in C) to assume that
> negative integers are stored in two-complement format?  (Of course
> the old code makes the same assumtion, but it's broken and I want
> to fix it.)

So use (~(int)0) instead of -1 and it should work for both
one-complement and two-complement numbers. The MSB would still mark
the sign. (If what the code is trying to fix is that there may be
extra bits beyond the 16 bits that are defined in the X-server, then
those bits could be anything, and maybe wouldn't guarantee that
negative numbers are correctly 1-padded above bit 16, in fact they may
not even have the int MSB set. If that is the case then I don't think
casting to int16_t or uint16_t would be feasible. The standard
mandates the int16_t to be in two-complement form even if the hardware
is using one-complement so casting from int to int_16t on a
one-complement platform would change the bit pattern in order to
maintain the value, but if the value is out of range for the 16-bit
number due to the excess bits you are trying to correct. I'm not sure
if the handling of overflow at a cast to xxx16_t is well-defined cross
all platforms.

>
> If it's really portable, the cleanest way is casting to int16_t
> and uint16_t from stdint.h.

Definitely. I just don't know if it is.

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-23 Thread Dominik Vogt 
On Sun, Oct 23, 2016 at 04:10:25PM +0100, Thomas Adam wrote:
> On Sun, Oct 23, 2016 at 04:05:03PM +0100, Dominik Vogt wrote:
> > I never can remember this; is it safe (in C) to assume that
> > negative integers are stored in two-complement format?  (Of course
> > the old code makes the same assumtion, but it's broken and I want
> > to fix it.)
> 
> It is not safe to make the assumption that negative integers are stored as
> twos-compliment.  C99 does not mandate whether that will be in
> twos-compliment, or ones-compliment.  Although most hardware will typically
> (in my experience) used twos-compliment, that's no guarantee.
> 
> So it's not portable; casting the values is the way to go.

Ah, the autoconf manual has some information in stdint.h:

  5.6.1 Portability of Headers

  ...

  inttypes.h vs. stdint.h

The C99 standard says that inttypes.h includes stdint.h, so
there's no need to include stdint.h separately in a standard
environment. Some implementations have inttypes.h but not
stdint.h (e.g., Solaris 7), but we don't know of any
implementation that has stdint.h but not inttypes.h. 

As far as I remember there was also an issue that inttypes.h does
not include stdint.h on all platforms, so we need configure tests
for both headers.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-23 Thread Thomas Adam 
On Sun, Oct 23, 2016 at 04:05:03PM +0100, Dominik Vogt wrote:
> I never can remember this; is it safe (in C) to assume that
> negative integers are stored in two-complement format?  (Of course
> the old code makes the same assumtion, but it's broken and I want
> to fix it.)

It is not safe to make the assumption that negative integers are stored as
twos-compliment.  C99 does not mandate whether that will be in
twos-compliment, or ones-compliment.  Although most hardware will typically
(in my experience) used twos-compliment, that's no guarantee.

So it's not portable; casting the values is the way to go.

-- Thomas Adam

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-23 Thread Dominik Vogt 
On Sun, Oct 23, 2016 at 04:39:53PM +0200, Viktor Griph wrote:
> Den 23 okt. 2016 14:36 skrev "Dominik Vogt" :
> > void fev_sanitise_configure_request(XConfigureRequestEvent *cr)
> > {
> > if (cr->value_mask & CWX)
> > {
> > cr->x = (((int)cr->x) & 0x);
> > }
> > ...
> > if (cr->value_mask & CWHeight)
> > {
> > cr->height = (((unsigned int)cr->height) &
> 0x);
> > }
> > ...
> > }
> >
> > 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) & 0x = 0x & 0x
> > = 0x
> > = 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.
> 
> Instead of setting the excess bits to 0 we need to set them to 1 for the
> negative case.
> 
> What about
> if (cr->x & 0x8000)
> {
> cr->x = (((int)-1) ^ 0x7fff) | (((int)cr->x) & 0x7fff);
> }
> else
> {
>  cr->x = (((int)cr->x) & 0x);
> }
> 
> The negative case could be simplified to
> 
> (((int)-1) ^ 0x7fff) | ((int)cr->x)
> 
> Or
> 
> ((int)-1)<<16|((int)cr->x)

I never can remember this; is it safe (in C) to assume that
negative integers are stored in two-complement format?  (Of course
the old code makes the same assumtion, but it's broken and I want
to fix it.)

If it's really portable, the cleanest way is casting to int16_t
and uint16_t from stdint.h.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-23 Thread Viktor Griph 
Den 23 okt. 2016 14:36 skrev "Dominik Vogt" :
>
> 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) & 0x);
> }
> ...
> if (cr->value_mask & CWHeight)
> {
> cr->height = (((unsigned int)cr->height) &
0x);
> }
> ...
> }
>
> 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) & 0x = 0x & 0x
> = 0x
> = 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.

Instead of setting the excess bits to 0 we need to set them to 1 for the
negative case.

What about
if (cr->x & 0x8000)
{
cr->x = (((int)-1) ^ 0x7fff) | (((int)cr->x) & 0x7fff);
}
else
{
 cr->x = (((int)cr->x) & 0x);
}

The negative case could be simplified to

(((int)-1) ^ 0x7fff) | ((int)cr->x)

Or

((int)-1)<<16|((int)cr->x)

>
> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-23 Thread zlists 
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) & 0x);
>   }
>   ...
>   if (cr->value_mask & CWHeight)
>   {
>   cr->height = (((unsigned int)cr->height) & 0x);
>   }
>   ...
>   }

> 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) & 0x = 0x & 0x
> = 0x
> = 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.)

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-23 Thread Thomas Adam 
On Sun, Oct 23, 2016 at 01:36:03PM +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.)

Can you double-check you actually pushed that, Dominik?  I don't see it
anywhere.

-- Thomas Adam

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-23 Thread Dominik Vogt 
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.)

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-23 Thread zlists 
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  HeightInternal 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]: <> 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]: <> 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

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-23 Thread Dominik Vogt 
On Sun, Oct 23, 2016 at 11:51:52AM +0100, Thomas Adam wrote:
> On Sun, Oct 23, 2016 at 11:13:59AM +0100, Dominik Vogt wrote:
> > 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?
> 
> Whoever ends up doing this, should use git-bisect to ascertain how I broke
> this.  ;P

Don't panic, it's one of my commits.
9e08db937a873943721f247e3ddfaed358faa143

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-23 Thread Thomas Adam 
On Sun, Oct 23, 2016 at 11:13:59AM +0100, Dominik Vogt wrote:
> 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?

Whoever ends up doing this, should use git-bisect to ascertain how I broke
this.  ;P

-- Thomas Adam

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-22 Thread zlists 
On Sun, Oct 23, 2016 at 02:23 (+0100), Dominik Vogt wrote:

> On Sat, Oct 22, 2016 at 10:00:16PM -0300, zli...@ns.sympatico.ca wrote:
>> On Sun, Oct 23, 2016 at 01:21 (+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.

>>> All right, I can see that acroread generates some weird requests
>>> for new size and position.  For me, the size is good, but the
>>> position is totally screwed (x=65600, y=66000).

>>> In fvwm/events.c at line 1077 there is this debug statement:

>>> #if 0
>>> fprintf(stderr,
>>> "cre: %d(%d) %d(%d) %d(%d)x%d(%d) fw 0x%08x w 0x%08x "
>>> ...
>>> #endif

>>> Can you please replace the "#if 0" with "#if 1", rebuild and post
>>> the output that going fullscreen causes on the console?  (Don't
>>> move or resize any windows when doing this to reduce the amount of
>>> output.)  Also, please add this line to the fvwm config file (or
>>> type it in FvwmConsole before starting acroread)

>>> bugopts explainwindowplacement

>>> This will produce some more output that may be helpful.

>> I trust this is what you were looking for?

>> cre: 0(0) 0(0) 48(4)x96(8) fw 0x00400cb3 w 0x0201 ew 0x0201  
>> 'stalonetray'
>> [fvwm][__execute_function]: <> No such command 
>> 'explainwindowplacement'

> The command is

> bugopts explainwindowplacement

My bad.  I tried
FvwmCommand bugopts explainwindowplacement
as a replacement since I don't have a menu item to start up
FvwmConsole, and that was wrong.  But after I sent my previous message
I saw my error and started up the FvwmConsole, but I didn't see
anything which I thought was more interesting.  However, I don't know
what I am looking at, so here is the output *after* giving "bugopts
explainwindowplacement" to FvwmConsole:

cre: 0(1) 0(2) 1910(0)x1048(0) fw 0x00401cd3 w 0x06400031 ew 0x06400031  'Adobe 
Reader'
cre: 0(1) 0(2) 200(0)x200(0) fw 0x00401e30 w 0x064005c8 ew 0x064005c8  
'acroread'
cre: 0(1) 0(2) 3276(4)x1048(8) fw 0x00401cd3 w 0x06400031 ew 0x06400031  
'zshguide.pdf - Adobe Reader'
cre: 0(1) 0(2) 3286(4)x1080(8) fw 0x00401cd3 w 0x06400031 ew 0x06400031  
'zshguide.pdf - Adobe Reader'
cre: 65529(1) 65481(2) 3300(4)x1142(8) fw 0x00401cd3 w 0x06400031 ew 0x06400031 
 'zshguide.pdf - Adobe Reader'
cre: 0(0) 0(0) 3300(4)x1142(8) fw 0x00401cd3 w 0x06400031 ew 0x06400031  
'zshguide.pdf - Adobe Reader'
cre: 0(1) 0(2) 200(0)x200(0) fw 0x00401ed2 w 0x064005f1 ew 0x064005f1  
'acroread'
cre: 1165(1) 44(2) 1910(4)x1048(8) fw 0x00401cd3 w 0x06400031 ew 0x06400031  
'zshguide.pdf - Adobe Reader'

> Uh, even stranger than on my box.
I don't know of anything particularly weird on my machine, unless it
is my screen config:

xrandr
Screen 0: minimum 8 x 8, current 3286 x 1080, maximum 32767 x 32767
LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 340mm x 
190mm
   1366x768  60.01*+
   1280x720  60.00  
   1024x768  60.00  
   1024x576  60.00  
   960x540   60.00  
   800x600   60.3256.25  
   864x486   60.00  
   640x480   59.94  
   720x405   60.00  
   680x384   60.00  
   640x360   60.00  
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected 1920x1080+1366+0 (normal left inverted right x axis y axis) 
520mm x 290mm
   1920x1080 60.00*+
   1680x1050 59.88  
   1280x1024 75.0260.02  
   1440x900  59.90  
   1280x960  60.00  
   1152x864  75.00  
   1024x768  75.0870.0760.00  
   832x624   74.55  
   800x600   72.1975.0060.3256.25  
   640x480   75.0072.8166.6760.00  
   720x400   70.08  
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Earlier this evening I tried turning off the external monitor and
trying acroread in full screen, but even in that situation it still
doesn't do full-screen correctly.

>> Anything else I can provide?

> Yes, a couple of things please:

> 1. What size are your pages, and how many pages do you use on the
> desktop?  On which page do you do this?  Do you have FvwmPager
> running and can see more of the window on other pages?
As it is not, I have 7 desks, each of which has 1 page.  With two
screens as above, the pages are 3286 x 1080.

> 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

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-22 Thread Dominik Vogt 
As a little bit of explanation how to read this output:


On Sat, Oct 22, 2016 at 10:00:16PM -0300, zli...@ns.sympatico.ca wrote:
> cre: 935(1) 0(2) 985(0)x1080(0) fw 0x00401005 w 0x06200031 ew 0x06200031  
> 'Adobe Reader'
   ^^^   ^^^   ^^^   ^^
X Y   Width  HeightInternal 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).

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

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

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

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-22 Thread Dominik Vogt 
On Sat, Oct 22, 2016 at 10:00:16PM -0300, zli...@ns.sympatico.ca wrote:
> On Sun, Oct 23, 2016 at 01:21 (+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.
> 
> > All right, I can see that acroread generates some weird requests
> > for new size and position.  For me, the size is good, but the
> > position is totally screwed (x=65600, y=66000).
> 
> > In fvwm/events.c at line 1077 there is this debug statement:
> 
> > #if 0
> > fprintf(stderr,
> > "cre: %d(%d) %d(%d) %d(%d)x%d(%d) fw 0x%08x w 0x%08x "
> > ...
> > #endif
> 
> > Can you please replace the "#if 0" with "#if 1", rebuild and post
> > the output that going fullscreen causes on the console?  (Don't
> > move or resize any windows when doing this to reduce the amount of
> > output.)  Also, please add this line to the fvwm config file (or
> > type it in FvwmConsole before starting acroread)
> 
> > bugopts explainwindowplacement
> 
> > This will produce some more output that may be helpful.
> 
> I trust this is what you were looking for?
> 
> cre: 0(0) 0(0) 48(4)x96(8) fw 0x00400cb3 w 0x0201 ew 0x0201  
> 'stalonetray'
> [fvwm][__execute_function]: <> No such command 'explainwindowplacement'

The command is

  bugopts explainwindowplacement

> cre: 935(1) 0(2) 985(0)x1080(0) fw 0x00401005 w 0x06200031 ew 0x06200031  
> 'Adobe Reader'
> cre: 0(1) 0(2) 200(0)x200(0) fw 0x00401166 w 0x0620086b ew 0x0620086b  
> 'acroread'
> cre: 0(1) 0(2) 3276(4)x1048(8) fw 0x00401005 w 0x06200031 ew 0x06200031  
> 'zshguide.pdf - Adobe Reader'
> cre: 0(1) 0(2) 3286(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031  
> 'zshguide.pdf - Adobe Reader'
> cre: 65529(1) 65481(2) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew 
> 0x06200031  'zshguide.pdf - Adobe Reader'
> cre: 0(0) 0(0) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew 0x06200031  
> 'zshguide.pdf - Adobe Reader'
> cre: 0(1) 0(2) 200(0)x200(0) fw 0x004012ac w 0x06200899 ew 0x06200899  
> 'acroread'
> cre: 1433(1) 65517(2) 985(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031 
>  'zshguide.pdf - Adobe Reader'

Uh, even stranger than on my box.

> Anything else I can provide?

Yes, a couple of things please:

1. What size are your pages, and how many pages do you use on the
   desktop?  On which page do you do this?  Do you have FvwmPager
   running and can see more of the window on other pages?

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

2. Please do this again (and post the new output), and then,
   without movind or resizing the window, run FvwmIdent on the
   reader window and post the contents of the FvwmIdent window
   (a small screenshot is fine).  (I need the new console output
   so that I can relate the information in FvwmIdent to the debug
   output on the console.)

3. Is this really a regression between 2.6.6 and 2.6.5, or did you
   also switch to a different acroread release?  (If so, which one
   did work with 2.6.5?)

And please, (unless you write sensitive information), reply to
fvm-work...@fvwm.org, not to me personally.  (This should happen
automatically if you hit the "reply" button in your mail
porogram.)

It might also help to include your config file or at least the
commands not refering to modules.  (You can send that to me
directly if you don't want to write it to the list.)

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

[zli...@ns.sympatico.ca: Re: regression from 2.6.5 to 2.6.6 ?]

2016-10-22 Thread Dominik Vogt 
- Forwarded message from zli...@ns.sympatico.ca -

Date: Sat, 22 Oct 2016 22:00:16 -0300
From: zli...@ns.sympatico.ca
To: Dominik Vogt <dominik.v...@gmx.de>
Subject: Re: regression from 2.6.5 to 2.6.6 ?
User-Agent: Mutt/1.6.1 (2016-04-27)

On Sun, Oct 23, 2016 at 01:21 (+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.

> All right, I can see that acroread generates some weird requests
> for new size and position.  For me, the size is good, but the
> position is totally screwed (x=65600, y=66000).

> In fvwm/events.c at line 1077 there is this debug statement:

> #if 0
>   fprintf(stderr,
>   "cre: %d(%d) %d(%d) %d(%d)x%d(%d) fw 0x%08x w 0x%08x "
> ...
> #endif

> Can you please replace the "#if 0" with "#if 1", rebuild and post
> the output that going fullscreen causes on the console?  (Don't
> move or resize any windows when doing this to reduce the amount of
> output.)  Also, please add this line to the fvwm config file (or
> type it in FvwmConsole before starting acroread)

> bugopts explainwindowplacement

> This will produce some more output that may be helpful.

I trust this is what you were looking for?

cre: 0(0) 0(0) 48(4)x96(8) fw 0x00400cb3 w 0x0201 ew 0x0201  
'stalonetray'
[fvwm][__execute_function]: <> No such command 'explainwindowplacement'
cre: 935(1) 0(2) 985(0)x1080(0) fw 0x00401005 w 0x06200031 ew 0x06200031  
'Adobe Reader'
cre: 0(1) 0(2) 200(0)x200(0) fw 0x00401166 w 0x0620086b ew 0x0620086b  
'acroread'
cre: 0(1) 0(2) 3276(4)x1048(8) fw 0x00401005 w 0x06200031 ew 0x06200031  
'zshguide.pdf - Adobe Reader'
cre: 0(1) 0(2) 3286(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031  
'zshguide.pdf - Adobe Reader'
cre: 65529(1) 65481(2) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew 0x06200031 
 'zshguide.pdf - Adobe Reader'
cre: 0(0) 0(0) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew 0x06200031  
'zshguide.pdf - Adobe Reader'
cre: 0(1) 0(2) 200(0)x200(0) fw 0x004012ac w 0x06200899 ew 0x06200899  
'acroread'
cre: 1433(1) 65517(2) 985(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031  
'zshguide.pdf - Adobe Reader'


Anything else I can provide?



- End forwarded message -


Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-22 Thread Dominik Vogt 
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.

All right, I can see that acroread generates some weird requests
for new size and position.  For me, the size is good, but the
position is totally screwed (x=65600, y=66000).

In fvwm/events.c at line 1077 there is this debug statement:

#if 0
fprintf(stderr,
"cre: %d(%d) %d(%d) %d(%d)x%d(%d) fw 0x%08x w 0x%08x "
...
#endif

Can you please replace the "#if 0" with "#if 1", rebuild and post
the output that going fullscreen causes on the console?  (Don't
move or resize any windows when doing this to reduce the amount of
output.)  Also, please add this line to the fvwm config file (or
type it in FvwmConsole before starting acroread)

  bugopts explainwindowplacement

This will produce some more output that may be helpful.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-22 Thread zlists 
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.  For example,
-> firefox
-> xournal
-> evince
-> chrome
-> opera
are all OK.  I may use other programs which work fine too, but
acroread is the one which does not go into full-screen mode correctly.

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-22 Thread Thomas Adam 
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.

-- Thomas Adam

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-22 Thread zlists 
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'm hearing reports of this problem, yes.  Can you try this with
> the version from git (master branch)?  And send me your fvwm
> configuration file, since I can't reproduce this problem.

 The git version as of 10 minutes ago still has this problem, unfortunately.

>>> Thanks; I'll put a fix in later on.

>> Any chance of this getting in to 2.6.7, if it isn't already in?

> I thought I had.  The fact that you're asking suggests it would be
> helpful if you could test 'master' and report back any problems.

I cloned the git version about 15 minutes ago and compiled it, and
acroread still does not go full-screen correctly.

If you have a fix you would like me to try, or if there is something
specific I can report from my system which you need, just let me know.

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-22 Thread Thomas Adam 
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'm hearing reports of this problem, yes.  Can you try this with the 
> >>> version
> >>> from git (master branch)?  And send me your fvwm configuration file, 
> >>> since I
> >>> can't reproduce this problem.
> 
> >> The git version as of 10 minutes ago still has this problem, unfortunately.
> 
> > Thanks; I'll put a fix in later on.
> 
> Any chance of this getting in to 2.6.7, if it isn't already in?

I thought I had.  The fact that you're asking suggests it would be helpful if
you could test 'master' and report back any problems.

-- Thomas Adam

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-22 Thread zlists 
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'm hearing reports of this problem, yes.  Can you try this with the version
>>> from git (master branch)?  And send me your fvwm configuration file, since I
>>> can't reproduce this problem.

>> The git version as of 10 minutes ago still has this problem, unfortunately.

> Thanks; I'll put a fix in later on.

Any chance of this getting in to 2.6.7, if it isn't already in?

Thanks.

Re: regression from 2.6.5 to 2.6.6 ?

2016-07-16 Thread zlists 
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'm hearing reports of this problem, yes.  Can you try this with the version
> from git (master branch)?
I will do so ASAP.

> And send me your fvwm configuration file, since I can't reproduce
> this problem.
In order to remove my config from suspicion, I created a new account
with no fvwm config files (and almost nothing else) and just used the
default config that Slackware provides.  Rather than me sending you
that, here is the whole thing that Slackware provides.

ftp://ftp.slackware.com/pub/slackware/slackware64-14.2/slackware64/xap/fvwm-2.6.6-x86_64-1.txz

Re: regression from 2.6.5 to 2.6.6 ?

2016-07-16 Thread Thomas Adam 
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'm hearing reports of this problem, yes.  Can you try this with the version
from git (master branch)?  And send me your fvwm configuration file, since I
can't reproduce this problem.

-- Thomas Adam

regression from 2.6.5 to 2.6.6 ?

2016-07-16 Thread zlists 
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 removed fvwm 2.6.6 and installed 2.6.5 from Slackware64 14.1 and now
it does the former (and expected) full-screen behaviour.

Has anyone else seen this?

FWIW, this is on a Fujitsu T900 which has a 13.3" 1280x800 screen and
8GB RAM.

Thanks.