Re: FVWM: REWRITE: Request for help -- parsing of command token

[Jaimos Skriletz]

On Sat, Sep 13, 2014 at 2:14 AM,
​​
Dominik Vogt dominik.v...@gmx.de wrote:

 For testing pusposes I need to get an overwiev of what types of
 commands people use in fvwm.  Could everybody please look through
 their configuration files and post any commands:

 1) That contain whitespace, quoting characters or variables
(e.g. $[foo] or $w) in  the first word of the line.  Expamples:


No occurrences in my config file.
​




 2) Such things in conditional commands or function or menu
definitions in place of the command name, menue name or
function name.  Examples:


I use variables in conditional commands to test for files before accessing
the file such as

​Test (f $[FVWM_USERDIR]/cfg/WallpaperMenu) Read
$[FVWM_USERDIR]/cfg/WallpaperMenu

Test (f $[FVWM_USERDIR]/cfg/DebianMenu) Read $[FVWM_USERDIR]/cfg/DebianMenu


 3) Fvwm allows to start modules without using the Module command,
e.g. with just FvwmButtons instead of Module FvwmButtons.
Do you use this?  Did you know that's possible?


​Nope, I did not know that was possible and have no occurrences of such a
thing.​

jaimos

Re: Deprecation: Let's talk once more about removing $STUFF...Setup Form

[Jaimos Skriletz]

On Thu, Jun 9, 2016 at 4:45 AM, Thomas Adam  wrote:

> On Fri, Jun 03, 2016 at 02:21:51AM +0100, Thomas Adam wrote:
> Any lasting objections before this is merged and we can move onto the next
> phase with is introducing a default configuration?
>
>
​I have some ideas on a default configuration I was working on, but then
got side tracked with work.

I may have time in 2-3 weeks I could put into cleaning my configuration I
was working on, if some help is needed with creating a default
configuration.

​There will of course be some questions/discussion on what should be in the
default, but I'll save this for when I have time and another thread.

I was also curious if the document that was created many years ago (by
members of #fvwm) about what should be in the default config is still
around as that would be useful to look at.

jaimos



​

​

Re: Deprecation: Let's talk once more about removing $STUFF...

[Jaimos Skriletz]

On Tue, May 31, 2016 at 2:46 PM, Jason Weber  wrote:

>
> I still have FvwmWinList on a button in case I get some rogue window
> that FvwmProxy doesn't represent, but, honestly, it isn't a big deal.
>
>
​You can also use WindowList and get a list of all the windows (under
certain conditions) in a menu which will serve as a replacement for
FvwmWinList if needed.​


​jaimos​

Re: Deprecation: Let's talk once more about removing $STUFF...

[Jaimos Skriletz]

On Tue, May 31, 2016 at 2:30 PM, Thomas Funk  wrote:

> On 05/31/2016 09:30 PM, Thomas Adam wrote:
>
>>
>> On 19 May 2016 4:18 p.m., "Thomas Adam"  tho...@fvwm.org>> wrote:
>>  >
>>  > Hey all,
>>  >
>>  > The last time this came up for conversation [0] things were far from
>> ideal.  I
>>  > want to have another conversation about this to see whether it's
>> possible to
>>  > state the case why some modules in FVWM should be removed.
>>
>> Anyone?
>>
>> Thomas Adam
>>
>> Perhaps you shouldn't remove FvwmTaskBar for the moment until someone
> creates a replacement
> with FvwmPager/FvwmIconman.
>
>
​Just remove FvwmTaskBar, there has been ample warning that this was going
to happen. There will be some fall back and it is my guess this is the one
that will get missed the most, but no need to keep it around and it isn't
like waiting is going to make it any less of an issue, I just expect to
hear various issues with it once fvwm 2.6.7 starts to get pushed into repos
of downstream oses.

jaimos​

Re: Deprecation: Let's talk once more about removing $STUFF...

[Jaimos Skriletz]

On Thu, May 19, 2016 at 9:18 AM, Thomas Adam  wrote:

>
> * FvwmTaskBar -- Use FvwmIconMan.
>
>
​I do agree that FvwmTaskBar should be deprecated and FvwmIconMan should be
used instead, but my experience is FvwmIconMan was not easy to create a
config that behaved like the simple FvwmTaskBar, and I still think many are
using this because it is so much easier to configure than FvwmIconMan for a
TaskBar (despite it is also buggy, I still see it used a lot).

I think removing this will cause some (or maybe more than some) discussion
on the main fvwm mailing list once people notice it is gone who have been
using it, including some not so happy fvwm users.

My suggestion is in order to remove FvwmTaskBar we should provide a config
that will provide something similar FvwmTaskBar using FvwmIconMan that
people can just take and slightly modify. This way when someone comes to
the list (or irc) and starts saying where did my FvwmTaskBar go, we can
just point them to a config and they can be on their way.


> I've also gone and removed these two directories:
>
> debian/
> rpm/
>
> AFAIAC, these shouldn't be part of a window manager, and it is
> unreasonable to
> expect maintainers of a window manager to understand package management to
> any
> degree.  All downstream do when they package FVWM is remove these
> directories
> and replace them with their own (newer) versions, since ours are just left
> to
> bitrot.  If you want to build packages of your own, do so.  But it's
> peripheral to FVWM.
>

​I can't speak for the rpm/ directory, but I know that in debian the
directory is removed by the debian maintainer and replaced by his own that
fits the modern debian standards, passes all the package auditing tools,
etc.​

​I also think that if someone wanted to build their own custom .deb, the
debian/ is outdated enough that it shouldn't be used.

If someone really wanted to build their own .deb over using the one
provided by debian I would suggest pointing them at debian_helper. This can
autogenerate a simple debian/ dir that is probably better than the one
provided by fvwm and is fairly automatic. I could look into writing up a
little doc on how to do this.​ The other option is to just use the debian/
from the debian source package, but then you have to deal with debian
patches.


Those are my two cents,

jaimos

Re: Deprecation: Let's talk once more about removing $STUFF...

[Jaimos Skriletz]

On Thu, May 19, 2016 at 11:07 AM, Dan Espen  wrote:

> Just had an opportunity to look at Fvwm.Org, it looks pretty nice.
> I thought we were going to retain the themeing, but I don't see it.
> Not a real problem.
> ​
>

​Being a static site and only using html and javascript it makes being able
to switch themes not as practical as it was when the site was php (also
makes the site way easier to maintain and update).​ So the initial build of
the new site was just to remove the php and use a static site builder
(jekyll) to build the site with a single theme.

I still had in my mind that themes would be nice to change. I built the
site using mostly css, so a simple change to the theme is to just change
the css file, but this requires three things.

​1) Someone to build a new theme .css file.
2) Figuring out how to use javascript to load the correct .css file.
3) Deal with any issues that arise. Even though I tried to do everything
with .css, more than just the .css files
may need to be modified when trying to write a new theme to get it to work
correctly.

So as of now (and mostly likely for a while) there won't be themes. But
they could be added if someone wanted to invest the time.

jaimos​

Re: Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed

[Jaimos Skriletz]

On Sun, Jan 15, 2017 at 10:10 PM, Jaimos Skriletz
<jaimosskril...@gmail.com> wrote:
> On Sun, Jan 15, 2017 at 8:44 PM, Jaimos Skriletz
> <jaimosskril...@gmail.com> wrote:
>> On Wed, Dec 28, 2016 at 3:16 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>>> On Tue, Dec 27, 2016 at 05:34:08PM -0700, Jaimos Skriletz wrote:
>>>> On Tue, Dec 27, 2016 at 5:28 PM, Jaimos Skriletz
>>>> <jaimosskril...@gmail.com> wrote:
>>>> > On Tue, Dec 27, 2016 at 5:15 PM, Dominik Vogt <dominik.v...@gmx.de> 
>>>> > wrote:
>>>> >> On Tue, Dec 27, 2016 at 05:04:40PM -0700, Jaimos Skriletz wrote:
>>>> >>> On Tue, Dec 27, 2016 at 4:52 PM, Jaimos Skriletz
>>>> >>> <jaimosskril...@gmail.com> wrote:
>>>> >>> > On Tue, Dec 27, 2016 at 3:44 PM, Dominik Vogt <dominik.v...@gmx.de> 
>>>> >>> > wrote:
>>>> >>> >> On Mon, Dec 26, 2016 at 01:17:05PM -0700, Jaimos Skriletz wrote:
>>>> >>> >>> Hello,
>>>> >>> >>>
>>>> >>> >>> This was reported by a Debian user. Please retain the CC to
>>>> >>> >>> 849355-forwar...@bugs.debian.org in your response, so that
>>>> >>> >>> the Debian BTS has a record.
>>>> >>> >>>
>>>> >>> >>> In short when running FvwmIconMan, fvwm prints warnings to stderr 
>>>> >>> >>> when
>>>> >>> >>> opening and closing windows. I too have had this issue in 2.6.7 
>>>> >>> >>> (and
>>>> >>> >>> previous versions) so I can also say it affects my Debian system.
>>>> >>> >>
>>> Fixed on the (new) fvwm2-stable branch; patch for the development
>>> branches will follow one I've figured out how to deal with the
>>> two repositories.
>>>
>>
>
> I'm also getting these errors from other applications. I will remove
> the patches and see if the behvior goes back to the way it was, or if
> there is something else in my system causing fvwm to output these
> warnings. Here is one from a vim window.
>

