FVWM: key bindings do not work until restart of FVWM [Re: reusing old configs in new versions [...]]
It's two days after Christmas, and finally I have the time to concentrate on the important things of life :-( Thomas Adam wrote: On Fri, Oct 28, 2011 at 10:34:13AM +0200, Michael Großer wrote: Thomas Adam wrote: On Fri, Oct 28, 2011 at 09:50:06AM +0200, Michael Großer wrote: Michelle Konzack wrote: Hello ro...@cloudcabin.org, I have quite a large config with some whistles and bells and maybe a couple dirty hacks in it and I use Archlinux (which means bleeding edge, constant updates and such), I think the first version I tried was 2.5.27, and not a single feature was broken with an update. I have strted using Fvwm2 in March 1999 and the config works up to NOW. Last year, I came back to fvwm after 10 years and started to learn how to configure it. I started with version 2.5.26 (Debian Lenny). Eleven days ago, I migrated an existing (still dirty, but extremly powerful) configuration to a new Debian Squeeze plattform with FVWM 2.5.30. I had to change the order of some code to make my config work with FVWM 2.5.30. So you swapped around the Key binding lines after the function definitions? This simply just isn't true -- they both work the same. -- Thomas Adam I also couldn't believe this. Maybe, the 2.5.30 has a bug that is fixed in later releases? No, this won't be true either. Whatever! I just leave this order now to be able to use all versions of FVWM, even the buggy ones. No, it's never just Whatever!. If you've found a problem, I want to know about it. All I can tell you with absolute certainty is it has nothing to do with you reordering lines in your config. So put your config somewhere with it still exhibiting the problem for you, and I'll take a look. -- Thomas Adam Hi! The reason was another bug, which let me think that I have to change the order of something in the config files. The real bug is the following: - When I use FVWM 2.5.30 on a Debian Squeeze system with KDM as X display manager, then the key bindings for some keys of my German keyboard do not work until I restart FVWM. Back in the days, I changed the order of something in my config files, restarted FVWM, and then the key bindings worked. This let me think that the order was the reason. - But the real cause why the key bindings worked after the restart of FVWM was because I restarted FVWM! You can download my FVWM config here: http://www.jumping-blue-turtle.com/fvwm/will_disappear_on_2012-01-31/8999_bugdemo_001.tar.bz2 It contains the file 0003_simple_keyboard_bindings. There, I added the following lines of code: # demonstrate the bug. Key Plus A N Exec exec xterm Key Numbersign A N Exec exec xterm Key Minus A N Exec exec xterm This code is supposed to open an xterm when I press the +, the # or the - key on my German keyboard: http://upload.wikimedia.org/wikipedia/commons/3/3c/Cherry_keyboard_105_keys.jpg -- All three keys are near the right Shift key as you can see on the picture. And, here in Germany, we don't need a Shift key to use +, # or -. When I reboot one of my Debian Lenny systems, then all works fine. When I reboot my Debian Squeeze system, then nothing happens if I press these keys. Only after I restart FVWM (for example by pressing my short-cut Ctrl+Alt+Pause), these three keys open xterm windows when I hit them. * Can anybody reproduce this behaviour? * Is this a known bug? * What could be the cause of this behaviour? * What can I do to let these keys work without having to restart FVWM? Best regards from Germany, Michael
my current approach to manage desktops [Re: FVWM: Fvwmpager crashes if no pages are to be shown]
Thomas Adam wrote: On Sun, Aug 29, 2010 at 01:10:42PM +0200, Michael Großer wrote: Thomas Adam wrote: On Fri, Aug 13, 2010 at 12:51:44AM +0200, michael.gros...@gmx.de wrote: On Thu, Aug 12, 2010 at 04:21:53PM +0200, michael.gros...@gmx.de wrote: Hi! I think that I found the first bug. I made a combination of pagers for me as shown in the attachment. Straight in the bottom left corner, I made an FvwmPager that I called minipager. I gave it these Geometry attributes: *minipager: Geometry 110x44+2+978 I deliberately chose the 44 to hide the viewports (pages). I only want to see the desks and nothing else (see the PNG attachment). But, this size specification 44 triggers the bug. The problem is, as soon as I hold down the Shift+Win+Right key binding (or any other binding - see my attached binding config file) to quickly scroll through all 12 desks or to scroll through all 12 viewports for 20 seconds, the minipager disappears. I think that it simply crashes. Try not to think -- it's either crashing or it isn't -- and as I suspected, I am unable to reproduce this. Note that I am using 2.5.31 though -- a version you should be using, and one I seem to recall asking you to use before. So I am afraid unless you can ascertain a corefile for me to analyse, or provide additional instructions using FVWM 2.5.31 which *still* exhibit this problem, I am unable to help you. I just now reproduced this bug in Debian Squeeze with FVWM 2.5.30. Core dump and/or FVWM 2.5.31 is more complex, so I will try these options later. Has there been any progress on this? Unfortunately no. I have to work to make my customers happy and earn money :-( Latest news was: It crashes in 2.5.26, 2.5.30 and 2.5.31. I don't think it's crashing at all. In fact, I think FvwmPager is as stable as it's ever been. Without your entire config present, I can't offer an explanation as to why you get the results you do -- it might very well be that the pager is closing, but that's different from crashing. Let's see what I notice first of all: # start several pagers AddToFunc StartFunction + I GotoDesk 0 0 + I FvwmPager minipager 0 11 + I Wait minipager + I GotoDesk 0 0 + I FvwmPager 0 3 + I Wait FvwmPager + I GotoDesk 0 1 + I FvwmPager 0 3 + I Wait FvwmPager ... etc., etc. You seem to have not heeded my very original advise to you regarding *why* the above is problematic. It doesn't have anything to do with your problem, BTW, it's just mildly frustrating that you're asking for help and not doing anything with the advise you're given. It also makes me dubious about how much else you're selectively ignoring, but it's a Bank Holiday for me, so you get the benefit of my doubt. :) (And who says I don't live up to my namesake?) So by this point, for each of your defined desks, we have a separate pager per *page*. Meanwhile, there's only one instance of your minipager running, it's just sticky. Fine. But if it closes, then it closes completely and you'll never see it again. If it crashed you would get a corefile -- I promise you that. So I suspect something is closing it. I don't know what, I *might* be able to tell from looking at the rest of your configs, and even an ~/.xsession-error log, if FVWM ever printed anything there. But I really don't think there's anything untoward happening here. There's no link necessarily between continually bombarding FVWM with module commands to switch desks, and a pager closing/crashing. Heck, I made myself dizzy switching pages and desks earlier, following your instructions, and still couldn't get it to crash. But the minipager there is a gratuitous hack for what is simply a desk chooser -- something you can use FvwmButtons for -- and this is ultimately what you *should* be doing. Here: DestroyModuleConfig foo:* *foo: Columns x *foo: Rows y *foo: (1x1, Title z, Action (Mouse 1) GotoDesk z) ... where: x, y and z, are calculated from $[pages.nx] $[pages.ny], etc. That's an exercise best left to you to work out -- hint: PipeRead is your friend here and a simple for(( .)) loop in sh. Now -- the part that makes this more interesting is making your requirement of seeing only four desks per desk for which you're currently on. Well, here's one way of doing it using FvwmEvent: DestroyModuleConfig foo2:* *foo2: new_desk SomeFunc AddToFunc StartFunction I Module FvwmEvent foo2 DestroyFunc SomeFunc AddToFunc SomeFunc + I KillModule FvwmPager some_alias + I PipeRead `[[ $[desk.n] -le 3 ]] echo \ Module FvwmPager some_alias 0 3 || [[ $[desk.n] -gt 3 ]] [[ $[desk.n] -le 7 ]] \ echo Module FvwmPager some_alias 4 7` ... etc., etc. Note that I'd use a simple modulo calculation to make this easier here. Now -- the interesting part here is that
Re: FVWM: key bindings do not work until restart of FVWM [Re: reusing old configs in new versions [...]]
Michael Großer michael.gros...@gmx.de writes: Thomas Adam wrote: On Fri, Oct 28, 2011 at 10:34:13AM +0200, Michael Großer wrote: Thomas Adam wrote: On Fri, Oct 28, 2011 at 09:50:06AM +0200, Michael Großer wrote: Michelle Konzack wrote: Hello ro...@cloudcabin.org, I have quite a large config with some whistles and bells and maybe a couple dirty hacks in it and I use Archlinux (which means bleeding edge, constant updates and such), I think the first version I tried was 2.5.27, and not a single feature was broken with an update. I have strted using Fvwm2 in March 1999 and the config works up to NOW. Last year, I came back to fvwm after 10 years and started to learn how to configure it. I started with version 2.5.26 (Debian Lenny). Eleven days ago, I migrated an existing (still dirty, but extremly powerful) configuration to a new Debian Squeeze plattform with FVWM 2.5.30. I had to change the order of some code to make my config work with FVWM 2.5.30. So you swapped around the Key binding lines after the function definitions? This simply just isn't true -- they both work the same. -- Thomas Adam I also couldn't believe this. Maybe, the 2.5.30 has a bug that is fixed in later releases? No, this won't be true either. Whatever! I just leave this order now to be able to use all versions of FVWM, even the buggy ones. No, it's never just Whatever!. If you've found a problem, I want to know about it. All I can tell you with absolute certainty is it has nothing to do with you reordering lines in your config. So put your config somewhere with it still exhibiting the problem for you, and I'll take a look. -- Thomas Adam Hi! The reason was another bug, which let me think that I have to change the order of something in the config files. The real bug is the following: - When I use FVWM 2.5.30 on a Debian Squeeze system with KDM as X display manager, then the key bindings for some keys of my German keyboard do not work until I restart FVWM. Back in the days, I changed the order of something in my config files, restarted FVWM, and then the key bindings worked. This let me think that the order was the reason. - But the real cause why the key bindings worked after the restart of FVWM was because I restarted FVWM! You can download my FVWM config here: http://www.jumping-blue-turtle.com/fvwm/will_disappear_on_2012-01-31/8999_bugdemo_001.tar.bz2 It contains the file 0003_simple_keyboard_bindings. There, I added the following lines of code: # demonstrate the bug. Key Plus A N Exec exec xterm Key Numbersign A N Exec exec xterm Key Minus A N Exec exec xterm This code is supposed to open an xterm when I press the +, the # or the - key on my German keyboard: http://upload.wikimedia.org/wikipedia/commons/3/3c/Cherry_keyboard_105_keys.jpg -- All three keys are near the right Shift key as you can see on the picture. And, here in Germany, we don't need a Shift key to use +, # or -. When I reboot one of my Debian Lenny systems, then all works fine. When I reboot my Debian Squeeze system, then nothing happens if I press these keys. Only after I restart FVWM (for example by pressing my short-cut Ctrl+Alt+Pause), these three keys open xterm windows when I hit them. * Can anybody reproduce this behaviour? * Is this a known bug? * What could be the cause of this behaviour? * What can I do to let these keys work without having to restart FVWM? My latest Fedora upgrade left me with a US-international setup that caused a few keys to stop working. Qoute keys became dead prefix keys. The tools I use to fix this are xev and xmodmap. Using xev you can see what the key generates and xmodmap allows you to change the key to what you want. I'm not clear on how restarting Fvwm would matter. Fvwm is really just working with the keys as generated by the X Server. Maybe you should post more info on what your keys are generating and how you restart fvwm. I don't have much experience with KDM. I always get the feeling that these DM things are doing something mysterious. I boot to run level 3 and let my profile run startx. That reads my .xinitrc which runs xmodmap early on to get the keyboard working to my satisfaction. -- Dan Espen
