On Sun, Apr 19, 2009 at 3:44 PM, Jason Weber <baboon.im...@gmail.com> wrote: > On Sun, Apr 19, 2009 at 7:40 AM, Thomas Adam <thomas.ada...@gmail.com> wrote: >> 2009/4/17 Jason Weber <bab...@imonk.com>: >>> Attached in function Restack(). Work in progress, etc. >>> >>> -- Jason Weber >>> >>> On Fri, Apr 17, 2009 at 10:30 AM, Thomas Adam <thomas.ada...@gmail.com> >>> wrote: >>>> 2009/4/17 Jason Weber <baboon.im...@gmail.com>: >>>>> I've been trying to switch series of XRaiseWindow/XLowerWindow calls >>>>> to a singular XRestackWindows, >>>>> but it doesn't seem to have any affect. I send it an array of Window >>>>> values. >>>>> It just responds with a bunch of: >>>>> >>>>> non-fatal X error as follows, display 0xe8e500 op 12:0 >>>>> "X_ConfigureWindow" serial 183 error 8 >> >> So I added the following debug: >> >> @@ -703,6 +734,8 @@ >> error_event->request_code,error_event->minor_code, >> function,(unsigned int)error_event->serial, >> error_event->error_code); >> + if( error_event->error_code == BadMatch && >> error_event->request_code == X_ConfigureWindow ) >> + fprintf(stderr, "BadMatch Raised! This shouldn't >> happen!\n"); >> >> >> ... to FvwmProxy.c:myXErrorHandler(). From the XRestackWindows man >> page (and my dusted-off XLib programmers' reference manual): >> >> You seem to be hitting the BadMatch error which suggests that the >> window specified aren't a sibling of one another. Coupled with the >> fact you're only receiving ConfigureNotify requests with this >> condition suggests that: >> >> If the override-redirect attribute of a window is False and some >> other client has selected SubstructureRedirectMask on the parent, the X >> server generates ConfigureRequest events for each window whose >> override-redirect flag is not set, and no further processing is >> performed. Otherwise, the windows will be restacked in top-to-bottom >> order. >> >> >> I am not sure who's at fault here -- I suspect FVWM is to blame. >> >> -- Thomas Adam >> >> > > I got a similar impression from the man pages, but those also implied that > the singular raise/lower requests would be similarly intercepted. However, > they seem to go through fine. > > As I understand, the primary windows are all children of the root, > so they are all siblings, but maybe restack only works on subwindows. > In FvwmPager, it seems to be used only for the little mini-windows it owns. > > Any ideas for an alternative method or a way we can evaluate this further? > > Is there a way to probe these masks on windows? I don't see it on xprop. > > -- Jason Weber >
I've given up on the XRestackWindows and wrote my own restack that compares the current and desired stacks and sends out a bunch of raise/lower calls. It's similar to what I had before, but now it cares about retaining the order within window groups. I'll run it locally for a while before checking in. I've implemented a better proxy shifting algorithm that should tend to nicely vertically center proxies of coincident windows (like in isolated "tab" mode) instead of running them off them bottom of the screen. I also added a ShowOnly option to reduce the number of proxies shown, All (default), Active, Cover, and Group. Active just shows the active proxy (the active window is not always the focused window). Cover mode adds proxies that overlap the active window. Just using Active mode can result in untouchable proxies. Group mode supersets Cover mode, showing proxies of windows in the same window group as the active window. Where are we in the Fvwm release cycle? Is this a good time for introducing new features? -- Jason Weber
