Hi Tylo,
Yes. It's not the first time it is requested, e.g. there already was
something similar on the HLML[1]
Ah. Sorry I missed this and now you're repeating yourself.
This creates a hard dependency to /bin/sh and assumes /bin/sh behaves
correctly for -c.
Yes. That was the main reason I was against it. I suppose a possiblity would be to let the user set his shell, but that still wouldn't solve the infinite loop problem.
I'd prefer a consequence that emits a hook. Syntax: hook=NAME, so it
means, that a hook called "rule NAME" is emitted each time that rule is
triggered.
That means the user has to start a own daemon that listens to these
hooks and then reacts to it. It still has this problem of a endless
loop, but it can't be triggered easily.
I like this idea a lot. Not sure if I'd consider making the user the one responsible for races/loops would be 'friendly' though ;).
And directly calling hlwm commands isn't a option because of the
parsing/quoting issues you already mentioned and because of the endless
loop problem.
The loop problem, yes. But the quoting problem: using the first method, if sh is bash, you simply need to escape your quotes. But it breaks nested quotes afaik.
So what do you think about the hook-consequence? And another open
question is, which hooks should be emitted for these rules if a new
window appears?
hc rule hook=hook1
hc rule hook=hook2 hook=hook3
Possible options are:
- hook3
- hook1, hook3
- hook1, hook2, hook3
What's the most intuitive behaviour?
I think the third one is most intuitive (a hook for each, in the order they're stored in the list). Your second suggestion isn't intuitive IMO, unless we INSIST that multiple hooks for identical conditions doesn't have a use. But I don't see a point in arguing that when the implimentation would be nearly the same amount of work.
The hook idea is great, but how can we assure the user that the window that matched the condition is the one they perform actions on in their script? We could optionaly include the winid with the hook (perhaps as a substitution or something):
hc rule hook="Hook1. Window:%{WINID}"
Then the user can use jumpto or bring to assure it's the right window. What other information might they need with this hook?
Tylo.
Ps. Is there a way for the user to get the winid of the active window without parsing dump?