After further investigation these new warnings do not seem related to
the original bug as they occur with or without the patches in
question. If I remove the patches I get the old behavior back. And
without the patches I still get gvim and other windows giving
warnings. I wonder if there is something new going on on my system in
the other applications causing these warnings or if they were there
before, I just didn't notice in the spam of the ones from FvwmIconMan.

Anyways thanks again for your help on this.

jaimos

FvwmIconMan still sometimes triggers Hint Warnings

[Jaimos Skriletz]

Hello,

FvwmIconMan still reports Hint warnings even with the patchs applied.

http://www.mail-archive.com/fvwm-workers@fvwm.org/msg04570.html

Using the current master branch I get the warnings from FvwmIconMan in
the situation it is set to grow/shrink. The easiest way to get this is
use the defaults, such as Module FvwmIconMan TestIconMan, then
adding/removing windows is triggering the following warning.

[fvwm][GetWindowSizeHints]: <> reason: 4: The hints have been
ignored because the window's current size would have become invalid.
The new hints willbecome active when the window generates the next
ConfigureRequest.

[fvwm][GetWindowSizeHints]: <> The application window (id 0x5a4)
  "FvwmIconMan" has broken size hints (inconsistent with current size).
fvwm is ignoring those hints.hint override = 0, flags = 371
  min_width = 120, min_height = 180, max_width = 120, max_height = 180
  width_inc = 1, height_inc = 1
  min_aspect = 0/0, max_aspect = 0/0
  base_width = 0, base_height = 0
  win_gravity = 3

If you are having a problem with the application, send a bug report
with this message included to the application owner.
There is no need to notify fvwm-workers@fvwm.org.

As before they are triggered whenever a window is added/removed from
the list. I looked at the patch and saw the functions that released
and then reset the hints, and if I comment out line 442 in
modules/FvwmIconMan/xmanager.c

 fix_manager_size(man, man->geometry.width, man->geometry.height);

The warnings are not triggered. So it seems to me there is some
race/timing issue where it may fix the size before
XMoveResizeWindow() has finished its task causing the warning to be
fired. At this point I'm unsure how to have fix_manager_size() wait
until the action is complete as to avoid triggering the warnings.

jaimos

Re: FvwmIconMan still sometimes triggers Hint Warnings

[Jaimos Skriletz]

On Wed, Mar 1, 2017 at 9:24 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> On Wed, Mar 01, 2017 at 07:18:11AM -0700, Jaimos Skriletz wrote:
>> On Wed, Mar 1, 2017 at 5:30 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>> > On Tue, Feb 28, 2017 at 10:22:33PM -0700, Jaimos Skriletz wrote:
>> >> On Mon, Feb 27, 2017 at 11:10 PM, Jaimos Skriletz
>> >> <jaimosskril...@gmail.com> wrote:
>> >> > Hello,
>> >> >
>> >> > FvwmIconMan still reports Hint warnings even with the patchs applied.
>> >>
>> >> I wrote this small patch that has FvwmIconMan wait until the window
>> >> has resized to set the window hints. This is in the lines of Dominik
>> >> Vogt's patch, but waits until FvwmIconMan has fully resized to run
>> >> fix_manager_size() to set the window hints. My tests here no longer
>> >> seem to tiger the warnings like it still sometimes did.
>> >>
>> >> As an additional thought, talking to Thomas Adam about the patch in
>> >> #fvwm, he mentioned that the issue is more FVWM being overly cautious
>> >> and the fix should be in how fvwm handles size hint warnings over
>> >> working with FvwmIconMan to avoid triggering them.
>> >>
>> >
>> > So, if it's not possible to completely fix FvwmIconMan in a decent
>> > way, what do we do with the warning?  I'd rather not disable it,
>> > but the number of false positives is too high.  One could make a
>> > style that disables the warning for a certain class of windows,
>> > but that would probably be used as "style * ...", disabling the
>> > warning for everything.  :-/
>> >
>>
>> FvwmIconMan isn't the only application that triggers these warnings,
>> but using it in a situation where it grows/shrinks is a very regular
>> way to cause the warnings and it fills up .xsession-error with mostly
>> warnings. Other applications I use only trigger these warnings rarely,
>> and in each case the application appears to work fine so yet more
>> false positives. But FvwmIconMan is the only one that regularly
>> resizes itself triggering the warning a lot.
>
> Of course.  Flooding the log was not the intention of the patch.
>
>> I had two ideas on this, one is use a BugOpts option that can turn on
>> these warnings for a user who wants to debug things, but they are off
>> by default. This is basically your style idea and the affect will be
>> almost everywhere these warnings will not appear and thus may miss out
>> on programs that actually need to be reported.
>
> Yes, but defaulting to "off" makes the warning effectively useless.
>

Yea, hence the same line as a style and then turning it off. Though if
a window is misbehaving it could be turned on to see if it is
triggering these warnings. But one would have to know a window is
misbehaving and not able to just look in the logs to see that one is.

>> Another is maybe don't have fvwm jump to conclusions that there is a
>> warning.
>
> Let me rephrase that:  Fvwm informs the user about something that
> might not be possible to clean up.  In such a situation the user
> would see that the window did not get resized as intended and has
> no clue why.  At least, fvwm has told her that something strange
> was going on.
>
>> What if there was some timer that fvwm gave the application
>> to fix itself before reporting a warning, and then the warning is not
>> just that the window had this inconstant state which seems to give
>> false positives, but it has been inconsistent for a set amount of time
>> without fixing itself.
>
> Too complex stuff for such a simple situation.  Maybe one could
> peek the event queue for an event that fixes the windows's size
> and not complain if such an event is already pending?  Another
> option is to generate only a limited number of these warning for
> each window.
>
> Does the attached patch improve the situation?
>

I have applied the patch and it doesn't seem to change the situation,
FvwmIconMan is still triggering the hint size warnings every time a
window is added or removed.

jaimos

Re: FvwmIconMan still sometimes triggers Hint Warnings

[Jaimos Skriletz]

On Wed, Mar 1, 2017 at 5:30 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> On Tue, Feb 28, 2017 at 10:22:33PM -0700, Jaimos Skriletz wrote:
>> On Mon, Feb 27, 2017 at 11:10 PM, Jaimos Skriletz
>> <jaimosskril...@gmail.com> wrote:
>> > Hello,
>> >
>> > FvwmIconMan still reports Hint warnings even with the patchs applied.
>>
>> I wrote this small patch that has FvwmIconMan wait until the window
>> has resized to set the window hints. This is in the lines of Dominik
>> Vogt's patch, but waits until FvwmIconMan has fully resized to run
>> fix_manager_size() to set the window hints. My tests here no longer
>> seem to tiger the warnings like it still sometimes did.
>>
>> As an additional thought, talking to Thomas Adam about the patch in
>> #fvwm, he mentioned that the issue is more FVWM being overly cautious
>> and the fix should be in how fvwm handles size hint warnings over
>> working with FvwmIconMan to avoid triggering them.
>>
>
> So, if it's not possible to completely fix FvwmIconMan in a decent
> way, what do we do with the warning?  I'd rather not disable it,
> but the number of false positives is too high.  One could make a
> style that disables the warning for a certain class of windows,
> but that would probably be used as "style * ...", disabling the
> warning for everything.  :-/
>

FvwmIconMan isn't the only application that triggers these warnings,
but using it in a situation where it grows/shrinks is a very regular
way to cause the warnings and it fills up .xsession-error with mostly
warnings. Other applications I use only trigger these warnings rarely,
and in each case the application appears to work fine so yet more
false positives. But FvwmIconMan is the only one that regularly
resizes itself triggering the warning a lot.

I had two ideas on this, one is use a BugOpts option that can turn on
these warnings for a user who wants to debug things, but they are off
by default. This is basically your style idea and the affect will be
almost everywhere these warnings will not appear and thus may miss out
on programs that actually need to be reported.

