Thanks,

I understand now what you're after. Basically what you'd want, if I understood correctly, is that you could define in a rule that "If this rule matches then actions in rules below this rule will not be considered. Except Default rule, its actions will be applied like always".

I can tell you that I've thought about another feature that would solve your problem just as well, and would be more general, thus allowing many other use cases too. The feature I've thought about, is allowing Rule's Conditions and Actions to "inherit" from another rule. In your case, it'd mean you could inherit the @Lunch conditions from @Work, and it's action's from "Default rule". Then you could override those inherited actions/conditions if you wished for some specialized circumstances.

But... While I like the idea I am not at the moment planning to implement it. With ProfileMatic I must juggle with at least these parameters:

- ProfileMatic is always in the background running. Therefore I must strive for it to be light-weight. I should strive to minimize memory and CPU usage
- Power of expression for user so that he can make rules that do what he wants
- Easy for new users. The UI should be as simple as possible, while allowing creating rules that do what's necessary to make life easier.
- Convenient to create different kind of rules.

Your suggestion, and the one I described about "inheriting" are about "convenience" in creating rules, because same kind of effect can be done with some more clicks in the UI. But they increase complexity in every other case described above.

So... while it may seem a bit annoying to duplicate the actions in the @Lunch rule, I think about it like this: ProfileMatic is meant to make day-by-day living easier and more automatic. The rules are, once set-up, probably changed quite seldom. So it doesn't matter much if there's a bit more work and duplication when initially setting up the rules.

This is my current stance on this, but I've changed my mind about many things in ProfileMatic's operation over time after hearing user input on different use-cases. So I'll keep this in mind and may reconsider in future.