FVWM Bug Tracking notification
new message incoming/853
Message summary for PR#853
From: [EMAIL PROTECTED]
Subject: wrong FvwmWindow.flags.is_map_pending stops iconifying
Date: Thu, 07 Feb 2002 07:38:35 -0600
0 replies 0 followups
====> ORIGINAL MESSAGE FOLLOWS <====
>From [EMAIL PROTECTED] Thu Feb 07 07:38:36 2002
Received: from karazm.math.uh.edu ([129.7.128.1])
by malifon.math.uh.edu with esmtp (Exim 3.20 #1)
id 16Yol1-0005zL-00
for [EMAIL PROTECTED]; Thu, 07 Feb 2002 07:38:35 -0600
Received: from malifon.math.uh.edu (IDENT:[EMAIL PROTECTED] [129.7.128.13])
by karazm.math.uh.edu (8.9.3/8.9.3) with ESMTP id HAA23081
for <[EMAIL PROTECTED]>; Thu, 7 Feb 2002 07:38:35 -0600 (CST)
From: [EMAIL PROTECTED]
Received: from localhost ([127.0.0.1] ident=65534)
by malifon.math.uh.edu with esmtp (Exim 3.20 #1)
id 16Yol1-0005zH-00
for [EMAIL PROTECTED]; Thu, 07 Feb 2002 07:38:35 -0600
To: [EMAIL PROTECTED]
Subject: wrong FvwmWindow.flags.is_map_pending stops iconifying
Message-Id: <[EMAIL PROTECTED]>
Date: Thu, 07 Feb 2002 07:38:35 -0600
Full_Name: Markus Schwarzenberg
Version: 2.4.5.
CVS_Date:
OS: sunos 5.7
X_Server:
Submission from: (NULL) (153.96.96.2)
after fvwm2 -restart the FvwmWindow.flags.is_map_pending bit
sometimes seems not to be set properly.
This causes the function Iconify(in icons.c) to return in:
if (IS_MAP_PENDING(tmp_win))
{
/* final state: iconified */
SET_ICONIFY_AFTER_MAP(tmp_win, 1);
return;
}
This makes fvwm2 sometimes refractorily ignoring any Iconify and DeIconify
actions (clicks) for windows which "survived" the restart in an iconified
state.
The bug is hard to reproduce (I have a very lengthy .fvwm2rc which
I don't want to include here) and seems to be related to a FvwmIconBox
running in my FvwmButtons.
But here is a possible workaround (Beginning of Function Iconify(in
icons.c)):
void Iconify(FvwmWindow *tmp_win, int def_x, int def_y)
{
FvwmWindow *t;
FvwmWindow *sf;
XWindowAttributes winattrs = {0};
unsigned long eventMask;
if(!tmp_win)
return;
if (!XGetWindowAttributes(dpy, tmp_win->w, &winattrs))
{
return;
}
eventMask = winattrs.your_event_mask;
/* correct is_map_pending if necessary ... */
if((winattrs.map_state == IsViewable) && IS_MAP_PENDING(tmp_win)) {
fprintf(stderr, "Window '%s':\nXGetWindowAttributes: IsViewable, but
MAP_PENDING set ... resetting it!\n",
tmp_win ? tmp_win->name ? tmp_win->name : "NULL_name" : "NULL");
SET_MAP_PENDING(tmp_win, 0);
}
if (IS_MAP_PENDING(tmp_win))
{
/* final state: iconified */
SET_ICONIFY_AFTER_MAP(tmp_win, 1);
return;
}
#if 0
if (tmp_win == Scr.Hilite && HAS_CLICK_FOCUS(tmp_win) &&
tmp_win->next)
{
SetFocusWindow(tmp_win->next, 1);
}
#endif
mark_transient_subtree(tmp_win, MARK_ALL_LAYERS, MARK_ALL, False,
True);
...
For me this completely seems to fix the bug. After the session restart
I once see the fprintf-message for every affected window and then fvwm
works OK again (of course the fprintf statement should be converted to
some debug message...).
Markus Schwarzenberg
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