Another is maybe don't have fvwm jump to conclusions that there is a
warning. What if there was some timer that fvwm gave the application
to fix itself before reporting a warning, and then the warning is not
just that the window had this inconstant state which seems to give
false positives, but it has been inconsistent for a set amount of time
without fixing itself.

Anyways, for those of us who use FvwmIconMan as a growing/shrinking
standalone module, this patch drastically reduces the amount of
warnings, but I agree it really doesn't seem like the way to deal with
this issue to make applications have to add these waits to deal with
resizing both the window and the size hints.

jaimos

Re: Changes in which regards dependency tree

[Jaimos Skriletz]

On Mon, Nov 7, 2016 at 3:33 PM, Jesús J. Guerrero Botella <
jesus.guerrero.bote...@gmail.com> wrote:

> I see, thanks for the pointers, they'll help.
>
>
​Please CC fvwm-workers@fvwm.org on replys. Glad I could help.
​


> On a related note, when I click the option to configure the xdg menu
> in the menu, fvwm says:
>
> Can't locate FVWM/Module.pm in @INC (you may need to install the
> FVWM::Module module) (@INC contains: /usr/share/fvwm/perllib /etc/perl
> /usr/local/lib64/perl5/5.22.2/x86_64-linux
> /usr/local/lib64/perl5/5.22.2
> /usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux
> /usr/lib64/perl5/vendor_perl/5.22.2 /usr/local/lib64/perl5
> /usr/lib64/perl5/vendor_perl /usr/lib64/perl5/5.22.2/x86_64-linux
> /usr/lib64/perl5/5.22.2 .) at /usr/lib/fvwm/2.6.7/FvwmPerl line 33.
> BEGIN failed--compilation aborted at /usr/lib/fvwm/2.6.7/FvwmPerl line 33.
>

​# ls /usr/share/fvwm/perllib/FVWM/Module.pm -- that is the file it is
looking for.

Do your build options not build with libperl (not sure on this) depends? I
don't know enough to think what option this can be. Check what build
options were detected.

The configure option uses FvwmPerl and FvwmForm to open a gui a user can
select options for building the menu. Including what .menu(s) to use,
include icons, menu titles, and some other options.

jaimos

​

Re: Changes in which regards dependency tree

[Jaimos Skriletz]

On Mon, Nov 7, 2016 at 2:57 PM, Jesús J. Guerrero Botella <
jesus.guerrero.bote...@gmail.com> wrote:

> Hi everyone!
>
> Regarding the dependency tree, I guess the latest changes added a
> dependency on pyxdg and stalonetray for the new configuration that
> fvwm ships by default.
>
> Is there something else that has been added or removed at lib level?
>
>
Those are the only ones that I can think of that have changed. In this case
I would considered them optional dependencies. The default-config will work
if stalonetray is not installed (in this case there is just no systemtray
in the panel). The python dependency is only for the fvwm-menu-desktop
script and xdg menus. Since this seems to be the standard menu system it
should be added if you want users to have menus work without having to
install extra packages. So without the python dependency and a .menu file,
system menus cannot be generated via the script.

Note that fvwm-menu-desktop also requires a .menu file, as fvwm does not
provide one. You may want to add a dependency to some gentoo package that
provides a .menu for the user to use as well. In the Debian package I have
put these as recommended packages (both python-xdg, stalonetray and a menu
(lxde menu is the one I like the best in Debian)), but not required depends.



jaimos

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​

Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory

[Jaimos Skriletz]

On Sun, Oct 16, 2016 at 5:01 PM, Dominik Vogt  wrote:

