awesome

Welcome to awesome bug tracking system.
Tasklist

FS#888 - add ban and unban client signals

Attached to Project: awesome
Opened by Grygoriy Fuchedzhy (gry) - Sunday, 10 April 2011, 22:01 GMT
Last edited by Uli Schlachter (psychon) - Monday, 27 June 2011, 08:46 GMT
Task Type Feature Request
Category Core
Status Closed
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 3.4.9
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

It would be very nice to have ban and unban signals for clients. Personally I need this feature to suspend/resume browser when it is banned/unbanned. Thanks.
This task depends upon

Closed by  Uli Schlachter (psychon)
Monday, 27 June 2011, 08:46 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Can't easily be done from C without looping over all clients and we already have enough signals to implement this in lua.
Comment by Uli Schlachter (psychon) - Monday, 11 April 2011, 06:14 GMT
Why can't you use the tag's "property::selected" and the client's "tagged", "untagged", "property::type" and "property::sticky" signals and check with c:isvisible() if the client is visible? If you only care when this changes, remember the old return value of c:isvisible() and only do something when it changes.
Comment by Grygoriy Fuchedzhy (gry) - Monday, 11 April 2011, 07:12 GMT
If we consider in detail case with suspend/resume, then we should suspend/resume not only when some tag containing client becomes selected/deselected, if I move my firefox client to another not selected tag it should be suspended also. So "property::selected" will not work for some cases. As I understood "tagged" and "untagged" gets called basicaly when client created/destroyed. "property::type" and "property::sticky" also seem to be not very helpful. The most clear solution here is to add client "ban"/"unban" handlers. No matter if you (de)selected some tag(s) with your client or moved it to another tag or something else handlers would be called just when it is necessary. I tried to add them and they works just fine for this task. Also they may be useful for some other tasks, who knows.
Comment by Aleksey Kunitskiy (marten) - Monday, 11 April 2011, 08:12 GMT
Gry, I think you should add your patch here so more people can test it ;)
Comment by Grygoriy Fuchedzhy (gry) - Monday, 11 April 2011, 08:49 GMT
Patch adding ban and unban handlers.
In order to implement suspend/resume for some client add content of suspend-resume-config.lua to your config and then add something like this to your rules table:

{ rule_any = { class = { "GNU IceCat", "Firefox" } },
callback = function(c)
c:add_signal("ban", suspend)
c:add_signal("unban", resume)
end},
Comment by Uli Schlachter (psychon) - Monday, 11 April 2011, 15:41 GMT
This should be 3.4 config syntax, but I haven't tested anything:

client:add_signal("new", function(c)
local banned = c:isvisible()
function update()
local state = c:isvisible()
if state == banned then return end
banned = state
if banned then
c:emit_signal"ban")
else
c:emit_signal("unban")
end
end
awful.tag.attached_add_signal(nil, "property::selected", update)
for k, v in pairs({"tagged", "untagged", "property::type", "property::sticky"}) do
c:add_signal(v, update)
end
end)
Comment by Uli Schlachter (psychon) - Monday, 11 April 2011, 15:42 GMT
Oh, also:
"if I move my firefox client to another not selected tag it should be suspended also"

That's why I included the tagged, untagged, property::type and property::sticky signals in my first post and not just the tag's property::selected
Comment by Grygoriy Fuchedzhy (gry) - Monday, 11 April 2011, 17:25 GMT
That looks like a hack for me, why not support signals for such native things as ban/unban?
Comment by Uli Schlachter (psychon) - Monday, 11 April 2011, 21:00 GMT
Also, the way your patch works, stuff can easily break. E.g. just change the text of a textbox or the currently focused client. I haven't actually checked the code (depends on the order of stuff done in awesome_refresh()), but with some luck some of these changes will only be applied after the next main loop iteration (and it can arbitrary long until that happens).
Basically, the rule for all the stuff called from awesome_refresh() is "don't call any lua code, or stuff might break (= changes aren't applied ASAP)".

If you really want to do something like this, you'd have to emit these signals from banning_need_update(). However, at that point you don't know which client will be banned/unbanned, so you have to loop over all of them and....

Basically, doing this in the C core would require the same approach as I did for lua above, but it would be a lot longer (minus having banning_need_update() instead of all the individual signals).

Loading...