Welcome to awesome bug tracking system.

FS#641 - Flicker when starting application which is moved to a different tag

Attached to Project: awesome
Opened by Uli Schlachter (psychon) - Friday, 25 September 2009, 06:55 GMT
Last edited by Uli Schlachter (psychon) - Wednesday, 09 December 2009, 17:59 GMT
Task Type Bug Report
Category Core
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 2
Private No



when icedove starts, my rc.lua moves it to tag 4 without focusing that tag. Since recently the icedove window shows up for a split second ("flickers") when this happens.

I think this is due to the recent changes to the banning code.

Can we please get the old lazy-banning behavior back and reopen  FS#629 ? I volunteer to provide the fix for it that I described in  FS#634  if it will be accepted.

This task depends upon

Closed by  Uli Schlachter (psychon)
Wednesday, 09 December 2009, 17:59 GMT
Reason for closing:  Fixed
Comment by Julien Danjou (jd) - Friday, 25 September 2009, 07:16 GMT
It flickers because it's first tagged with selected tags I guess. This is probably the problem to solved here.
Comment by Uli Schlachter (psychon) - Friday, 25 September 2009, 07:31 GMT
Uhm, ok, feel free to fix that. I'm not going to remove the awful.tag.withcurrent signal because then I'd have to figure out when to call that function "by hand". The lazy banning solved that problem quite well for me. :/

Comment by Jacob (jacob) - Saturday, 26 September 2009, 06:18 GMT
I've had the same problem with sticky clients. It's not easy to set the client sticky before the initial client signal is received by tag.lua, which causes a layout arrange. I moved the signal to the end of rules.lua and its been working perfectly. That was also to stop the client geometry changing but thats been fixed now.

end of rules.lua:

client.add_signal("manage", apply)

client.add_signal("manage", function(c, startup)
atag.withcurrent(c, startup)
Comment by Jacob (jacob) - Sunday, 27 September 2009, 02:18 GMT
I take it all back.

The tidy up of client_manage() has changed, so now the client list signal cases a screen layout with the client no longer hidden.
I've resorted to making quite a few changes to rules.lua with the intention that it will always run, even if the user doesn't
add additional rules, so no I keep the client hidden until all the rules are though, then call tag.withcurrent() then focus.

The only other approach I could think of was adding a new signal for stuff that should be done before layout is called.
Comment by Uli Schlachter (psychon) - Wednesday, 09 December 2009, 17:59 GMT
I *think* this was fixed already (33e209dd839085bdef040d60bf7468a584c13c7d "Re-add lazy banning" seems to be good candidate).
Since I'm the reporter and I haven't seen this behavior in a while, I'll close this as fixed.