Re: Super flexible rules

[Thorsten Wißmann <edu _at_ thorsten _minus_ wissmann _dot_ de>]

Hi Carlos,

the idea of making rules (even) more flexible is good! But in my opinion
this first conept is way too flexible because it can break the window
manager in too many different ways; mainly it too easy to let the window
manager explode if one makes a small mistake in the netrule.sh.

On Tue, Sep 18, 2012 at 07:02:11AM -0300, Carlos Pita wrote:
> what follows is a very simple suggestion for a powerful rule mechanism
> that naturally extends the existing one. The idea is to add a flag
> that is neither exactly a condition nor a consequence but a script
> that generates further conditions and/or consequences. For example:
> 
> rule class=Netscape windowtype=_NET_WM_WINDOW_TYPE_DIALOG
> rest=netrule.sh tag=6 focus=off
> 
> would mean: check that the window class is Netscape and window type is
> dialog; if false just abort, otherwise call netrule.sh with instance,
> class, title, pid, maxage, windowtype and windowrole as parameters
> (alternatively as its environment); if netrule.sh outputs the string
> "0" or "false" (alternatively returns a code != 0) abort,

The main problem here already is: If such a rule is executed,
herbstluftwm has to wait for that netrule.sh (i.e. maybe hangs) or it
will make the code very complex.

An infinite loop can be created by this rule:

    rule class Netscape rest=netscape

And: If netrule.sh never returns because itself runs into an infinite
loop the Netscape window never is shown.

> otherwise netrule.sh should output something like, say, "title~.*mail
> index=/0"; combine this output with the rest of the parameters to get
> "title~.*mail index=/0 tag=6 focus=off"; then apply this rule as
> usual.

This makes it easier to create an infinite loop, if this output again
contains a rest parameter, e.g. with that bash script:

    echo rest=$0

Of course, the user always is able to create infinite loops in his own
scripts, but there are two major differences:

  - With this rest-rule makes it very easy and you don't see at the
    first sight.
  - It's the window manager that hangs and not just some script

So I would prefer finding a solution that solves some example problems
you named:

> - Rules that are contextual to specific workspaces

A curtag-condition would solve that. (Which checks the current tag name)

> - catch-all and dedicated frames

I guess you are talking about musca's catchall and dedicate commands[1].
If Yes: That would be a use case for that rest= thing. But how do you
mark them as dedicated? Only this wouldn't solve it, so it it is
probably much easier to directly implement it in the herbstluftwm core.
The catchall feature already is planned and the dedicate thing also is
possible.

> - In general, more complex logical expressions, not just because of
> the extended logical form but because of the ability to further
> inspect hswm state.

Yes, that would be nice. But the question is: How many use-cases are
there that can't be solved yet? One already can write a script that
always checks the hlwm state and dynamically adds a rule if certain
conditions are met. It also planned to be able to single remove rules
again, currently those rules only can be overwritten by adding more
rules.

> - And also, more complex consequences because of the ability to
> (carefully!) manipulate hswm state (for example, to change the current
> workspace).

The solution for this would be something like a hook-consequence which
emits a hook if that rule is applied. E.g. class=Firefox hook=hellofox
would emit a hook like:

    rule_applied hellofox $windowid

This could be used to wait for hooks and then react to it to do hlwm
state modifications.

Changing the workspace already is implemented since v0.4 by the
switchtag consequence.

Would these different approaches also cover your use cases?

Are there any other opinions?

Thorsten

[1] http://aerosuidae.net/musca_commands.html