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