Re: Default Configuration File

[Jaimos Skriletz]

On Sun, Oct 23, 2016 at 6:22 PM, Dan Espen  wrote:
>
>
> I have a few comments,
>
> 1) Wall paper changing isn't working.
>
> 2) The right panel goes all the way to the bottom of the screen
> but it's empty.  I don't like it wasting space.
>

​There was some issues modifying the config files to work from a system
location. This is hopefully fixed and you should be able to use the
wallpaper menu and that blank spot at the bottom is a clock.
​


> 3) "refresh" is in the menus.  Is that something users will use


​I have needed this through out the years and even on running inside a vnc
vm I found it was useful due to the low quality graphics. It doesn't need
to be in the menus, it is just something I find useful.
​


>
>
4) Olive Drab?
>
>
​I couldn't really figure out a good color and just went with the green. My
plan was to change it, never did. I am open for suggestions on replacing
the green. I thought about going with the blue from the website as a base
color.
​


> 5) I have windows without mini-icons and they are difficult
> to see in the pager


I'll modify the colorsets to make the windows stand out better. Also adding
a default mini icon for apps without them is a possibility.
​


>
>
6) There should be a menu to invoke the modules.
> Especially FvwmAnimate.
>
>
​I will look into adding such a menu and FvwmAnimate (I'm not that familiar
 with it)
​.

jaimos​

[fvwmorg/fvwm] aa6cf4: Changes to be committed:

[GitHub]

  Branch: refs/heads/default-config
  Home:   https://github.com/fvwmorg/fvwm
  Commit: aa6cf4cf9291f4bcf6efc61bd46edb15a31bff94
  
https://github.com/fvwmorg/fvwm/commit/aa6cf4cf9291f4bcf6efc61bd46edb15a31bff94
  Author: somiaj 
  Date:   2016-10-23 (Sun, 23 Oct 2016)

  Changed paths:
M default-config/Makefile.am
M default-config/config

  Log Message:
  ---
   Changes to be committed:
modified:   default-config/Makefile.am
modified:   default-config/config

 Updated config file to correct load wallpapers and FvwmScripts.

Re: Default Configuration File

[Dan Espen]

Thomas Adam  writes:

> On Sun, Oct 23, 2016 at 12:09:47AM -0600, Jaimos Skriletz wrote:
>> Hello,
>> 
>> Thomas has asked me to help with a default configuration file and this is
>> what I have come up with.
>> 
>> http://fvwmforums.org/fvwm-default-config.tar.gz
>> 
>> That file extracts to fvwm-default-config/ and to use copy the contents to
>> $HOME/.fvwm
>
> This won't be necessary.  I've more-or-less added these files to the FVWM
> build, the result of which can be found on the 'default-config' branch on git.
>
> I've been using it like this:
>
> % make clean && ./autogen.sh && ./configure --prefix=tmp/fvwn && \
>   sudo make install
>
> Then running fvwm under Xephyr:
>
> % /tmp/fvwm/bin/fvwm -f /dev/null

Hi,

So far I sort of like this.

I have a few comments,

1) Wall paper changing isn't working.
I get the message:

[fvwm-root] failed to load image file 'images/background/bg2.png'

The files are there:

  /usr/local/share/fvwm/default-config/images/background:
  -rw-r--r--. 1 root root 550823 Oct 23 19:54 bg2.png

I think maybe "default-config" isn't in the images path?


2) The right panel goes all the way to the bottom of the screen
but it's empty.  I don't like it wasting space.

3) "refresh" is in the menus.  Is that something users will use?

4) Olive Drab?

5) I have windows without mini-icons and they are difficult
to see in the pager.

6) There should be a menu to invoke the modules.
Especially FvwmAnimate.



-- 
Dan Espen

[fvwmorg/fvwm] bb35ad: Add default-config to fvwm

[GitHub]

  Branch: refs/heads/default-config
  Home:   https://github.com/fvwmorg/fvwm
  Commit: bb35adba0c417a8b477d33523ac3d8ffb5efac3e
  
https://github.com/fvwmorg/fvwm/commit/bb35adba0c417a8b477d33523ac3d8ffb5efac3e
  Author: Thomas Adam 
  Date:   2016-10-24 (Mon, 24 Oct 2016)

  Changed paths:
