Re: [PATCH] consequence: spawn

[Thorsten Wißmann <re06huxa _at_ cip _dot_ cs _dot_ fau _dot_ de>]

Hi Tylo,

On Thu, Dec 13, 2012 at 09:27:30AM -0800, Tyler Thomas Hart wrote:
> On Thu, Dec 13, 2012 at 7:54 AM, Thorsten Wißmann wrote:
> > On Wed, Dec 12, 2012 at 06:19:42PM -0800, Tyler Thomas Hart wrote:
> > > As requested by Wintervenom on archBBS (
> > > https://bbs.archlinux.org/viewtopic.php?id=128646&p=12 post#292 ), I
> > > implimented a spawn consquence when a rule is matched.
> >
> > 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.

The feature was a bit different, so this was just a comment. Of course
you don't have to read the entire archive before suggesting something
here.

> > 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.

Yes and there isn't any sh if we would call internal hlwm command. But
it doesn't matter; it is no option at all.

> > 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.

I also think the third one is the most intuitive option.

> 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}"

Right, I didn't think of the window id, so the easy fix is to *always*
add the window id as the third argument:

    rule $NAME $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?

Maybe there are names (or ids) for rules on some day, but actually the
hook=$NAME is sufficient for debugging.

If someone reacts with jumpto or bring to hooks created by rules, then
it really gets racy! But there already is a solution: The consequences
tag, switchtag and focus. (e.g. tag="" brings the client to the active
tag).

> Ps. Is there a way for the user to get the winid of the active window
> without parsing dump?

Yes. There is xdotool getwindowfocus (based on X11-Focus) and xdotool
getactivewindow (based on ewmh).

Regards,
Thorsten