> On Sun, Oct 16, 2016 at 05:09:57PM +0100, Thomas Adam wrote:
> > On Sun, Oct 16, 2016 at 04:48:34PM +0100, Dominik Vogt wrote:
> > > Maybe it's a silly question, but *why* does fvwm need mandatory
> > > image support at all?  Arent's images in a window manager just
> > > gimmicks?
> >
> > It's not a silly question, but I'd hoped the commit message said enough.
> > Gimmick is a matter of perspective.  I'm trying to stike a balance
> through
> > useability.  I don't think it's unreasonable to assume one image library
> as
> > the de facto; others are still available.  I'm trying to frame this in
> terms
> > of:
> >
> > * Making the default config useable and useful (which from what I'm
> seeing,
> >   does entail some form of image loading (for icons im menus and
> elsewhere)
> >
> > * Integrating with other third-party applications which generate menus
> (which
> >   use PNG).
>
> I completely understand that, and PNG seems to be a sensible
> choice.  The thing I'm unsure about is whether it should be
> possible to build fvwm without any libraries and expendable
> features to have a lean, minimalistic WM.  But I've honestly no
> idea whether anybody did that in the recent past or not.
> Perosnally, if I weren't too lazy to change the config, I could
> perfectly do without image support:  The menu logo is just
> decoration, icons work as well when done as text, and the
> FvwmButtons images could be replaced by thext or just menu
> entries.
>
>
What about having libpng be default but having a --disable-libpng
./configure option to disable? Have it set up to error out if libpng and
that option are not present with an error that says building without libpng
may affect the default config and other applications. If you want to build
without libpng use --disable-libpng.

This way if someone really wants to build without image support they can
without having to edit the configure script. Though the answer to having
such an option may be on what happens when fvwm hits the .png images in the
default config without support. I'm hoping it just throws a warning and
leaves a blank place where the image should be.

jaimos​

fvwm-perllib patch

[Jaimos Skriletz]

Hello,

There was a bug reported in Debian about fvwm-perllib man's use of
pod2man via a pipe.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777471

Summary: Newer versions of pop2man will give an error if the --name
flag is not present and sets the title to STDIN if error handling is
set to proceed despite errors.

The attached patch adds the --name flag to the pod2man call to set the
manpage name.

In addition when testing this perl gave me deprecated warnings about
use of {} in regex without being escaped. The patch also adds escape
characters to {} inside of regex.

jaimos
Description: Adds --name '$topic' to pod2man and fixes deprecated warning.
 pod2man used in a pipe needs a --name to set manpage name.
 pod2man now errors out or defaults the title to STDIN if error handling
 is set to proceede despite errors.
 .
 Fixed a deprecated warning about unescaped braces {} in regex.
Author: Jaimos Skriletz <jaimosskril...@gmail.com>
Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777471
--- a/bin/fvwm-perllib.in
+++ b/bin/fvwm-perllib.in
@@ -390,7 +390,7 @@ if (exists $internal_pods->{$topic}) {
 	if ($topic eq 'index') {
 		my @class_names = sort @{list_filenames($perllibdir, 1)};
 		@class_names = map { s!\.pm$!!; s!/!::!g; $_ } @class_names;
-		$text =~ s/{{CLASS_NAMES}}/join("\n", @class_names)/seg;
+		$text =~ s/\{\{CLASS_NAMES\}\}/join("\n", @class_names)/seg;
 	}
 
 	if ($topic eq 'events') {
@@ -404,7 +404,7 @@ if (exists $internal_pods->{$topic}) {
 			/eg;
 			$result .= "\n";
 		}
-		$text =~ s!{{EVENT_NAMES}}!$result!se;
+		$text =~ s!\{\{EVENT_NAMES\}\}!$result!se;
 	}
 
 } else {
@@ -416,7 +416,7 @@ if (exists $internal_pods->{$topic}) {
 my $man_converter = $do_man ? " | nroff -man | $pager" : "";
 open(MANPIPE, $do_cat ? "| pod2text '$file' | $pager" :
 	"| pod2man --section 3 --release 'fvwm $version$version_info'" .
-		" --center 'Fvwm Perl library' '$file'" .
+		" --center 'Fvwm Perl library' --name '$topic' '$file'" .
 		" | @SED@ 's//perllib/ig'$man_converter")
 	or die "Can't open pipe to pod/man viewer\n";
 print MANPIPE $text

Re: Bug#802604: fvwm: focus is not given to the window when changing page with invisible mouse pointer

[Jaimos Skriletz]

On Sat, Dec 31, 2016 at 6:11 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> On Sat, Dec 31, 2016 at 05:37:45AM -0700, Jaimos Skriletz wrote:
>> On Sat, Dec 31, 2016 at 4:11 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>> > On Fri, Dec 30, 2016 at 09:12:50PM -0700, Jaimos Skriletz wrote:
>> >> On Fri, Dec 30, 2016 at 8:49 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>> >> > On Fri, Dec 30, 2016 at 08:24:07PM -0700, Jaimos Skriletz wrote:
>> >> >> Hello,
>> >> >>
>> >> >> This was reported by a Debian user. Please retain the CC to
>> >> >> 802604-forwar...@bugs.debian.org in your response, so that
>> >> >> the Debian BTS has a record.
>> >> >>
>> >> >> In short if the mouse cursor is over the root window and hidden with
>> >> >> unclutter, when switching pages (and maybe desks), focus is not given
>> >> >> to the window under the pointer.
>> >> >
>> >> > Works fine for me.  I'd need a precise description + config file
>> >> > to test this.
>> >> >
>> >>
>> >> Using SloppyFocus with a 2x2 grid of pages with the default config and
>> >> the following two key bindings
>> >>
>> >> Key Right A CM Scroll 100 0
>> >> Key Left A CM Scroll -100 0
>> >>
>> >> I then run unclutter to hide the mouse after being idle for a second:
>> >>
>> >> unclutter -idle 1 -root
>> >>
>> >> I move the mouse over the root window and wait for it to be hidden.
>> >> Once it is hidden
>> >> I use the key binding to switch to a new page. After I switch to the
>> >> page focus is kept
>> >> on the window in the old page and is not transferred.
>> >
>> > Still does not happen for me.  With unclutter 8-18 (Debian):
>> >
>> >  * Start fvwm with default config.
>> >  * Open two Xterms from the menu (left side of screen).
>> >  * Open FvwmConsole and move it to the bottom right corner.
>> >  * Type
>> >  style * sloppyfocus
>> >  Key Right A CM Scroll 100 0
>> >  Key Left A CM Scroll -100 0
>> >in FvwmConsole.
>> >  * Run "unclutter -idle 1 -root" from one of the Xterms.
>> >  * Press ctrl-alt-right to switch to page (1 0).
>> >  * (Optional: open an Xterm there and close it to take away the
>> >focus from any window on (0 0).)
>> >  * Move the pointer roughly to the middle of the FvwmConsole
>> >window.
>> >  * Press ctrl-alt-left to switch to page (0 0).
>> >  => The pointer ends up over FvwmConsole which gets the focus.
>> >
>>
>> These steps work for me.
>
> "Work" = "the window does not get focus"?
>

Yes work, as in reproduces the issue.

>> I tried with various versions of the optional
>> step, though in my tests I left the xterm around, but this did not
>> seem to matter, Leaving the xterm or not did not change the result.
>
> Neither for me.
>
>> Unsure how else to describe it as those steps cause this to happen,
>> just tested again in a VM and have attached screen shots to show how
>> the focus is right before and right after I switch pages. In the
>> before picture the mouse is in the bottom right corner over the root
>> window near the panel (but not over it) and unclutter has hidden the
>> mouse.
>>
>> Only other thing I note, as soon as I move the mouse, focus is then
>> given to the window under the mouse, but until then it remains on the
>> window on the previous page.
>
> You probably have a different version of unclutter.  In the past,
> there was some change of the method it uses to hide the pointer.
> his may well play a role here.  Can you find out which version you
> have?  I guess it's something that should be fixed in unclutter if
> it's still an issue with the latest version.
>

Using the version from Debian stretch, 8-20.

I downgraded to the wheezy version, 8-18 that you reported to use, and
no longer can reproduce this bug. So it is something with a change in
unclutter. I will reassign the bug to unclutter.

Thanks for the help.

jaimos

Menu hot keys with accented characters

[Jaimos Skriletz]

Hello,

Here is an old (minor) bug that is lurking in the Debian BTS.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464363

The bug is that when assigning non ASCII keys as hot keys in a Menu,
the underline underlines the non ASCII character and the one after it.

Here is a simple test

DestroyMenu TestMenu
AddToMenu TestMenu "Test" Title
+ "T&êst" Echo Test
+ "&ñice one" Echo Nice One
+ "Th&ááát" Echo Thaaat
+ " One" Echo This

Then open the menu.

In addition to the visual bug, I was not able to correctly use these
non-ASCII characters as hot keys. Since I don't have a keyboard that
has accented keys on them it could be that I can't properly test if
they work as hot keys (since I have to hit alt-key to type them).

Seems there was once a patch trying to make these hot keys work better

http://www.mail-archive.com/fvwm-workers@fvwm.org/msg01916.html

Unsure if the bug is just an extra character is underlined in the Menu
or if using non ASCII characters for hot-keys doesn't work.

jaimos

Re: Improving the default config

[Jaimos Skriletz]

On Sat, Dec 31, 2016 at 8:31 AM, Dominik Vogt  wrote:
> On Sat, Dec 31, 2016 at 04:18:26PM +0100, Dominik Vogt wrote:
>> See branch dv/devel for various patches.
>
> (Feel free to use any of these patches to build a new patch.)
>

Thanks. I incorporated some of your suggestions.

I have hopefully made fvwm-menu-desktop error out nicer when either
python-xdg or a .menu file is not found.

In additions I have grouped some of your config changes (and some I
had in mind) into a single patch on js/default-config-changes.

Hopefully the commits explain enough, if you have any questions please ask.

happy new year.

jaimos

Re: Menu hot keys with accented characters

[Jaimos Skriletz]

On Sun, Jan 8, 2017 at 3:14 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> On Sun, Jan 01, 2017 at 02:10:03AM -0700, Jaimos Skriletz wrote:
>> Here is an old (minor) bug that is lurking in the Debian BTS.
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464363
>>
>> The bug is that when assigning non ASCII keys as hot keys in a Menu,
>> the underline underlines the non ASCII character and the one after it.
>
> Hotkeys must be printable 7 bit Ascii characters, which is
> probably not documented.  The reason for this is that the hotkey
> is specified as a substring from the item label (e.g. "á") instead
> of a key name ("aacute").  X has no real way to convert a string
> into a key name or vice versa, so hotkeys work only for keys where
> both representations are the same.
>

If keybindings for non 7 bit ASCII keys don't work, documentation
could be useful. Though this has been around for a long time and not
many seem to mention it so it probably isn't a big deal in the overall
picture.

>
>> Here is a simple test
>>
>> DestroyMenu TestMenu
>> AddToMenu TestMenu "Test" Title
>> + "T&êst" Echo Test
>> + "&ñice one" Echo Nice One
>> + "Th&ááát" Echo Thaaat
>> + " One" Echo This
>>
>> Then open the menu.
>
> I can reproduce the drawing bug.  Maybe we should simply disable
> hotkeys completely for anything not 7 bit ASCII.
>

Disabling the keys since they aren't working anyways and giving a
warning may be useful for those who try to use non ASCII characters.
Such a warning should only trigger when items are added to the menu,
not each time the menu pops up.

At least this way if anyone tries to use non-ASCII characters they are
correctly informed that they do not work and this can move to a
feature request to add support for these keys.

thanks for looking into this.

jaimos

Re: Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed

[Jaimos Skriletz]

On Tue, Dec 27, 2016 at 3:44 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> On Mon, Dec 26, 2016 at 01:17:05PM -0700, Jaimos Skriletz wrote:
>> Hello,
>>
>> This was reported by a Debian user. Please retain the CC to
>> 849355-forwar...@bugs.debian.org in your response, so that
>> the Debian BTS has a record.
>>
>> In short when running FvwmIconMan, fvwm prints warnings to stderr when
>> opening and closing windows. I too have had this issue in 2.6.7 (and
>> previous versions) so I can also say it affects my Debian system.
>
>
> I don't get any such messages with or without FvwmIconMan.  Can
> you give detailed instructions pelase?
>

Using Fvwm 2.6.7 Debian package, doubt it is any of the debian
patches, but I will compile a version without patches and test.

Run FvwnIconMan by itself with no configuration, so FvwmIconMan is in
its own window (if FvwmIconMan was swallowed in FvwmButtons I did not
notice this warning).

Once FvwmIconMan is running, run xterm, warning appears, close xterm,
warning appears again.

I tested this with other windows and modules. FvwmScript modules
seemed to trigger it, FvwmIdentify did not, so I wonder if it has to
do with transient windows or not (just something I noticed).

If you are not able to reproduce this wonder if it is something
specific with Debian's xserver, let me know what other output you
would want.

jaimos

Re: Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed

[Jaimos Skriletz]

On Tue, Dec 27, 2016 at 5:15 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> On Tue, Dec 27, 2016 at 05:04:40PM -0700, Jaimos Skriletz wrote:
>> On Tue, Dec 27, 2016 at 4:52 PM, Jaimos Skriletz
>> <jaimosskril...@gmail.com> wrote:
>> > On Tue, Dec 27, 2016 at 3:44 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>> >> On Mon, Dec 26, 2016 at 01:17:05PM -0700, Jaimos Skriletz wrote:
>> >>> Hello,
>> >>>
>> >>> This was reported by a Debian user. Please retain the CC to
>> >>> 849355-forwar...@bugs.debian.org in your response, so that
>> >>> the Debian BTS has a record.
>> >>>
>> >>> In short when running FvwmIconMan, fvwm prints warnings to stderr when
>> >>> opening and closing windows. I too have had this issue in 2.6.7 (and
>> >>> previous versions) so I can also say it affects my Debian system.
>> >>
>> >>
>> >> I don't get any such messages with or without FvwmIconMan.  Can
>> >> you give detailed instructions pelase?
>> >>
>> >
>> > Using Fvwm 2.6.7 Debian package, doubt it is any of the debian
>> > patches, but I will compile a version without patches and test.
>> >
>>
>> Tested with a fresh compile of Fvwm 2.6.7 without any debian patches,
>> same issue.
>>
>> >
>> > I tested this with other windows and modules. FvwmScript modules
>> > seemed to trigger it, FvwmIdentify did not, so I wonder if it has to
>> > do with transient windows or not (just something I noticed).
>> >
>>
>> Nevermind this, FvwmIdentify is not a traisnent window, the reason it
>> was not producing the warning was it was configured so FvwmIconMan did
>> not create a button for that window.
>>
>> After further testing the warning seems to be due to be caused by
>> adding/removing the button for a window from FvwmIconMan. Windows that
>> appear there trigger the warning but ones that don't appear don't.
>
> Still no luck to reproduce it.  After said message there should
> always be this one which prints all the details of the window and
> the faulty hints:
>
> fvwm_msg(
> WARN, "GetWindowSizeHints",
> "The application window (id %#lx)\n"
> "  \"%s\" has broken size hints (%s).\n"
> "fvwm is ignoring those hints.  "
> "  hint override = %d, flags = %lx\n"
> "  min_width = %d, min_height = %d, "
> "max_width = %d, max_height = %d\n"
> "  width_inc = %d, height_inc = %d\n"
> "  min_aspect = %d/%d, max_aspect = %d/%d\n"
> "  base_width = %d, base_height = %d\n"
> "  win_gravity = %d\n",
>

I get no other output after the warning, so that message is never
printed to stderr on my system.

Unsure if this helps, but I did enable BugOpts DebugCRMotionMethod,
and get the output

_cdim: not moved 0x55927d4a8990 'FvwmIconMan'

after each time the warning is produced.

Spelling errors and manpage patchs

[Jaimos Skriletz]

Hello,

In making the Debian package lintian found some spelling errors in
both the man page and some binaries. Patch attached.

Additionally a Debian user noticed that the manpage under ClickTime
did not specify this also configures time for double clicks. The
second patch just adds a small note to this.

jaimos
Description: Add double click time info to ClickTime in manpage.
Author: Jaimos Skriletz <jaimosskril...@gmail.com>
Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567387
--- a/doc/commands/ClickTime.xml
+++ b/doc/commands/ClickTime.xml
@@ -26,4 +26,6 @@ is 150 milliseconds.  Omitting the delay
 ClickTime
 to the default.
 
+ClickTime also specifies the delay
+between two clicks to be interpreted as a double-click.
 
Description: Spelling Errors.
 Fixes spelling errors found by lintian.
Author: Jaimos Skriletz <jaimosskril...@gmail.com>
Last-Update: 2016-12-05
--- a/modules/FvwmCommand/FvwmCommand.c
+++ b/modules/FvwmCommand/FvwmCommand.c
@@ -532,7 +532,7 @@ void usage(void)
   fprintf (stderr,
 	   "  -v  print version number\n");
   fprintf (stderr,
-	   "  -w   waiting time for the reponse from fvwm\n");
+	   "  -w   waiting time for the response from fvwm\n");
   fprintf (stderr, "\nDefault fifo names are ~/.%sC and ~/.%sM\n",
 	   MYNAME, MYNAME);
   fprintf (stderr, "Default waiting time is 500,000 us\n");
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -4213,7 +4213,7 @@ void InitEventHandlerJumpTable(void)
 	{
 		/* should never happen */
 		fvwm_msg(ERR, "InitEventHandlerJumpTable",
-			 "Faild to initialize event handlers");
+			 "Failed to initialize event handlers");
 		exit(1);
 	}
 	if (FShapesSupported)
@@ -4231,7 +4231,7 @@ void InitEventHandlerJumpTable(void)
 shape_jump_table))
 		{
 			fvwm_msg(ERR, "InitEventHandlerJumpTable",
- "Faild to init Shape event handler");
+ "Failed to init Shape event handler");
 		}
 	}
 