M Makefile.am
M configure.ac
A default-config/.stalonetrayrc
A default-config/FvwmScript-ConfirmQuit
A default-config/FvwmScript-DateTime
A default-config/Makefile.am
A default-config/config
A default-config/images/background/bg1.png
A default-config/images/background/bg2.png
A default-config/images/background/bg3.png
A default-config/images/bgicons/bg1.png
A default-config/images/bgicons/bg2.png
A default-config/images/bgicons/bg3.png
A default-config/images/fvwm-logo-small.png
A default-config/images/icons/apps.png
A default-config/images/icons/help.png
A default-config/images/icons/programs.png
A default-config/images/icons/quit.png
A default-config/images/icons/refresh.png
A default-config/images/icons/restart.png
A default-config/images/icons/terminal.png
A default-config/images/icons/wallpaper.png
A default-config/images/icons/xterm.png
M fvwm/ConfigFvwmDefaults
M fvwm/fvwm.c

  Log Message:
  ---
  Add default-config to fvwm

It's been a long-time coming, but fvwm out-of-the-box now has an uptodate and
maintainable configuration file which will hopefully serve as a good basis for
users to customise, should they not have one of their own to start with.

All credit for this goes to Jaimos Skriletz for this work, with some nice
feedback from the fvwm community at-large (mostly on #fvwm on freenode).

[fvwmorg/fvwm] d5eb11: Add default-config to fvwm

[GitHub]

  Branch: refs/heads/default-config
  Home:   https://github.com/fvwmorg/fvwm
  Commit: d5eb113f03c816a1b9a289cacf80497f6b47
  
https://github.com/fvwmorg/fvwm/commit/d5eb113f03c816a1b9a289cacf80497f6b47
  Author: Thomas Adam 
  Date:   2016-10-24 (Mon, 24 Oct 2016)

  Changed paths:
M Makefile.am
M configure.ac
A default-config/.stalonetrayrc
A default-config/FvwmScript-ConfirmQuit
A default-config/FvwmScript-DateTime
A default-config/Makefile.am
A default-config/config
A default-config/images/background/bg1.png
A default-config/images/background/bg2.png
A default-config/images/background/bg3.png
A default-config/images/bgicons/bg1.png
A default-config/images/bgicons/bg2.png
A default-config/images/bgicons/bg3.png
A default-config/images/fvwm-logo-small.png
A default-config/images/icons/apps.png
A default-config/images/icons/help.png
A default-config/images/icons/programs.png
A default-config/images/icons/quit.png
A default-config/images/icons/refresh.png
A default-config/images/icons/restart.png
A default-config/images/icons/terminal.png
A default-config/images/icons/wallpaper.png
A default-config/images/icons/xterm.png
M fvwm/ConfigFvwmDefaults
M fvwm/fvwm.c

  Log Message:
  ---
  Add default-config to fvwm

It's been a long-time coming, but fvwm out-of-the-box now has an uptodate and
maintainable configuration file which will hopefully serve as a good basis for
users to customise, should they not have one of their own to start with.

All credit for this goes to Jaimos Skriletz for this work, with some nice
feedback from the fvwm community at-large (mostly on #fvwm on freenode).

[fvwmorg/fvwm] 869ad4: Add default-config to fvwm

[GitHub]

  Branch: refs/heads/default-config
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 869ad41e10840a1f99da86013a22e1b4ab2d93c0
  
https://github.com/fvwmorg/fvwm/commit/869ad41e10840a1f99da86013a22e1b4ab2d93c0
  Author: Thomas Adam 
  Date:   2016-10-23 (Sun, 23 Oct 2016)

  Changed paths:
M Makefile.am
M configure.ac
A default-config/FvwmScript-DateTime
A default-config/FvwmScript-Quit
A default-config/Makefile.am
A default-config/config
A default-config/images/background/bg1.png
A default-config/images/background/bg2.png
A default-config/images/background/bg3.png
A default-config/images/bgicons/bg1.png
A default-config/images/bgicons/bg2.png
A default-config/images/bgicons/bg3.png
A default-config/images/fvwm-logo-small.png
A default-config/images/icons/apps.png
A default-config/images/icons/help.png
A default-config/images/icons/programs.png
A default-config/images/icons/quit.png
A default-config/images/icons/refresh.png
A default-config/images/icons/restart.png
A default-config/images/icons/terminal.png
A default-config/images/icons/wallpaper.png
A default-config/images/icons/xterm.png
M fvwm/ConfigFvwmDefaults
M fvwm/fvwm.c

  Log Message:
  ---
  Add default-config to fvwm

It's been a long-time coming, but fvwm out-of-the-box now has an uptodate and
maintainable configuration file which will hopefully serve as a good basis for
users to customise, should they not have one of their own to start with.

All credit for this goes to Jaimos Skriletz for this work, with some nice
feedback from the fvwm community at-large (mostly on #fvwm on freenode).

Re: Default Configuration File

[Thomas Adam]

On Sun, Oct 23, 2016 at 12:09:47AM -0600, Jaimos Skriletz wrote:
> Hello,
> 
> Thomas has asked me to help with a default configuration file and this is
> what I have come up with.
> 
> http://fvwmforums.org/fvwm-default-config.tar.gz
> 
> That file extracts to fvwm-default-config/ and to use copy the contents to
> $HOME/.fvwm

This won't be necessary.  I've more-or-less added these files to the FVWM
build, the result of which can be found on the 'default-config' branch on git.

I've been using it like this:

% make clean && ./autogen.sh && ./configure --prefix=tmp/fvwn && \
  sudo make install

Then running fvwm under Xephyr:

% /tmp/fvwm/bin/fvwm -f /dev/null

-- Thomas Adam

[fvwmorg/fvwm] 5e9298: Add default-config to fvwm

[GitHub]

  Branch: refs/heads/default-config
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 5e9298b92b272e6bb63177cf3e8657032273a055
  
https://github.com/fvwmorg/fvwm/commit/5e9298b92b272e6bb63177cf3e8657032273a055
  Author: Thomas Adam 
  Date:   2016-10-23 (Sun, 23 Oct 2016)

  Changed paths:
M Makefile.am
M configure.ac
A default-config/FvwmScript-DateTime
A default-config/FvwmScript-Quit
A default-config/Makefile.am
A default-config/config
A default-config/images/background/bg1.png
A default-config/images/background/bg2.png
A default-config/images/background/bg3.png
A default-config/images/bgicons/bg1.png
A default-config/images/bgicons/bg2.png
A default-config/images/bgicons/bg3.png
A default-config/images/fvwm-logo-small.png
A default-config/images/icons/apps.png
A default-config/images/icons/help.png
A default-config/images/icons/programs.png
A default-config/images/icons/quit.png
A default-config/images/icons/refresh.png
A default-config/images/icons/restart.png
A default-config/images/icons/terminal.png
A default-config/images/icons/wallpaper.png
A default-config/images/icons/xterm.png
M fvwm/ConfigFvwmDefaults
M fvwm/fvwm.c

  Log Message:
  ---
  Add default-config to fvwm

It's been a long-time coming, but fvwm out-of-the-box now has an uptodate and
maintainable configuration file which will hopefully serve as a good basis for
users to customise, should they not have one of their own to start with.

All credit for this goes to Jaimos Skriletz for this work, with some nice
feedback from the fvwm community at-large (mostly on #fvwm on freenode).

Re: regression from 2.6.5 to 2.6.6 ?

[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: FVWM: problems with png support

[Volker]

On 10/22/16 20:41, Thomas Adam wrote:

On Fri, Oct 21, 2016 at 10:12:01AM +0200, Volker wrote:

I updated (from cvs) to the latest version in git, but
unfortunately lost png support under the transition.

This should be fixed now on master; please check.

-- Thomas Adam

Works fine, thanks.

/Volker

Re: regression from 2.6.5 to 2.6.6 ?

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

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

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

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

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

[fvwmorg/fvwm] 968357: Fix sanitising XConfigureRequest and XConfigureNot...

[GitHub]

  Branch: refs/heads/dv/fix-cr-merging
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 96835762f45eaf844dab14754a9694bbd1c55fbe
  
https://github.com/fvwmorg/fvwm/commit/96835762f45eaf844dab14754a9694bbd1c55fbe
  Author: Dominik Vogt 
  Date:   2016-10-23 (Sun, 23 Oct 2016)

  Changed paths:
M libs/FEvent.c

  Log Message:
  ---
  Fix sanitising XConfigureRequest and XConfigureNotify events.

libs:
* FEvent.c (fev_sanitise_configure_request)
(fev_sanitise_configure_notify): Fix trunctation of int to 16-bit
quantity.  This broke ConfigureRequest handling for some applications
like acroread.

[fvwmorg/fvwm] ec8588: Fix sanitising XConfigureRequest and XConfigureNot...

[GitHub]

  Branch: refs/heads/dv/fix-cr-merging
  Home:   https://github.com/fvwmorg/fvwm
  Commit: ec8588fc8f96b08105f973b23b7943aa216205f2
  
https://github.com/fvwmorg/fvwm/commit/ec8588fc8f96b08105f973b23b7943aa216205f2
  Author: Dominik Vogt 
  Date:   2016-10-23 (Sun, 23 Oct 2016)

  Changed paths:
M libs/FEvent.c

  Log Message:
  ---
  Fix sanitising XConfigureRequest and XConfigureNotify events.

libs:
* FEvent.c (fev_sanitise_configure_request)
(fev_sanitise_configure_notify): Fix trunctation of int to 16-bit
quantity.  This broke ConfigureRequest handling for some applications
like acroread.

Re: regression from 2.6.5 to 2.6.6 ?

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

[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

FVWM: fvwm3???

[Ethan Raynor]

Hi,

I was just browsing the fvwm git repository and saw that things have
been busy this weekend - I hope this means fvwm development is
happening again? It has been really slow for years - nothing
happening.

https://github.com/fvwmorg/fvwm/blob/ta/next/FVWM3.md

Does this mean fvwm2 is dead? Does fvwm3 exist yet? what's  happening with it?

Sounds like a plan though! Who's developing it?

[fvwmorg/fvwm] 1f45da: FvwmButtons: Fix infinite loop with Silent

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 1f45da61792db76a50b40eb22d6510b0f4bc533d
  
https://github.com/fvwmorg/fvwm/commit/1f45da61792db76a50b40eb22d6510b0f4bc533d
  Author: Thomas Adam 
  Date:   2016-10-23 (Sun, 23 Oct 2016)

  Changed paths:
M NEWS
M modules/FvwmButtons/dynamic.c

  Log Message:
  ---
  FvwmButtons: Fix infinite loop with Silent

When detecting whether Silent has been given (to surpress errors), make sure
the loop is exited early, otherwise the tokenisation of commands can cause
FvwmButtons to infinite loop.

[fvwmorg/fvwm] 1f45da: FvwmButtons: Fix infinite loop with Silent

[GitHub]

  Branch: refs/heads/ta/fvwmbuttons-colorset
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 1f45da61792db76a50b40eb22d6510b0f4bc533d
  
https://github.com/fvwmorg/fvwm/commit/1f45da61792db76a50b40eb22d6510b0f4bc533d
  Author: Thomas Adam 
  Date:   2016-10-23 (Sun, 23 Oct 2016)

  Changed paths:
M NEWS
M modules/FvwmButtons/dynamic.c

  Log Message:
  ---
  FvwmButtons: Fix infinite loop with Silent

When detecting whether Silent has been given (to surpress errors), make sure
the loop is exited early, otherwise the tokenisation of commands can cause
FvwmButtons to infinite loop.

Re: regression from 2.6.5 to 2.6.6 ?

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

[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: [fvwmorg/fvwm] 58d1a6: NEWS: formatting tweaks

[Thomas Adam]

On Sat, Oct 22, 2016 at 06:42:08PM -0700, GitHub wrote:
>   Branch: refs/heads/ta/reluctant-news
>   Home:   https://github.com/fvwmorg/fvwm
>   Commit: 58d1a64671c12e93554dd48e6112f6c6e0d921ed
>   
> https://github.com/fvwmorg/fvwm/commit/58d1a64671c12e93554dd48e6112f6c6e0d921ed
>   Author: Thomas Adam 
>   Date:   2016-10-23 (Sun, 23 Oct 2016)
> 
>   Changed paths:
> M NEWS
> 
>   Log Message:
>   ---
>   NEWS: formatting tweaks

This is now reflected on the website:   http://fvwm.org/news/

-- Thomas Adam

[fvwmorg/fvwm] 355c4c: FvwmButtons: Fix infinite loop with Silent

[GitHub]

  Branch: refs/heads/ta/fvwmbuttons-colorset
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 355c4cb1a9729ac02214d20fc3aa61e27d0fb0a5
  
https://github.com/fvwmorg/fvwm/commit/355c4cb1a9729ac02214d20fc3aa61e27d0fb0a5
  Author: Thomas Adam 
  Date:   2016-10-23 (Sun, 23 Oct 2016)

  Changed paths:
M NEWS
M modules/FvwmButtons/dynamic.c

  Log Message:
  ---
  FvwmButtons: Fix infinite loop with Silent

When detecting whether Silent has been given (to surpress errors), make sure
the loop is exited early, otherwise the tokenisation of commands can cause
FvwmButtons to infinite loop.

Re: regression from 2.6.5 to 2.6.6 ?

[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: Final long term stable version

[Thomas Adam]

On Sun, Oct 23, 2016 at 11:46:23AM +0100, Dominik Vogt wrote:
> The old stable branch should provide important fixes for people
> who use old versions, and that includes not taking away stuff from
> them, no?  The idea is that people who have some good (but rare)
> reason to stick with the old version can continue doing so.
> 
> > Given all of this, I think it's safe to do this.  I have heard nothing from
> > anyone in recent years who are using the above, and/or who haven't already
> > migrated to FvwmButtons or FvwmTaskbar for the most part.
> 
> But actually these removals are only half a year old and are not
> part of any release yet.

So this work is going towards that next release.  If you were to forget about
2.6.7 being the last release of fvwm2 before we move away to pastures new,
then this work is simply another iteration on improving fvwm2.  This is where
I want to leave fvwm2, in a known good state, by removing all the things I've
mentioned.  It means the user can actually use something which is "current",
and more maintainable, and it also means that any maintenance work needed is
reduced in scope because there's less things to worry about.

-- Thomas Adam

Re: Final long term stable version

[Dominik Vogt]

On Sun, Oct 23, 2016 at 03:22:08AM +0100, Thomas Adam wrote:
> On Sun, Oct 23, 2016 at 03:12:19AM +0100, Dominik Vogt wrote:
> > On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote:
> > > On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote:
> > > I am looking at releasing 2.6.7 this weekend.  AFAIAC, this release will 
> > > be
> > > the last stable/supported version.  Up to this point I've installed all
> > > optional libraries and fixed all the warnings for the versions I have
> > > available (FreeBSD) -- so that's something.  I think it's in a good state 
> > > to
> > > be left behind, and allowing it to receive minor fixes, etc.
> > 
> > Hm, is it actually a good idea to remove half the modules and
> > GNOME hints support in the last stable fvwm2 release?  Could the
> > commits be rearranged so that this stuff stays in 2.6.7 and is
> > removed immediately after that?
> > 
> > Or maybe start the long term stable branch at 2.6.6 and
> > cherry-pick only the patches that add something from master.
> 
> Hmm.  Why?

I'm *not* against removal of anything on that list.  It's just
very inconsinstent if we announce "2.6.7 is the last long time
stable version of fvwm2, and after that release we start rewriting
stuff from scratch and remove old things" and then actually start
removing things in 2.6.7.

The old stable branch should provide important fixes for people
who use old versions, and that includes not taking away stuff from
them, no?  The idea is that people who have some good (but rare)
reason to stick with the old version can continue doing so.

> Given all of this, I think it's safe to do this.  I have heard nothing from
> anyone in recent years who are using the above, and/or who haven't already
> migrated to FvwmButtons or FvwmTaskbar for the most part.

But actually these removals are only half a year old and are not
part of any release yet.

> As for GNOME hints support -- that's reduced code, and isn't used in the wild
> at all.

Good for me, I hate that code.

> Should enough people complain loudly enough, sure, I might add it back in, but
> I really don't think they will.  So I still think going ahead with 2.6.7 in
> this state--whereby we've made the best effort to leave it with *useful* stuff
> that we then don't have to fix in the future, can only been a good thing.

All I care is having a base for long term maintenance without
breaking things.  I'd even be fine to release 2.6.7 as the last
old stable release without the removals and 2.7.0 adding them back
on the same day.  (But first this acroread issue needs to be
resolved.)

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt