awesome

Welcome to awesome bug tracking system.
Tasklist

FS#664 - awful.rules

Attached to Project: awesome
Opened by saucerful (saucerful) - Friday, 23 October 2009, 03:51 GMT
Last edited by Julien Danjou (jd) - Friday, 08 January 2010, 18:13 GMT
Task Type Bug Report
Category Lua libraries → awful
Status Closed
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version git/master
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 15
Private No

Details

awful.rules is nice. but it seems that rules don't get applied immediately. for example, i have a floating rule and i can see the window launch normally for a instant and then move to floating. its ugly and uses unnecessary cpu to resize the other windows, etc.
This task depends upon

Closed by  Julien Danjou (jd)
Friday, 08 January 2010, 18:13 GMT
Reason for closing:  Fixed
Additional comments about closing:  commit a757ddabc4484a9369c30fb28327145df4f37673
Author: koniu <gkusnierz@gmail.com>
Date: Fri Jan 8 15:26:21 2010 +0000

awful.rules: tag clients without flicker ( FS#664 )

We unregister the default awful.tag.withcurrent 'manage' signal handler
and have awful.rules.apply handle initial client tagging.

Signed-off-by: koniu <gkusnierz@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
Comment by Damjan (gdamjan) - Saturday, 24 October 2009, 05:25 GMT
This is probably related to the issue I've noticed, that is I have the following rule:

{ rule = { class = "XTerm" },
properties = { tag = tags[1][1] } },

i.e. I put all xterms on tag 1. the thing is, when I'm on any other tag and press mod+enter, I see the xterm flashing very briefly on the current tag, before beeing moved to tag 1.

I guess the problem is the "manage" signal callback are called in a undeterministic order, and probably the "manage" callback in awful.tag (where c.screen is set) is called before the "manage" callback in awful.rules (where the tag is set).

This needs to be more flexible (maybe just remove it from awful and put it in rc.lua)
Comment by Zsolt Udvari (uzsolt) - Tuesday, 27 October 2009, 17:38 GMT
I've similar problem. But I don't have idea :)
Comment by Damjan (gdamjan) - Tuesday, 27 October 2009, 17:47 GMT
can you try the second patch I attached to task 659.

seems to have helped here
Comment by Renato Botelho (rbgarga) - Tuesday, 27 October 2009, 17:59 GMT
Didn't have effect here, problem persists
Comment by Renato Botelho (rbgarga) - Tuesday, 27 October 2009, 19:56 GMT
Ops, it has effect, it fixed the problem with firefox popup windows focus \o/, but the first problem i reported no. Thanks
Comment by saucerful (saucerful) - Tuesday, 27 October 2009, 20:04 GMT
Problem persists here, too.
Comment by chisiyuan (chisiyuan) - Tuesday, 27 October 2009, 22:53 GMT
I had the same problem with 3.4 too. I tried to remove awful.rules and things went a little better. Now I stay with the perfect 3.3.
Comment by Renato Cantão (rfcantao) - Friday, 27 November 2009, 12:09 GMT
Same (annoying!) problem here. 3.4.1 on Gentoo.
Comment by Renato Cantão (rfcantao) - Friday, 27 November 2009, 12:10 GMT
By the way, how do I remove awful.rules *and* keep the floating apps floating?
Comment by Hiltjo (bob127) - Sunday, 06 December 2009, 15:47 GMT
The attached patch fixes it for me.
Comment by Renato Botelho (rbgarga) - Monday, 07 December 2009, 10:33 GMT
Tested here on 3.4.2, patch fixes the problem! \o/
thank you
Comment by Julien Danjou (jd) - Monday, 07 December 2009, 15:27 GMT
The patch touch awful.tag, and should not.
Comment by anrxc (anrxc) - Monday, 07 December 2009, 20:33 GMT
> The attached patch fixes it for me.

Cleaner than the last patch I used, thanks EvilBob.
Comment by Uli Schlachter (psychon) - Friday, 11 December 2009, 19:46 GMT
Uhm, this should be fixed by lazy banning, not? If not, any guess why lazy banning gets defeated?
Comment by Rafael Fonseca (rfonseca) - Thursday, 17 December 2009, 01:02 GMT
I have a similar problem but not just with floaters. If I have enabled setslave on manage signal, when I create a new client it goes to the master column first and I can see it swapping until it reaches its position. awesome v3.4-85-gc4c15db.
Comment by Renato Cantão (rfcantao) - Friday, 18 December 2009, 10:58 GMT
Any improvements about this? Was the patch accepted?
Comment by Uli Schlachter (psychon) - Tuesday, 22 December 2009, 14:06 GMT
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")
Comment by Julien Danjou (jd) - Tuesday, 22 December 2009, 14:16 GMT
> 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.

This is partially implemented in 'next' branch. EWMH update is done via signals.
Comment by Julien Danjou (jd) - Monday, 28 December 2009, 10:06 GMT
FTR, I've sent a howto fix this bug on awesome-devel.
Comment by Gregor Best (farhaven) - Monday, 28 December 2009, 19:29 GMT
I splitted off the second part of this bug report into an own report as it was a simple feature request for awful.rules (not even a valid one, see the closing reason for #714).
Comment by saucerful (saucerful) - Tuesday, 05 January 2010, 21:17 GMT
I take it the fix was not merged in 3.4.3? How can I apply the patch to that build?
Comment by anrxc (anrxc) - Tuesday, 05 January 2010, 23:22 GMT
> I take it the fix was not merged in 3.4.3? How can I apply the patch to that build?

The patch by Hiltjo P. only does small changes to some Lua modules. You can patch awesome prior to building it, but you can also make the changes your self once it is installed. But to answer the question in full;

If you have a local awesome repo from which you build awesome then all you need is to "git apply" or "git am" the file. If you build awesome from tarballs something like this example would do it: patch -p0 < /path/to/rules-fix.patch
Comment by saucerful (saucerful) - Tuesday, 05 January 2010, 23:45 GMT
Great, thanks.
Comment by Julien Danjou (jd) - Wednesday, 06 January 2010, 08:38 GMT
No one send a right patch so this is still not fixed in 3.4.3, yeah.

Loading...