At 1245918857 time_t, Uli Schlachter wrote: > BTW in my testing only my test app ever triggered this code and I don't really > see any reason why someone would change their WM_PROTOCOLS, so I think this is > less bad than it looks (Plus some other function in there already does the > same > *duck*).
Yup, I'm not telling what you did is bad. It's just that if you ever goes by this path, you send a request/get a reply whereas the reply is already furnished by xcb-property. So this is suboptimal. (But xcb-util's fault, not yours). > I tried the following: > > - protocols.atoms_len is obviously initialized to 0. Ack. > - In property_update_wm_protocols(): If after the _reply() call .atoms_len is > 0, > _reply_wipe() the struct again and set it to 0 again. Just wipe it before calling reply? > - In client_unmanage, only _reply_wipe() the struct if .atoms_len is != 0 I, btw, think that collecting resources shoud be done in _gc rather than in unmanage(). > This seemed ugly. As you see, the problem is how to decide when to > _reply_wipe() > this struct. If you are fine with the '.atoms_len == 0' hack, I can implement > it, but I didn't really feel comfortable with it. I'd say always wipe+p_clear before updating. -- Julien Danjou // ᐰ <jul...@danjou.info> http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // I'm no superman.
signature.asc
Description: Digital signature
