On Fri 02 Feb 2007 at 10:09:28 -0500, Stefan Monnier wrote: > >> Well, I still have my OnTopPriority stuff, but I don't think anyone has the > >> time/energy to work on it soon, > [...] > > It would also be nice for switching workspaces, when mapping and unmapping > > windows could be done in stacking order to minimize Expose events. > > You mean "it *is* nice".
I do seem to recall that somebody said that they had made it, but actually I can't find any clear proof in the code. And in practice I occasionally see (when the system is a bit slow) that windows that should be hidden behind others still have their border drawn (this is when the obscuring window also only has its borders drawn so you can "see through" it - this can only mean that the obscured window was mapped first). When the system is fast enough the effect is more difficult to spot. There is this mysterious comment in GotoWorkSpace(), /* Iconise in reverse order */ but since there is no iconisation I've taken it with a large amount of salt (like so many other things in the code). The loop after that only operates in any meaningful order if the list is kept in depth-order, and I don't think it is. Grepping shows there is no CirculateNotify handler nor a ConfigureNotify handler to keep track of the stacking order (but strangely enough there is a mention of a "HandleConfigureNotify" in a comment). The only thing that appears to change the order is move_to_head() which is used in SetFocus(). (That may be an optimisation for all the loops that go search through the list for the current window, which I have removed anyway) > Stefan "who's been enjoying it for a while now" Or do you mean that you have recently implemented it? *If* the TwmWindow list is in depth-order, then the drawing of the workspace manager can be simplified (right now WMapRestack() calls XQueryTree() to find out the stacking). -Olaf. -- ___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it. \X/ rhialto/at/xs4all.nl -- Cetero censeo "authored" delendum esse.
