At 1243147563 time_t, koniu wrote:
> My best conclusion so far is that when re-setting root.keys with
> different length tables (note that I still run root.keys({ ... }) even
> when switching A1->A2 and it works fine) something goes wrong and the
> keybinding/function is done twice.The thing is that when you call root.keys(), awesome lies down the table passed as argument, and fill an array of key object (globalconf.keys). So when awesome receive an key event, it look through from 0 to globalconf.keys.len and check each element of the array. When a key matches, it run its callback function. So if one of this function modifies the array, while the loop was checking for example key object 5 on 200, it will still go through key number 6 which can be ... the same as 5 if you pushed an elememnt in from of your table in the previously called callback function from object number 5. In fact it can be anything else, and you can do very bad things modifying key bindings while a key binding is pressed, like infinite loop. (This can be a false problem, since awesome is able to finish such a loop in matter of miliseconds of course *g*) Seriously, this has been discussed previously, and no solution has been found. I just though about something that IIRC had not been proposed. What we can try is to go through the loop and look for matching key from globalconf.key. Then, rather then calling callback function each time we match (since that can break things (TM)) we store key object temporarly. _Then_, we call all matched key's callback function. If one of them modify the root.keys(), we just do not care, we already finished looping. What do you people think? Cheers, -- 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
