All pastes #290023 Raw Edit

Untitled

public text v1 · immutable
#290023 ·published 2006-12-23 17:00 UTC
rendered paste body
<roico> KristianLy, input prevention? yes...
<KristianLy> an X call, then returning to core, then doing something else in some other proc?
<roico> KristianLy, we just map a window...
<marex_v2> or we create -> map -> unmap -> destroy a window
<roico> marex_v2, i think i have an idea why it sometimes work and sometimes it doesn't...
<marex_v2> roico, why?
<KristianLy> 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)
<KristianLy> because that could explain why it's random
<roico> 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
<roico> KristianLy, i don't understand what you mean, sorry... :\
<KristianLy> sigh, ok, listen
<roico> what do you mean return back to core?
<KristianLy> 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))
<iXce> arg
<iXce> 1s too late
* Loffe (n=loffe@213.134.106.56) hat #beryl-dev betreten
<roico> 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)...
<roico> KristianLy, ^^
<iXce> Loffe : done
<KristianLy> 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
<KristianLy> 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...
<KristianLy> 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
<roico> 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
<KristianLy> yes, but if it randomly works/bugs, chances are you have some multi-processing related problems
<roico> KristianLy, maybe we just don't put it in the correct place in the stack? :P
<KristianLy> not really your job to restack windows though
<roico> KristianLy, it is our job to tell the window to be right after the tabbed window...
<roico> marex_v2, are you still here, btw?
<marex_v2> yeah.. reading your discussion... well we could try the restack thing quite easily...
<KristianLy> yes, indeed it is, but you shouldn't really directly modify the w-> stack as that would confuse other code
<roico> KristianLy, not w->, just tell X to restack it (with sibling, we did that before but maniac removed it... :P)...
<roico> what's sibling, btw?
<KristianLy> ah, yes, that's correct
<KristianLy> since when you tell X to do it, you're sure any other code that rely on the stacking order also gets notified :)
<KristianLy> sibling is another child of the parent ?
<marex_v2> roico, my dictionary says it means something like brother/sister
<KristianLy> marex_v2: indeed
* spiorf hat die Verbindung getrennt (Remote closed the connection)
<roico> hehe, ok... :P
* Mook` hat die Verbindung getrennt (Success)
<roico> btw, unloading group still crashes beryl here... still no idea why...
<KristianLy> roico: I thought you were talking about manually editing the window stack, hehe :)
<roico> KristianLy, nah.... :) i did it in 3d though, panels stacking is annoying... :P
<marex_v2> window stacking is evil... especially insert/unhookWindow
<KristianLy> well in 3d the screen is grabbed too and you revert it too if I remember correctly
<KristianLy> window stacking is beautiful :P
<KristianLy> made it so easy for opacify
<marex_v2> beautiy becomes hate if you ever had to manipulate it...
<roico> KristianLy, yeah, i reverted it.... :P
<marex_v2> since beryl-stack != X-stack
<roico> KristianLy, nice algo i made there hehe... :P