Wrong handling of XWithdrawWindow

[sillysloft]

fluxbox (0.9.11) do not react correct to XWithdrawWindow. the correct way is descripted here:

http://tronche.com/gui/x/icccm/sec-4.html\#s-4.1.4

XFCE4 do it correct:

http://cvs.xfce.org/viewcvs.cgi/xfce4/xfwm4/src/events.c?view=markup (handleUnmapNotify function)

so fluxbox should do the following with the unmapnotifyevent:

if ((ue.event == screen().rootWindow().window()) && (ue.send_event)) {

//ungrabe all buttons //set state to withdrawstate //forget about the window

}

the reason is i try to get my project:

http://alltray.sourceforge.net/

working under fluxbox. (which waits for the window to change state to withdrawn and reparent it after)

thx a lot jochen

Reported by: jebe

[sillysloft]

Logged In: YES user_id=1101187

1) somehow we do not get neither ue.event == rootwindow nor the ue.send_event (which would come from a synthetic xsendevent in my understanding)

2) when we set the unmapped window to withdrawn then we would put such apps (handled by "alltray") into the same category as all dockapps .. we would have to add code to block such apps from entering the slit (whats called dock in windowmaker) ... simon? henrik? comments about that issue? it really looks funny, when "ding" pops up inside the slit :))

3) aside from the above things, in your code, you can use gdk_withdraw_window() instead of native xlib-calls

cheers, mathias

Original comment by: akir

[sillysloft]

• assigned_to: nobody --> akir

Original comment by: akir

[sillysloft]

Logged In: YES user_id=817814

to 1)

in the function void Fluxbox::handleUnmapNotify(XUnmapEvent &ue)

the line: if ( ue.event != ue.window && (screen != 0 || !ue.send_event)) return;

will filter out the event. because ue.event is the root window, ue.window will be the window to unmap. !ue.send_event is 1.

and searchScreen function will return the first list member because

"if (*it && (*it)->rootWindow() == window)" will always match for the root window.

to 2)

gdk function often do not work with native xlib windows. (they often check for GDK_IS_WINDOW(..) etc. and this will not match for xlib windows.

regards jochen

Original comment by: jebe

[sillysloft]

• status: open --> closed

Original comment by: akir

[sillysloft]

Logged In: YES user_id=1101187

should be fixed now in svn.

Original comment by: akir