Actually, wmaker's code looks like this....
/* prevent window withdrawal when getting UnmapNotify */
XSelectInput(dpy, wwin->client_win,
wwin->event_mask & ~StructureNotifyMask);
XUnmapWindow(dpy, wwin->client_win);
XSelectInput(dpy, wwin->client_win, wwin->event_mask);
XUnmapWindow(dpy, wwin->frame->core->window);
..............................................
, whereas blackbox's code is this....
..............................................
XUnmapWindow(display, frame.window);
XSelectInput(display, client.window, NoEventMask);
XUnmapWindow(display, client.window);
XSelectInput(display, client.window,
PropertyChangeMask | StructureNotifyMask |
FocusChangeMask);
Slightly different. I've not had a chance to look at what exactly the
difference in results is.... =:)
On Wed, 2001-12-12 at 14:41, Sean 'Shaleh' Perry wrote:
> >
> > Shaleh, please take a gander at this and see if you have any objections
> > to putting it in 61.2. The affect that this has (at least with this
> > opera situation) is that opera's state hasn't changed to Withdrawn and
> > he's now able to receive the "open a new link" message. Now, granted,
> > opera doesn't magically switch the desktop to where it is, but it does
> > get the message to open a new link and doesn't open a brand new window
> > on the current desktop....
> >
> > So, again, the fix that I've come up with is as follows.... Window.cc
> > should have this....
> >
>
> Window maker's code look just like yours vanR. I would like to know if Brad
> had a reason for the state call.
--
----%<----------%<----
Jason Kasper (vanRijn)
bash$ :(){ :|:&};:
Numbers 6:24-26