Re: regression from 2.6.5 to 2.6.6 ?
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 ?
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 ?
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 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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
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 EW
Re: regression from 2.6.5 to 2.6.6 ?
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 ?
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 ?
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 Style acroread fixedppos, fixedpsize If that doesn't help, try adding Style acroread fixeduspos, fixedussize (You may or may not want the fixed...size bit.) 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? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
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 (annoyingly
Re: regression from 2.6.5 to 2.6.6 ?
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 ?
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 ?]
- Forwarded message from zli...@ns.sympatico.ca - Date: Sat, 22 Oct 2016 22:00:16 -0300 From: zli...@ns.sympatico.ca To: Dominik Vogt 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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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: >>> 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. Great, thanks very much.
Re: regression from 2.6.5 to 2.6.6 ?
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. -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: regression from 2.6.5 to 2.6.6 ?
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. (Incidentally, "git clone" does not get the file autogen.sh, and neither the README nor the INSTALL mention that one wants to use autoreconf. Perhaps this is obvious to everyone in the world besides me, but in case there are others, would it make sense to mention this somewhere?)
Re: regression from 2.6.5 to 2.6.6 ?
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 ?
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