http://blog.gmane.org/gmane.comp.window-managers.fvwm.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5235 <pre>CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by:tadam12/05/04 08:18:09 Modified files: . : Tag: branch-2_6 ChangeLog libs : Tag: branch-2_6 PictureImageLoader.c Log message: Fix compilation problems. Print to stderr instead. </pre> cvs< at >math.uh.edu 2012-05-04T13:18:09 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5234 <pre>CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by:tadam12/05/02 03:02:44 Modified files: . : Tag: branch-2_6 ChangeLog fvwm : Tag: branch-2_6 menus.c libs : Tag: branch-2_6 PictureImageLoader.c Log message: Improve image loading messages. Give hints to the user why an image couldn't be loaded. </pre> cvs< at >math.uh.edu 2012-05-02T08:02:44 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5233 <pre>CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by:tadam12/04/20 06:21:52 Modified files: . : ChangeLog definitions.inc documentation/manpages/stable: FvwmAnimate.php FvwmAuto.php FvwmBacker.php FvwmBanner.php FvwmButtons.php FvwmCommand.php FvwmConsole.php FvwmConsoleC.pl.php FvwmCpp.php FvwmDebug.php FvwmDragWell.php FvwmEvent.php FvwmForm.php FvwmGtk.php FvwmGtkDebug.php FvwmIconBox.php FvwmIconMan.php FvwmIdent.php FvwmM4.php FvwmPager.php FvwmPerl.php FvwmProxy.php FvwmRearrange.php FvwmSave.php FvwmSaveDesk.php FvwmScript.php FvwmScroll.php FvwmTabs.php FvwmTaskBar.php FvwmTheme.php FvwmWharf.php FvwmWinList.php FvwmWindowMenu.php focus-link.php fvwm-bug.php fvwm-config.php fvwm-convert-2.2.php fvwm-convert-2.4.php fvwm-convert-2.6.php fvwm-menu-desktop.php fvwm-menu-directory.php fvwm-menu-headlines.php fvwm-menu-xlock.php fvwm-perllib.php fvwm-root.php fvwm.php index.php news : index.php Log message: Updated for 2.6.5 </pre> cvs< at >math.uh.edu 2012-04-20T11:21:52 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5232 <pre>Jason, I've released FVWM 2.6.5 -- tarballs in the usual place. Kindly, </pre> Thomas Adam 2012-04-20T11:14:57 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5231 <pre>CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by:tadam12/04/20 06:14:00 Modified files: . : Tag: branch-2_6 NEWS ChangeLog configure.ac Log message: 2.6.6 (CVS HEAD) changes. </pre> cvs< at >math.uh.edu 2012-04-20T11:14:00 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5230 <pre>CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by:tadam12/04/20 06:03:33 Modified files: . : Tag: branch-2_6 ChangeLog NEWS configure.ac docs : Tag: branch-2_6 ANNOUNCE Log message: Update key files in prep for 2.6.5 release. </pre> cvs< at >math.uh.edu 2012-04-20T11:03:33 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5226 <pre>CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by:tadam12/04/14 04:46:38 Modified files: . : Tag: branch-2_6 NEWS modules : Tag: branch-2_6 ChangeLog modules/FvwmPager: Tag: branch-2_6 x_pager.c Log message: Wrap window titles in FvwmPager Patch largely by Anton Khirno. Tweaked by tadam&lt; at &gt; </pre> cvs< at >math.uh.edu 2012-04-14T09:46:38 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5225 <pre>CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by:tadam12/04/14 04:40:45 Modified files: modules : Tag: branch-2_6 ChangeLog Log message: Fix memory leak with InfoStore </pre> cvs< at >math.uh.edu 2012-04-14T09:40:45 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5224 <pre>CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by:tadam12/04/14 04:34:33 Modified files: fvwm : Tag: branch-2_6 infostore.c Log message: Fix memory leak with InfoStore </pre> cvs< at >math.uh.edu 2012-04-14T09:34:33 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5222 <pre>Hi, fvwm-workers; long time no see! GNOME 3 / Unity have ended my 4-year fling and sent me crawling back; I always come back to fvwm, in the end :) I found a segfault when polishing up and modernizing my config, and then found a few much more minor memory issues. The first patch should be non-controversial; the only reason it works at all in some cases is that the mi_store is NULL after the memset (and also writing zeros over some other random memory), and mi_new-&gt;next becomes NULL on the first item being stored. Author: epg &lt;epg&lt; at &gt;pretzelnet.org&gt; Date: Fri Apr 13 22:06:51 2012 -0700 Fix segfault in new_metainfo: Need to memset the newly allocated block of memory at the address held in mi_store, not the stack memory holding that address. The second fixes various memory leaks I found; the latest one is only an issue after the above fix (as mi_store is now pointing to a dead object during initialization rather than a NULL pointer). commit a297778dede814070ddbba7da8ab7d992fddcc9e Author: epg &lt;epg&lt; at &gt;pretzelnet.org&gt; Date: Fri Apr 13 22:28:11 2012 -0700 Don't keep a dead MetaInfo entry at the end of the list. When called with the mi_store global set to NULL, new_metainfo would set mi_store to a new, empty (key == value == NULL) MetaInfo object in addition to the new MetaInfo object it returns to insert_metainfo. insert_metainfo would then set the new key/value in the latter object, setting its next pointer to the extra, "dead" object new_metainfo had created. commit 3ae32d3ada22ce659197db6336f885159817f6f1 Author: epg &lt;epg&lt; at &gt;pretzelnet.org&gt; Date: Fri Apr 13 22:18:24 2012 -0700 Fix memory leak in CMD_InfoStoreAdd: insert_metainfo now always stores a newly allocated copy of value, so free the copy here, rather than leaking it when replacing an existing setting. commit 0456c4473ffda2422d0b04ccce855fc56d5e987f Author: epg &lt;epg&lt; at &gt;pretzelnet.org&gt; Date: Fri Apr 13 22:17:23 2012 -0700 Always use CopyString on value in insert_metainfo. CopyString eats leading and trailing whitespace and throws away everything after a newline; InfoStoreAdd of the same key/value twice in a row should not store something different the second time. This also allows another memory clean-up, by always allocating a new copy of the value, rather than only when replacing. commit c43a45cf63cc5bef8ec20fab62192ba2110bc5c6 Author: epg &lt;epg&lt; at &gt;pretzelnet.org&gt; Date: Fri Apr 13 22:10:49 2012 -0700 Fix memory leak in insert_metainfo when replacing old value: CopyString always allocates a new buffer, so free the old value first. </pre> epg< at >pretzelnet.org 2012-04-14T07:32:43 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5219 <pre>Greetings, I've spent the past few days hunting down a bug that involves an interaction between FVWM and Java 7. I can provide more detail for anyone who is curious, but here are the key points: a) Java version 7 creates a special "FocusProxy" window to get keyboard input. See http://www.docjar.com/html/api/sun/awt/X11/XFocusProxyWindow.java.html b) frame.c contains a work around and a comment that begins with the fated phrase "For some reason". It seems like there was a bug in a ~1999 X server that doesn't exist in 2012 era Xorg. c) The code in frame.c takes focus away from java's "Focus Proxy" window and gives it to a java window that doesn't know what to do with keyboard input. I'm including a proposed patch (very simple - comment out the hack from 1999) as well as java code that can be used to reproduce the issue. Let me know if you have any thoughts. Thanks and best regards, Jonathan ===================================================== diff -urNp fvwm-2.6.4/fvwm/frame.c fvwm-2.6.4-javafix/fvwm/frame.c --- fvwm-2.6.4/fvwm/frame.c2011-10-15 05:34:28.000000000 -0500 +++ fvwm-2.6.4-javafix/fvwm/frame.c2012-04-11 16:54:25.090804806 -0500 &lt; at &gt;&lt; at &gt; -1938,14 +1938,25 &lt; at &gt;&lt; at &gt; void frame_free_move_resize_args( } update_absolute_geometry(fw); frame_reparent_hide_windows(Scr.NoFocusWin); -if (mra-&gt;w_with_focus != None) -{ -/* domivogt (28-Dec-1999): For some reason the XMoveResize() on - * the frame window removes the input focus from the client - * window. I have no idea why, but if we explicitly restore - * the focus here everything works fine. */ -FOCUS_SET(mra-&gt;w_with_focus); -} + +/* JPS: 11-Apr-2012: The code which is now commented out was introduced + * in 1999 with the following comment: + * + * For some reason the XMoveResize() on the frame window removes + * the input focus from the client window. I have no idea why, + * but if we explicitly restore the focus here everything works + * fine. + * + *if (mra-&gt;w_with_focus != None) + *{ + *FOCUS_SET(mra-&gt;w_with_focus); + *} + * + * Unfortunately, the code doesn't work fine with Java 7's "FocusProxy" + * and has been commented out since it doesn't seem to be necessary + * when using modern Xorg. + */ + if (mra-&gt;flags.do_update_shape) { /* unset shape */ ===================================================== /* simpleproblem.java * * Install java 7 (either oracle or openjdk) * Run FVWM * compile with: javac simpleproblem.java * run with: java -cp . simpleproblem * * You will see that after resizing the window * text entry into the java app is impossible. */ import javax.swing.JFrame; import javax.swing.JLabel; import javax.swing.JTextField; import java.awt.FlowLayout; public class simpleproblem extends JFrame { private JLabel explanation; private JTextField entrybox; private FlowLayout thelayout; public simpleproblem() { explanation = new JLabel("Resize the window then enter text:"); entrybox = new JTextField(15); thelayout = new FlowLayout(); setLayout(thelayout); add(explanation); add(entrybox); } public static void main( String args[] ) { simpleproblem entertext = new simpleproblem(); entertext.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE ); entertext.setSize( 400,200 ); entertext.setVisible( true ); } } </pre> Schaaf, Jonathan P (GE Healthcare 2012-04-11T22:23:23 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5214 <pre>Current check is broken for 2-byte characters due to str[0] getting sign-extended. Also support 4-byte characters. --- libs/Flocale.c | 11 +++++------ 1 files changed, 5 insertions(+), 6 deletions(-) diff --git a/libs/Flocale.c b/libs/Flocale.c index 058dc49..9ec9a3f 100644 --- a/libs/Flocale.c +++ b/libs/Flocale.c &lt; at &gt;&lt; at &gt; -205,14 +205,13 &lt; at &gt;&lt; at &gt; int FlocaleStringNumberOfBytes(FlocaleFont *flf, const char *str) { bytes = 1; } -else if((str[0] &amp; ~0xdf) == 0) -{ - bytes = 2; -} else { - /* this handles only 16-bit Unicode */ - bytes = 3; +switch (str[0] &amp; 0xf0) { +case 0xc0: bytes = 2; break; +case 0xe0: bytes = 3; break; +default: bytes = 4; +} } } else if(flf-&gt;flags.is_mb) </pre> Anton Khirnov 2012-04-04T15:18:00 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5212 <pre>CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by:tadam12/03/26 05:17:54 Modified files: . : Tag: branch-2_6 NEWS modules : Tag: branch-2_6 ChangeLog modules/FvwmButtons: Tag: branch-2_6 FvwmButtons.c Log message: Handle deleted windows properly in FvwmButtons. </pre> cvs< at >math.uh.edu 2012-03-26T10:17:54 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5207 <pre>Configuration Information [Automatically generated, do not change]: uname: Linux vega.poges 2.6.31-21-generic-pae #59-Ubuntu SMP Wed Mar 24 08:47:55 UTC 2010 i686 GNU/Linux compiler flags: gcc -Wall -Wno-implicit-int -g -O2 FVWM Version: 2.6.4 FVWM_MODULEDIR: /usr/local/libexec/fvwm/2.6.4 FVWM_DATADIR: /usr/local/share/fvwm FVWM_USERDIR: /home/rparlett/.fvwm Description: FvwmButtons is causing problems with swallowed programs because it is misinterpreting DestroyNotify messages, wrongly concluding that the swallowed window has been destroyed (when in fact only a child of the swallowed window has been destroyed). This causes particular problems with stalonetray, since the tray icons are children of the swallowed window, and are destroyed as a matter of course in normal operation when a tray application exits. The problem is the following piece of code in FvwmButtons.c :- 1455 case DestroyNotify: 1456 ub = UberButton;button = -1; 1457 while (NextButton(&amp;ub, &amp;b, &amp;button, 0)) 1458 { 1459 Window swin = SwallowedWindow(b); 1460 1461 if ((buttonSwallowCount(b) == 3) &amp;&amp; Event.xany.window == swin) 1462 { 1463 #ifdef DEBUG_HANGON 1464 fprintf(stderr, 1465 "%s: Button 0x%06x lost its window 0x%x (\"%s\")", 1466 MyName, (ushort)b, (ushort)swin, b-&gt;hangon); 1467 #endif The expression "Event.xany.window" in line 1461 does in fact refer to the *parent* of the window that has been destroyed, rather than the destroyed window itself. This can be seen by comparing the definitions of XAnyEvent and XDestroyWindowEvent :- typedef struct { int type; unsigned long serial; /* # of last request processed by server */ Bool send_event; /* true if this came from a SendEvent request */ Display *display; /* Display the event was read from */ Window window; } XAnyEvent; typedef struct { int type; /* DestroyNotify */ unsigned long serial; /* # of last request processed by server */ Bool send_event; /* true if this came from a SendEvent request */ Display *display; /* Display the event was read from */ Window event; Window window; } XDestroyWindowEvent; Thus xany.window == xdestroywindow.event, which refers to the parent of the destroyed window, if SubstructureNotify is selected, which it is for a swallowed window (see the definition of SW_EVENTS). What this means in the case of stalonetray is that when one of its icons is removed from the tray, FvwmButtons receives a DestroyNotify message, with Event.xany.window == SwallowedWindow(b), ie the parent of the removed tray icon. So fvwm believes that stalonetray's window has been destroyed, and reconfigures its internal flags accordingly. What *that* means is that when fvwm is restarted, stalonetray's window is not reparented into the root window; rather it is destroyed by the X server when FvwmButtons exits. stalonetray does not expect this, and is left stuck waiting for events in its main loop (or on an XIfEvent call). When fvwm restarts, it spawns a new stalonetray (since the old stalonetray window was destroyed), so it still seems to work, albeit leaving the defunct stalonetray in existence. To reproduce this, recompile fvwm with the following definition set in FvwmButtons.c :- #define DEBUG_HANGON 1 Then start fvwm with stalonetray included in FvwmButtons, as follows :- *FvwmButtons: (1x1, Swallow (NoClose,UseOld) "stalonetray" \ "Exec exec stalonetray --no-shrink --log-level trace") When fvwm starts, open some applications which use the tray (eg kmail, kalarm, etc). Then close one of those applications. As the tray icon is deleted you will see the above "Button xxxxx lost its window" debug message go by on the fvwm output. Then restart fvwm. Running "pgrep stalonetray" will reveal two processes, where there should be only one. Fix: There are two possible fixes. I am not sure which is best. The first and most obvious is to change the "Event.xany.window" at line 1461 above to "Event.xdestroywindow.window". Note that there are also two other places that the "xany.window" field may possibly be being used incorrectly, namely in the DestroyedWindow() function at line 221, and also in the MapNotify/UnmapNotify handler at lines 1438-1453. The other possible fix is to change the definition of SW_EVENTS (line 95) to use StructureNotifyMask instead of SubstructureNotifyMask. If this is done, then the event and window fields of XDestroyWindowEvent, and the window field of XAnyEvent all refer to the destroyed window. (The same applies to the other StructureNotify event types). This would however mean FvwmButtons won't get any of the StructureNotify events at all for children of swallowed windows. I'm not sure if that matters, but I can't see why fvwm should want to know about these windows. I am using this fix at the moment and haven't noticed any side-effects so far. </pre> Robert Parlett 2012-03-21T22:06:34 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5198 <pre>CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by:tadam12/03/17 18:52:53 Modified files: . : Tag: branch-2_6 ChangeLog fvwm : Tag: branch-2_6 events.c Log message: Fix XSizeHints problem with FVWM not correctly allowing resizing of windows when the hints are toggled with respect to FVWM processing XA_WM_NORMAL_HINTS. Noticed by R. Parlett. </pre> cvs< at >math.uh.edu 2012-03-17T23:52:53 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5196 <pre>Configuration Information [Automatically generated, do not change]: uname: Linux vega.poges 2.6.31-21-generic-pae #59-Ubuntu SMP Wed Mar 24 08:47:55 UTC 2010 i686 GNU/Linux compiler flags: gcc -Wall -Wno-implicit-int -g -O2 FVWM Version: 2.6.4 FVWM_MODULEDIR: /usr/local/libexec/fvwm/2.6.4 FVWM_DATADIR: /usr/local/share/fvwm FVWM_USERDIR: /home/rparlett/.fvwm Description: This is a very minor bug. The problem can best be seen by running the attached program. Compile with gcc -lX11 fvwm-hints-problem.c The window of this program accepts three keyboard inputs, namely 'q' to quit 'y' to allow resizability (by setting XSizeHints), and 'n' to disallow resizability (also by setting XSizeHints) To observe the bug, proceed as follows. 1) Start the program. The window is initially resizable. 2) Press 'n' to disable resizability. Note at this point that if you have a fvwm "Resize" menu item on your window menu, it is not greyed out, which it should be. 3) Try to resize the window - it is not possible, which is correct. Note that now your "Resize" menu item IS greyed out. 4) Press 'y' to re-enable resizability. 5) Try to resize the window - it remains impossible, which is wrong behaviour. 6) Further toggling will not restore resizability. Fix: I think the problem occurs because fvwm is not updating the size hints at the correct point. In HandlePropertyNotify() (events.c), when XA_WM_NORMAL_HINTS is noted to have changed, rather than getting the new size hints, a flag is set (SET_HAS_NEW_WM_NORMAL_HINTS), and the old stale values are left in place. Unfortunately, these stale values are then used in the function which checks for resizability (__is_resize_allowed() in decorations.c). Hence, the window may wrongly be deemeded to be not resizable. A possible fix may be to update the values if necessary in __is_resize_allowed, or to get them in events.c immediately upon notification the hints property has changed. </pre> Robert Parlett 2012-03-17T23:29:38 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5195 <pre>CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by:tadam12/03/16 03:36:17 Modified files: . : Tag: branch-2_6 ChangeLog NEWS fvwm : Tag: branch-2_6 placement.c Log message: Honour EWMH working area for "PositionPlacement UnderMouse" by default When the EWMH working area is in use, and a window is asked to place itself under the cursor, force it on-screen by taking in to account the working area if it's in use. </pre> cvs< at >math.uh.edu 2012-03-16T08:36:17 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5191 <pre>Hi Thomas, I've played around with the asciidoc manpages to include them into fvwm html pages (interesting for fvwm-web). Atached is a working example which uses two asciidoc manpages (FvwmForm and FvwmTheme) inside the actual Fvwm page. It is based on the asciidoc webpage example. On Debian you'll find it under /usr/share/doc/asciidoc/examples/website/ Used componnents: - layout_fvwm.conf to build the manpage inside a fvwm page - build-website.sh create the html pages - manpage.css - stylesheet for the manpage formating. It is very poor at the moment, and need some changes to fit the fvwm look. But that's no prob, cause if you create a standalone asciidoc html page with "asciidoc -f manpage &lt;manpage.txt&gt;" the complete formating will be found at the beginning of the page. - style.css the original fvwm style sheet I've put two links for testing in FvwmForm: -&gt; external link: FvwmTheme - in "*FvwmForm: Colorset n" -&gt; internal link: DEFAULTS - in "*FvwmForm: Back color" These links doesn't occur inside a manpage. See for yourself - create with "create-manpage.sh FvwmForm.txt" a manpage and view it. I hope this will help to switch completely to asciidoc. It's amazing how easy it is to build different document types with one asciidoc document. Cheers, Thomas </pre> Thomas Funk 2012-03-13T12:25:48 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5190 <pre>Hi, I have been looking at the fvwm RPM for fedora and i noticed that the following patches are in there: fvwm-0005-Explicitly-link-against-fontconfig.patch fvwm-2.5.21-menu-generate.patch fvwm-2.5.30-mimeopen.patch fvwm-2.5.30-more-mouse-buttons.patch fvwm-2.5.30-xdg-open.patch There is also the following: fvwm-xdg-menu.py From looking at the archives, it is not clear to me if the last one should be included/excluded? Are any of the above no longer necessary for fvwm-2.6.4? Separately, I also was wondering: do any of these patches conflict with the following more commonly used patches (for Gentoo/ArchLinux)? 01-TranslucentMenus.patch 11-MultiBorder.patch 02-ColourBorders.patch 12-FvwmButtonsTips.patch 03-ResizeOutlineThin.patch 13-FvwmIconMan.patch 04-Conditionals.patch 14-Hover.patch 05-FlatSeparators.patch 15-FirstItemUnderPointer.patch 06-BorderUnderTitle.patch 16-ThinGeometryProxy.patch 07-InactiveFont.patch 08-FluxRoundedCorners.patch 09-TopBorder.patch 10-ButtonWidth.patch Finally, does anyone here know what is going on wrt Fedora's fvwm? Bugzilla requests there do not seem to have been even checked out for months, sometimes years, and it is not clear whether the WM has any support or not. Many thanks and best wishes, Ranjan </pre> Ranjan Maitra 2012-03-13T04:18:14 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5187 <pre>Hi FVWM developers, first of all thank you for maintaining my window manager :) I recently switched all my windows to a style where the title is on the left using the TitleAtLeft style. The FvwmRearrange module, when used with the -tile option, is not able to cope with this and windows are tiled such that the right most ones fall out of the screen. The reason is that FvwmRearrange assumes the title to be always either on top or on the bottom of windows. Looking in FvwmRearrange.c (FVWM version 2.6.4) within the tile_window function 305 int nw = wdiv - w-&gt;bw * 2; 306 int nh = hdiv - w-&gt;bw * 2 - w-&gt;th; 339 int nw = wdiv - w-&gt;bw * 2; 340 int nh = hdiv - w-&gt;bw * 2 - w-&gt;th; you see that the new width of the window is calculated removing twice the border width, whereas the height gets the title height removed too. In order to solve my particular problem I simply patched those lines to be 305 int nw = wdiv - w-&gt;bw * 2 - w-&gt;th; 306 int nh = hdiv - w-&gt;bw * 2; 339 int nw = wdiv - w-&gt;bw * 2 - w-&gt;th; 340 int nh = hdiv - w-&gt;bw * 2; This way FvwmRearrange almost works (windows are still overflowing on the right of the screen by 1 pixel, why?), but of course a general solution taking into account title orientation would benefit all users. Thank you! Tiziano </pre> Tiziano Zito 2012-02-27T17:34:14 http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/5186 <pre>CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by:tadam12/02/19 19:03:54 Modified files: . : Tag: branch-2_6 ChangeLog NEWS fvwm : Tag: branch-2_6 fvwm.c Log message: Don't block signals. Unblock signals registered so as not to queue them up with repeated events. </pre> cvs< at >math.uh.edu 2012-02-20T01:03:54 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.window-managers.fvwm.devel