The problem:
I have my xterms in an FvwmIconMan instance and set them StickyIcon so
that anything I deiconify winds up on the current virtual desktop page.
In configuration terms:
DesktopSize 3x2
Style "XTerm" !Icon, StickyIcon
*FvwmIconMan: Resolution desk
*FvwmIconMan: Show class=XTerm
*FvwmIconMan: ManagerGeometry 8x0+0+0
*FvwmIconMan: ButtonGeometry 100x0
*FvwmIconMan: Format %i
*FvwmIconMan: Shape true
If I switch to another page while I have one or more xterm windows
iconified, FvwmIconMan stops updating the displayed icon manager in
response to xterms being created, deleted, or having their icon name
changed. The manager only updates when I actually interact with it at
the X level (move my mouse into it, cover it with something that forces
it to redraw due to an expose, etc).
(Testing this with xterms is convenient because you can easily control
and change their window and icon name with scripts.)
The bug:
FvwmIconMan normally redraws the icon manager windows after processing
each event sent to it from fvwm. As a redraw optimization during
M_NEW_PAGE processing, FvwmIconMan works out a count of how many
M_CONFIGURE_WINDOW messages it expects (for windows managed by each
manager); it then doesn't do any of fvwm event redraws until it has seen
all of the configure window messages it expects. When I have one or more
iconified StickyIcon windows, this count is higher than the number of
configure window messages that FvwmIconMan gets and debug tracing shows
that FvwmIconMan is not getting configure window messages for those
iconified StickyIcon windows.
FvwmIconMan already excludes sticky windows from the configure window
count. Based on this, I think that the underlying bug is that it should
also exclude iconified windows that have sticky icons.
Assuming that my bug diagnosis is correct, I propose the following
patch (which is hopefully formatted properly this time around). Please
feel free to revise the text and/or the code as needed and appropriate
(I've tried to match the existing style but may well have failed).
Index: ChangeLog
===================================================================
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.3126
diff -u -r1.3126 ChangeLog
--- ChangeLog 28 Jul 2010 20:55:16 -0000 1.3126
+++ ChangeLog 6 Aug 2010 18:40:50 -0000
@@ -1,3 +1,13 @@
+2010-08-06 Chris Siebenmann <[email protected]>
+ * modules/FvwmIconMan/fvwm.c (count_nonsticky_in_hashtab):
+ * NEWS:
+ Correctly handle iconified windows with sticky icons.
+
+ When counting how many windows we expect configure window messages
+ for after changing to a new page, don't count iconified windows
+ with sticky icons (ones styled with StickyIcon or any of its
+ variants).
+
2010-07-28 Thomas Adam <[email protected]>
* fvwm/builtins.c (CMD_Exec):
Close fd if it's not opened successfully.
Index: NEWS
===================================================================
RCS file: /home/cvs/fvwm/fvwm/NEWS,v
retrieving revision 1.814
diff -u -r1.814 NEWS
--- NEWS 28 Jul 2010 20:25:13 -0000 1.814
+++ NEWS 6 Aug 2010 18:40:50 -0000
@@ -14,6 +14,8 @@
- Correctly report a window's height and width if the window has
incomplete resize increment set.
- Maintain any State hints on a window when used with WindowStyle.
+ - FvwmIconMan now correctly handles windows styled with any of
+ StickyIcon, StickyAcrossPagesIcon, or StickyAcrossDesksIcon.
-------------------------------------------------------------------
Index: modules/FvwmIconMan/fvwm.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmIconMan/fvwm.c,v
retrieving revision 1.66
diff -u -r1.66 fvwm.c
--- modules/FvwmIconMan/fvwm.c 7 Aug 2007 20:17:43 -0000 1.66
+++ modules/FvwmIconMan/fvwm.c 6 Aug 2010 18:40:50 -0000
@@ -92,6 +92,8 @@
WinManager *man = the_manager;
if (!(IS_STICKY_ACROSS_DESKS(win) || IS_STICKY_ACROSS_PAGES(win)) &&
+ !(win->iconified && (IS_ICON_STICKY_ACROSS_PAGES(win) ||
+ IS_ICON_STICKY_ACROSS_DESKS(win))) &&
win->complete && win->manager == man)
{
return 1;
- cks, who had fun tracking this one down and has to thank all
of the people who've maintained the debug logging support
in FvwmIconMan over the years; it was really handy.
