KristianLy, input prevention? yes... an X call, then returning to core, then doing something else in some other proc? KristianLy, we just map a window... or we create -> map -> unmap -> destroy a window marex_v2, i think i have an idea why it sometimes work and sometimes it doesn't... roico, why? my point is, do you head back to core in the middle of that process, after makeing an X call ? * Mook hat die Verbindung getrennt (Connection timed out) because that could explain why it's random marex_v2, before maniac's changes, we did xwc.stack_mode = Above; xwc.sibling = TOP_TAB(group)->id; and now we don't... * Mook (i=MookDawg@pool-141-150-247-136.pskn.east.verizon.net) hat #beryl-dev betreten KristianLy, i don't understand what you mean, sorry... :\ sigh, ok, listen what do you mean return back to core? like do something in an event handler then something else, related, in paintScreen or preparePaintScreen * Pricey ist jetzt bekannt als PriceChild * Loffe hat die Verbindung getrennt (Read error: 104 (Connection reset by peer)) arg 1s too late * Loffe (n=loffe@213.134.106.56) hat #beryl-dev betreten hmmm, we create the window when the group is tabbed (on a bind key event), and map / unmap it with a timer (and sometimes preparePaintScreen)... KristianLy, ^^ Loffe : done the point is that beryl is single threaded, but whenever you do a call to X, you have to keep in mind that your machine isn't. If Beryl returns to core, schedueling will decide wether or not X has had time to process the event you triggered and pass it on to Beryl, if it have, you will see diffrent results the next time your code executes so you can't blindly say "ok, I did this and it's ok" just because a call to X*() returned success, it needs to actually be processed by core first too, and that doesn't happen until after you return to core... so what I'm saying is: Check if the X-calls you do trigger events, many of them do, then check how core handles such events errrr.... i'm not sure if that's the problem, but maybe... i don't really know too much about multi-processing... as i said, we create the window when the group is tabbed (on a bind key event), and map / unmap it with a timer (and sometimes preparePaintScreen)... does it dound ok KristianLy? :P yes, but if it randomly works/bugs, chances are you have some multi-processing related problems KristianLy, maybe we just don't put it in the correct place in the stack? :P not really your job to restack windows though KristianLy, it is our job to tell the window to be right after the tabbed window... marex_v2, are you still here, btw? yeah.. reading your discussion... well we could try the restack thing quite easily... yes, indeed it is, but you shouldn't really directly modify the w-> stack as that would confuse other code KristianLy, not w->, just tell X to restack it (with sibling, we did that before but maniac removed it... :P)... what's sibling, btw? ah, yes, that's correct since when you tell X to do it, you're sure any other code that rely on the stacking order also gets notified :) sibling is another child of the parent ? roico, my dictionary says it means something like brother/sister marex_v2: indeed * spiorf hat die Verbindung getrennt (Remote closed the connection) hehe, ok... :P * Mook` hat die Verbindung getrennt (Success) btw, unloading group still crashes beryl here... still no idea why... roico: I thought you were talking about manually editing the window stack, hehe :) KristianLy, nah.... :) i did it in 3d though, panels stacking is annoying... :P window stacking is evil... especially insert/unhookWindow well in 3d the screen is grabbed too and you revert it too if I remember correctly window stacking is beautiful :P made it so easy for opacify beautiy becomes hate if you ever had to manipulate it... KristianLy, yeah, i reverted it.... :P since beryl-stack != X-stack KristianLy, nice algo i made there hehe... :P