--- a/fvwm/builtins.c
+++ b/fvwm/builtins.c
@@ -611,7 +611,7 @@ static char *ReadMultiPixmapDecor(char *
 			{
 fvwm_msg(
 	ERR, "ReadMultiPixmapDecor",
-	"Colorset shoule take one or two "
+	"Colorset should take one or two "
 	"positive integers as argument");
 			}
 			else
--- a/modules/FvwmScript/Instructions.c
+++ b/modules/FvwmScript/Instructions.c
@@ -794,7 +794,7 @@ static char *FuncSendMsgAndGet(int *NbAr
   FILE *f;
   struct timeval timeout;
 
-  /* comunication name */
+  /* communication name */
   (*NbArg)++;
   com_name=CalcArg(TabArg,NbArg);
   /* the command send to the receiver */
@@ -851,7 +851,7 @@ static char *FuncSendMsgAndGet(int *NbAr
   if (i > IN_FIFO_NBR_OF_TRY)
   {
 	fprintf(stderr,
-	 "[%s][GetMsgAndGet]: <> No in fifo %s for comunication %s\n",
+	 "[%s][GetMsgAndGet]: <> No in fifo %s for communication %s\n",
 	  ScriptName,in_fifo,com_name);
 	close(filedes);
 	err = 1;
@@ -908,7 +908,7 @@ static char *FuncSendMsgAndGet(int *NbAr
   if (i > OUT_FIFO_NBR_OF_TRY)
   {
 	fprintf(stderr,
-	 "[%s][GetMsgAndGet]: <>: No out fifo %s for comunication %s\n",
+	 "[%s][GetMsgAndGet]: <>: No out fifo %s for communication %s\n",
 	 ScriptName,out_fifo,com_name);
 	err = 1;
 	break;
--- a/modules/FvwmBacker/FvwmBacker.1.in
+++ b/modules/FvwmBacker/FvwmBacker.1.in
@@ -101,7 +101,7 @@ Cancels the effect of the previous optio
 It it possible to replace FvwmBacker's configuration at run-time,
 although it is not yet possible to remove existing configuration
 lines.  This is done by simply removing the old configuration from
-withing fvwm and then read a new one.  This can be done in many
+within fvwm and then read a new one.  This can be done in many
 ways, for example by using an fvwm function or one of the modules
 .BR FvwmCommand " or " FvwmConsole .
 
--- a/modules/FvwmButtons/FvwmButtons.1.in
+++ b/modules/FvwmButtons/FvwmButtons.1.in
@@ -988,7 +988,7 @@ inside the relief and padding.
 
 .SH DYNAMICAL ACTIONS
 A running FvwmButtons instance may receive some commands at run time.
-This is achived using the fvwm command
+This is achieved using the fvwm command
 .nf
 .sp
 SendToModule FvwmButtons-Alias  
--- a/modules/FvwmPerl/FvwmPerl.1
+++ b/modules/FvwmPerl/FvwmPerl.1
@@ -204,7 +204,7 @@ The following 5 options are only valid t
 If \fB\-\-nolock\fR is added here, \fBModuleSynchronous\fR returns immediately. Note that \fBModule\fR returns immediately regardless of this option.
 .SH "USING ALIAS"
 .IX Header "USING ALIAS"
-Aliases allow to have several module invocations and work separately with all invocations, here is an example:
+Aliases allow one to have several module invocations and work separately with all invocations, here is an example:
 .PP
 .Vb 4
 \&ModuleSynchronous FvwmPerl FvwmPerl\

Re: Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed

[Jaimos Skriletz]

On Tue, Dec 27, 2016 at 4:52 PM, Jaimos Skriletz
<jaimosskril...@gmail.com> wrote:
> On Tue, Dec 27, 2016 at 3:44 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>> On Mon, Dec 26, 2016 at 01:17:05PM -0700, Jaimos Skriletz wrote:
>>> Hello,
>>>
>>> This was reported by a Debian user. Please retain the CC to
>>> 849355-forwar...@bugs.debian.org in your response, so that
>>> the Debian BTS has a record.
>>>
>>> In short when running FvwmIconMan, fvwm prints warnings to stderr when
>>> opening and closing windows. I too have had this issue in 2.6.7 (and
>>> previous versions) so I can also say it affects my Debian system.
>>
>>
>> I don't get any such messages with or without FvwmIconMan.  Can
>> you give detailed instructions pelase?
>>
>
> Using Fvwm 2.6.7 Debian package, doubt it is any of the debian
> patches, but I will compile a version without patches and test.
>

Tested with a fresh compile of Fvwm 2.6.7 without any debian patches,
same issue.

>
> I tested this with other windows and modules. FvwmScript modules
> seemed to trigger it, FvwmIdentify did not, so I wonder if it has to
> do with transient windows or not (just something I noticed).
>

Nevermind this, FvwmIdentify is not a traisnent window, the reason it
was not producing the warning was it was configured so FvwmIconMan did
not create a button for that window.

After further testing the warning seems to be due to be caused by
adding/removing the button for a window from FvwmIconMan. Windows that
appear there trigger the warning but ones that don't appear don't.

jaimos

Re: Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed

[Jaimos Skriletz]

On Tue, Dec 27, 2016 at 5:28 PM, Jaimos Skriletz
<jaimosskril...@gmail.com> wrote:
> On Tue, Dec 27, 2016 at 5:15 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>> On Tue, Dec 27, 2016 at 05:04:40PM -0700, Jaimos Skriletz wrote:
>>> On Tue, Dec 27, 2016 at 4:52 PM, Jaimos Skriletz
>>> <jaimosskril...@gmail.com> wrote:
>>> > On Tue, Dec 27, 2016 at 3:44 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>>> >> On Mon, Dec 26, 2016 at 01:17:05PM -0700, Jaimos Skriletz wrote:
>>> >>> Hello,
>>> >>>
>>> >>> This was reported by a Debian user. Please retain the CC to
>>> >>> 849355-forwar...@bugs.debian.org in your response, so that
>>> >>> the Debian BTS has a record.
>>> >>>
>>> >>> In short when running FvwmIconMan, fvwm prints warnings to stderr when
>>> >>> opening and closing windows. I too have had this issue in 2.6.7 (and
>>> >>> previous versions) so I can also say it affects my Debian system.
>>> >>
>>> >>
>>> >> I don't get any such messages with or without FvwmIconMan.  Can
>>> >> you give detailed instructions pelase?
>>> >>
>>> >
>>> > Using Fvwm 2.6.7 Debian package, doubt it is any of the debian
>>> > patches, but I will compile a version without patches and test.
>>> >
>>>
>>> Tested with a fresh compile of Fvwm 2.6.7 without any debian patches,
>>> same issue.
>>>
>>> >
>>> > I tested this with other windows and modules. FvwmScript modules
>>> > seemed to trigger it, FvwmIdentify did not, so I wonder if it has to
>>> > do with transient windows or not (just something I noticed).
>>> >
>>>
>>> Nevermind this, FvwmIdentify is not a traisnent window, the reason it
>>> was not producing the warning was it was configured so FvwmIconMan did
>>> not create a button for that window.
>>>
>>> After further testing the warning seems to be due to be caused by
>>> adding/removing the button for a window from FvwmIconMan. Windows that
>>> appear there trigger the warning but ones that don't appear don't.
>>
>> Still no luck to reproduce it.  After said message there should
>> always be this one which prints all the details of the window and
>> the faulty hints:
>>
>> fvwm_msg(
>> WARN, "GetWindowSizeHints",
>> "The application window (id %#lx)\n"
>> "  \"%s\" has broken size hints (%s).\n"
>> "fvwm is ignoring those hints.  "
>> "  hint override = %d, flags = %lx\n"
>> "  min_width = %d, min_height = %d, "
>> "max_width = %d, max_height = %d\n"
>> "  width_inc = %d, height_inc = %d\n"
>> "  min_aspect = %d/%d, max_aspect = %d/%d\n"
>> "  base_width = %d, base_height = %d\n"
>> "  win_gravity = %d\n",
>>
>
> I get no other output after the warning, so that message is never
> printed to stderr on my system.
>
> Unsure if this helps, but I did enable BugOpts DebugCRMotionMethod,
> and get the output
>
> _cdim: not moved 0x55927d4a8990 'FvwmIconMan'
>
> after each time the warning is produced.

Further testing, if I set the ManagerGeometry to something like 5x3 so
FvwmIconMan doesn't resize itself, I no longer get the warning. It is
only with the default like 0x1, causing the window to grow/shrink I
get the warning.

Wild guess, could it be some timing issue during the resizing of the
window when adding/removing a button cause the window's current size
to become invalid as per the warning?

jaimos

Manpage patch + NEWS patch for 2.6.7

[Jaimos Skriletz]

Hello,

A Debian user pointed out that the manpages still mentioned some of
the removed modules. The attach patch either removes or updates the
manpages reference to the modules that were removed in 2.6.7.

Additionally it was also pointed out that FvwmDebug was not included
in the list of removed modules in the NEWS file.

Attached are patches to use as needed.

jaimos
--- a/doc/commands/Module.xml
+++ b/doc/commands/Module.xml
@@ -26,7 +26,6 @@ spawned. Currently several modules, incl
 ,
 ,
 ,
-,
 ,
 
 support aliases.  Aliases are useful if more than one instance of
@@ -53,12 +52,8 @@ Module FvwmForm MyForm
  (a command server to use with shell's FvwmCommand client),
  (to execute fvwm commands directly),
  (to preprocess your config with cpp),
- (to help debug fvwm),
- (the place to dragdrop to),
  (trigger various actions by events),
  (to bring up dialogs),
- (to bring up GTK menus and dialogs),
- (like the mwm IconBox),
  (a flexible icon manager),
  (to get window info),
  (to preprocess your config with m4),
@@ -66,16 +61,7 @@ Module FvwmForm MyForm
  (a Perl manipulator and preprocessor),
  (to locate and control obscured windows by using small proxy windows),
  (to rearrange windows),
- (saves the desktop state in .xinitrc style),
- (saves the desktop state in fvwm commands),
  (another powerful dialog toolkit),
- (puts scrollbars on any window),
- (a generic tabbing module),
- (a Windows like task bar),
- (managed colorsets, obsolete),
- (an AfterStep like button bar),
- (a configurable fvwm menu listing current windows),
- (a window list).
 These modules have their own man
 pages.  There may be other modules out on there as well.
 
--- a/doc/commands/Colorset.xml
+++ b/doc/commands/Colorset.xml
@@ -237,22 +237,15 @@ uses Colorset 10 as background. If you w
 the
 RootTransparent
 option.
-,
+
 ,
-,
-
 and
-
+,
 are relatively simple. There is one main colorset option which
 defines the background of the window and the other colorsets (if
 any) are drawn on the foreground. The case of
- and
-
-are simpler. With
-
-all the colorsets are drawn on the foreground and with
 
-the two colorsets refer to the window backgrounds.
+is simpler, the two colorsets refer to the window backgrounds.
 
 is more complicated as almost everything in the pager are windows
 with some parental relations (the mini windows are the child and
--- a/doc/fvwm/initialization.xml
+++ b/doc/fvwm/initialization.xml
@@ -136,14 +136,14 @@ is used instead of ExitFunction.
  InitFunction
  InitFunction
  + I  
- + I  
+ + I  
  + I  xsetroot -solid cyan
  + I  xterm
  + I  netscape
 
  RestartFunction
  RestartFunction
- + I  
+ + I  
 
  SessionInitFunction
  SessionInitFunction
--- a/doc/commands/LocalePath.xml
+++ b/doc/commands/LocalePath.xml
@@ -87,8 +87,6 @@ parameter:
 available.
 
 Note that the
-
-module has its own catalog and that the
 
 module has a set of special instructions for string
 translation. It is out of the scope of this discussion to explain
--- a/doc/commands/Style.xml
+++ b/doc/commands/Style.xml
@@ -1105,7 +1105,7 @@ window. This miniature icon can be drawn
 (see
 ),
 and can be used by various fvwm modules
-(,  and ).
+( and ).
 It takes the name of a pixmap as an argument.
 
  and 
@@ -2265,8 +2265,8 @@ Style rxvt !State 11
 
 styles do not appear in the menu that is created with the
 
-command or the lists shown in several modules like
- or .
+command or the lists shown in modules like
+.
 In the modules, the style can usually be ignored with an option.
 Please refer to the man page of the module in question for
 further information.  To disable this feature, use the default
--- a/doc/commands/Wait.xml
+++ b/doc/commands/Wait.xml
@@ -44,8 +44,8 @@ After the xmh window appears control mov
 Fvwm remains partially functional during a wait, but any input
 from the modules is queued up and processed only after the window
 appears or the command is aborted.  For example, windows can not
-be focused with  or 
- during a wait.
+be focused with  or
+ during a wait.
 
 You can escape from a
 Wait
--- a/doc/fvwm/colorsets.xml
+++ b/doc/fvwm/colorsets.xml
@@ -24,7 +24,8 @@ other color operations.
 
 was introduced to manage colorsets.  Starting with the 2.5.x beta
 version, the  functionality was moved to the core fvwm,
-so this module became obsolete.
+so this module became obsolete. In 2.6.7 the 
+module was removed.
 
 The old syntax:
 
--- a/doc/fvwm/virtualDesktop.xml
+++ b/doc/fvwm/virtualDesktop.xml
@@ -29,11 +29,11 @@ windows on a range of desktops can be vi
 ,
 a miniature view of the desktops.  The pager is an accessory
 program, called a module, which is not essential for the window
-manager to operate.  Windows may also be listed, along with their
-geometries, in a window list, accessible as a pop-up menu, or as a
-separate window, called the
-
-(another module).
+manager to operate.  Windows may also be listed using the
+
+command or the
+
+module.
 
 Fvwm keeps the windows on the desktop in a 

Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed

[Jaimos Skriletz]

Hello,

This was reported by a Debian user. Please retain the CC to
849355-forwar...@bugs.debian.org in your response, so that
the Debian BTS has a record.

In short when running FvwmIconMan, fvwm prints warnings to stderr when
opening and closing windows. I too have had this issue in 2.6.7 (and
previous versions) so I can also say it affects my Debian system.

-- Forwarded message --
From: Vincent Lefevre 
Date: Sun, Dec 25, 2016 at 6:37 PM
Subject: Bug#849355: fvwm: GetWindowSizeHints warnings when windows
and opened and closed
To: Debian Bug Tracking System 


Package: fvwm
Version: 1:2.6.7-2
Severity: normal

I get the following warnings in my .xsession-errors file (where FVWM's
standard error is redirected):

[fvwm][GetWindowSizeHints]: <> reason: 2: The hints have been
ignored because the window's current size would have become invalid.
The new hints will become active when the window generates the next
ConfigureRequest.

when a window is opened.

[fvwm][GetWindowSizeHints]: <> reason: 4: The hints have been
ignored because the window's current size would have become invalid.
The new hints will become active when the window generates the next
ConfigureRequest.

when a window is closed.

I've tried with windows from the following applications: xterm, Emacs,
xev. This seems to be always reproducible.

This also occurs when I move to a different page with FvwmPager, with
lots of warnings (I assume one for each window of the old and new
pages).

After 23 hours, the size of my .xsession-errors file is 678 KB.
I don't think that the space taken is much a problem, but the major
consequence is that these warnings can easily hide more interesting
warning/error messages (from FVWM or applications started by it).

Edit (from a followup email):

This only occurs when I use the FvwmIconMan module (which I start
from RestartFunction, itself invoked from InitFunction).

If I remove my specific FvwmIconMan configuration, the problem still
occurs.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fvwm depends on:
ii  libc6   2.24-8
ii  libcairo2   1.14.8-1
ii  libfontconfig1  2.11.0-6.7
ii  libfreetype62.6.3-3+b1
ii  libfribidi0 0.19.7-1
ii  libgdk-pixbuf2.0-0  2.36.2-1
ii  libglib2.0-02.50.2-2
ii  libice6 2:1.0.9-1+b1
ii  libperl4-corelibs-perl  0.003-2
ii  libpng16-16 1.6.26-6
ii  libreadline77.0-1
ii  librplay3   3.3.2-16+b1
ii  librsvg2-2  2.40.16-1
ii  libsm6  2:1.2.2-1+b1
ii  libstroke0  0.5.1-8
ii  libtinfo5   6.0+20161126-1
ii  libx11-62:1.6.4-2
ii  libxcursor1 1:1.1.14-1+b1
ii  libxext62:1.3.3-1
ii  libxft2 2.3.2-1
ii  libxinerama12:1.1.3-1+b1
ii  libxpm4 1:3.5.12-1
ii  libxrender1 1:0.9.10-1
ii  perl5.24.1~rc4-1

Versions of packages fvwm recommends:
ii  lxmenu-data  0.1.5-1
ii  python   2.7.13-1
ii  python-xdg   0.25-4

Versions of packages fvwm suggests:
ii  cpp   4:6.2.1-1
ii  libx11-protocol-perl  0.56-7
ii  m41.4.17-5
ii  perl-tk   1:804.033-1+b3
pn  stalonetray   

-- no debconf information

Re: FvwmIconMan still sometimes triggers Hint Warnings

[Jaimos Skriletz]

On Mon, Feb 27, 2017 at 11:10 PM, Jaimos Skriletz
<jaimosskril...@gmail.com> wrote:
> Hello,
>
> FvwmIconMan still reports Hint warnings even with the patchs applied.
>

I wrote this small patch that has FvwmIconMan wait until the window
has resized to set the window hints. This is in the lines of Dominik
Vogt's patch, but waits until FvwmIconMan has fully resized to run
fix_manager_size() to set the window hints. My tests here no longer
seem to tiger the warnings like it still sometimes did.

As an additional thought, talking to Thomas Adam about the patch in
#fvwm, he mentioned that the issue is more FVWM being overly cautious
and the fix should be in how fvwm handles size hint warnings over
working with FvwmIconMan to avoid triggering them.

I don't know enough about the issue to say which is more appropriate,
but here is a patch that stops the warnings from being triggered in my
tests.

jaimos
From 227d7ea2597ec3fec304c53934fcc41773ab7e89 Mon Sep 17 00:00:00 2001
From: Jaimos Skriletz <jaimosskril...@gmail.com>
Date: Tue, 28 Feb 2017 17:43:12 -0700
Subject: [PATCH 1/1] Wait until FvwmIconMan is resized to set window HINTS

---
 modules/FvwmIconMan/xmanager.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/modules/FvwmIconMan/xmanager.c b/modules/FvwmIconMan/xmanager.c
index 58eaaedc..b4efe890 100644
--- a/modules/FvwmIconMan/xmanager.c
+++ b/modules/FvwmIconMan/xmanager.c
@@ -439,6 +439,16 @@ static void resize_window(WinManager *man)
 }
 MyXUngrabServer(theDisplay);
   }
+
+  // Wait until the window has resised to fix the HINTS.
+  // counter is used to break an infinte loop.
+  XWindowAttributes attribs;
+  int counter = 2;
+  while ( counter && (attribs.width != man->geometry.width ||
+  attribs.height != man->geometry.height)) {
+XGetWindowAttributes(theDisplay, man->theWindow, );
+counter--;
+  }
   fix_manager_size(man, man->geometry.width, man->geometry.height);
 }
 
-- 
2.11.0

Sometimes windows remain after the process has died.

[Jaimos Skriletz]

Hello,

This was reported by a Debian user. Please retain the CC to
855206-forwar...@bugs.debian.org in your response, so that
the Debian BTS has a record.

Sometimes when a process stops the window will remain open until some
event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm
will remove the window.

The following script was provided by the user which launches and
closes a large number of xterms. When running this script some of the
xterm windows will remain even though the process is no longer
running.

On Wed, Apr 26, 2017 at 6:13 PM, Vincent Lefevre  wrote:
> Simpler test case:
>
> 
> #!/bin/sh
>
> n=${1:-200}
> n=$((n+0))
>
> for i in `seq $n`; do xterm -geometry 80x24+$((2*i))+$((2*i)) -e true & done
>
> wait
> 

After this script ends a few windows remain and can be moved,
iconified, shaded, resized. But if you run FvwmIdent something is
triggered which removes all the affected windows.

I was not able to reproduce this on my main machine (though rarely I
would have a window stick around for a second or two before it was
removed, most weren't even drawn), but I was able to reproduce this
with the default config on both the debian 2.6.7-3 package and the
master branch from git inside a virtual machine.

thanks for your time,

jaimos

Re: Sometimes windows remain after the process has died.

[Jaimos Skriletz]

On Thu, Apr 27, 2017 at 4:21 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> On Thu, Apr 27, 2017 at 11:04:14AM -0600, Jaimos Skriletz wrote:
>> Sometimes when a process stops the window will remain open until some
>> event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm
>> will remove the window.
>
> That is not possible unless either
>
>  1) the process is not really dead,

The process do not appear in 'ps fax' and the script outputs [Done] on
all the jobs that were run in the background in the shell, so this is
not the case.

>  2) the X server has a bug,

This does seem to be the case. The user and myself both tested this
running an xsession with only an xterm. We could not reproduce it with
only running an xterm.

I decided to test another window manager, openbox in this case, and
was able to reproduce the issue in openbox. So it seems to be some bug
with how the xserver but may require a window manager to trigger it.

In all cases trying to get any info from the xserver closes the
windows. I have tried xprop, xwinfo and even just xdpyinfo and xvinfo
will close all the windows that were left open when running that
command.

Thanks for the help, I will forward this bug on to xorg as it affects
more than just fvwm.

jaimos

Re: Sometimes windows remain after the process has died.

[Jaimos Skriletz]

On Thu, Apr 27, 2017 at 5:09 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:

> On Thu, Apr 27, 2017 at 05:00:33PM -0600, Jaimos Skriletz wrote:
> > On Thu, Apr 27, 2017 at 4:21 PM, Dominik Vogt <dominik.v...@gmx.de>
> wrote:
> > > On Thu, Apr 27, 2017 at 11:04:14AM -0600, Jaimos Skriletz wrote:
> > >> Sometimes when a process stops the window will remain open until some
> > >> event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm
> > >> will remove the window.
> > >
> > > That is not possible unless either
> > > ...
> >
> > The process do not appear in 'ps fax' and the script outputs [Done] on
> > all the jobs that were run in the background in the shell, so this is
> > not the case.
> >
> > >  2) the X server has a bug,
> >
> > This does seem to be the case. The user and myself both tested this
> > running an xsession with only an xterm. We could not reproduce it with
> > only running an xterm.
> >
> > I decided to test another window manager, openbox in this case, and
> > was able to reproduce the issue in openbox. So it seems to be some bug
> > with how the xserver but may require a window manager to trigger it.
>
> I wonder what that trigger could be.  If the window can be moved,
> fvwm is communicating with the X server in both directions, so if
> a destroy event was pending it should have been delivered to fvwm
> before any mouse motion events.  Maybe the X server itself has
> destroyed the window internally but not yet sent the event for
> some reason, and does so only when some request for that window is
> issued.  (Moving the fvwm window does not move the client window
> directly but the frame.)
>
> If you type "xsync" in FvwmConsole, does that kill the window?
> (This forces all pending requests and events to be delivered in
> both directions.)  My guess is that it doesn't, i.e. no event is
> pending.
>
>
​Typing xsync into FvwmConsole did not trigger the removal of the windows.
​

> > In all cases trying to get any info from the xserver closes the
> > windows. I have tried xprop, xwinfo and even just xdpyinfo and xvinfo
> > will close all the windows that were left open when running that
> > command.
>
> Does it also kill the window to request information from a
> different (non-zombie) window?
>
>
​It kills them before I even get a chance to pick the window to identify. I
am not able to find away to get any info on the zombie windows, as soon as
I query xorg with xprop or xwinfo, all zombie windows are removed, then it
gives me a pointer to pick a window. If I use FvwmIconMan (which still has
the windows) to Identify via FvwmIdent (using the window ops menu), the
windows disappear and I get no output from FvwmIdent. No errors in
.xsession-errors either.

jaimos

Re: fvwm.org domain name

[Jaimos Skriletz]

On Sat, Feb 10, 2018 at 8:38 AM, Dan Espen  wrote:
>
> Hi,
>
> I've renewed the fvwm.org domain name for the next 9 years.  (The max
> gandi allows for.)  The fvwm.org web site is back up from here.
>
> Hopefully, I'll still be alive in 9 years, but I've got no guarantees.
> I don't think there will be a problem, as I understand it anyone can
> renew.
>

If needed, and we want to go through the pain of transferring the
domain, I can put the domain with some domains I control, such as
fvwmforums.org, which is setup to auto renew.

jaimos

fvwm-menu-desktop and Python 3

[Jaimos Skriletz]

Hello,

I am trying to update the fvwm-menu-desktop script to work in python 3
while being python 2 compatible, since python 2 is nearing end of
life.

I first ran 2to3 on the script and it fixed the majority the syntax
differences. But the script's output had some encoding issues due to
differences in python 2 and 3 in terms of utf-8. I was able to trace
down the issues and get them to work on my system, mostly by bypassing
the decoding/encoding function if using python 3 (I think this is
okay, because python 3 should support utf-8 in strings by default and
not need to encode/decode them).

Just seeing if anyone would want to test the script on their setup if
they use it to see if it works both with Python 3 and Python 2, and
especially with someone who has menus that uses lots of utf-8
characters with accents in them.

You can find the changes in the branch js/fvwm-menu-desktop

You may have to change the she-bang at the top of the script to
#!/usr/bin/python3 if it gets built with python 2.

Thanks,

jaimos

Fvwm pauses in a wait state if a click is too fast

[Jaimos Skriletz]

Hello,

This was reported by a Debian user. Please retain the CC to
849354-forwar...@bugs.debian.org in your response, so that
the Debian BTS has a record.

The full bug report can be found at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849354

In summary I think the bug that the user experiences is due to the
time between a ButtonPress and ButtonRelease event being to quick. The
user has a binding that looks like this:

Mouse 1 A   SCM Raise

Sometimes when clicking on a window to raise it, fvwm will not
register the click fully and then be put into a wait state until the
mouse is clicked a second time, at which time the window is raised.
After some investigation the user discovered that it only happened
with their touchpad and further by looking at xev, only happened when
the time difference between the Press and Release events were less
than 10 units by xev (about 10+ times faster than the times registered
with a normal mouse button). Additionally the user discovered if they
wrapped the Raise call into a function or just held down the button a
little bit longer, the bug did not happen.

My theory is the time is so low there is a race condition. Fvwm gets
and maybe ignores the release event before fvwm fully processes the
press event. Then fvwm gets stuck waiting for a release event, which
happens the next time the mouse is clicked.

When using the function wrapper, this wouldn't happen because the function
wrapper might not necessarily we waiting for a release event like the
mouse binding might be.

So could there be some issue that causes fvwm to pause with such a
binding, as the push would put fvwm in a state that forces it to wait
for the release event to register the click as happening to trigger
the binding, and could a fix be have some timeout while fvwm is
waiting for the release button in this case?

In addition if I make such a binding and then click and hold my mouse
button, fvwm is put into a wait state and won't function until I
release my mouse button, so this seems to help support my theory that
the pause is due to fvwm waiting for the release event. So last
question, could a timeout be useful here to ensure fvwm won't pause
too long waiting for a release event, or is there some reason fvwm
needs to wait for the release event and this is just an issue with the
touchpard hardware sending to quick of press/release events?

Thanks for your time,

jaimos

[fvwmorg/fvwm] b46163: Add lighten/darken capability to colorset expansio...

[Jaimos Skriletz]

  Branch: refs/heads/js/lighten-darken-colors
  Home:   https://github.com/fvwmorg/fvwm
  Commit: b46163d5a60cf76875963ec9951db42e24367ca5
  
https://github.com/fvwmorg/fvwm/commit/b46163d5a60cf76875963ec9951db42e24367ca5
  Author: Jaimos Skriletz <jaimosskril...@gmail.com>
  Date:   2018-04-01 (Sun, 01 Apr 2018)

  Changed paths:
M NEWS
M doc/fvwm/expansion.xml
M fvwm/expand.c
M libs/ColorUtils.c
M libs/ColorUtils.h

  Log Message:
  ---
  Add lighten/darken capability to colorset expansion.

  * Added expansion for appending .lighten and .darken to
a color set expansion, such as $[fg.cs.lighten] or
$[shadow.cs.darken].
  * Added missing $[fgsh.cs] expansion to manpage.

[fvwmorg/fvwm] e66b16: Add lighten/darken capability to colorset expansio...

[Jaimos Skriletz]

  Branch: refs/heads/js/lighten-darken-colors
  Home:   https://github.com/fvwmorg/fvwm
  Commit: e66b16aa1018458f2cb9f781b24bfda11807aaa7
  
https://github.com/fvwmorg/fvwm/commit/e66b16aa1018458f2cb9f781b24bfda11807aaa7
  Author: Jaimos Skriletz <jaimosskril...@gmail.com>
  Date:   2018-04-01 (Sun, 01 Apr 2018)

  Changed paths:
M NEWS
M doc/fvwm/expansion.xml
M fvwm/expand.c
M libs/ColorUtils.c
M libs/ColorUtils.h

  Log Message:
  ---
  Add lighten/darken capability to colorset expansion.

  * Added expansion for appending .lighten and .darken to
a color set expansion, such as $[fg.cs.lighten] or
$[shadow.cs.darken].
  * Added missing $[fgsh.cs] expansion to manpage.