THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added:
FS#664 - awful.rules User who did this - Uli Schlachter (psychon) ---------- Anybody took a look at this bug from the C side of things? client_manage() (Called when we receive a MapRequest) creates a new client object in banned state (no MapWindow generated) and generates the necessary lua calls. The only way for a client to actually get mapped is through client_unban(). The "proper" way for a client to go throught client_unban() is through the lazy banning code in banning.c. If this route is taken, there is no way for flicker to occur because it is only called at the end of awesome's main loop. The other call to client_unban() (which must thus be the one which causes this) is in client_focus_update(). The only call to this which may be responsible is in client_focus() which is called all over the place (I'd guess this call here is caused by 'client.focus = c') Wouldn't it be a better fix to add some kind of "lazy focusing" to the C side of things? Let the lua code do whatever it wants and the C side makes sure to avoid flicker. One would just have to change client_focus_update() to only do the lua-side of things and the X stuff (ewmh_update_net_active_window() and client_unban()) is delayed until the end of the main loop. Oh and one would somehow have to "fix" client_set_focus() to also delay its work until later (Or what happens if one tries to focus an unmapped window X11-wise?). Thoughts? Takers? (I guess the answer to the second question will be "psychon") ---------- More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=details&task_id=664#comment1665 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to [email protected].
