Migrate the mechanism of listening events to monitor style about easer

[ramack]

My first thought is, that splitting is somehow abstraction, which makes it normally more complex to get started with it. But is might make sense.

Maybe you can remove the link (at least from the way how to enter it) and just give directly a "entering condition" for the profiles.

But let me give an example what I want:
At home always normal loudness, so profile home could have the entering condition "Wifi SSID == Bla".
But now it comes to my mind, that at night I want to switch off wireless and maybe switch to the silent mode. Profile "Night" with condition "between 22:00 and 5:00".

What do I want as profile when I am sleeping elsewhere? Probably Night still active in the times, but in the morning I might want to change back to the last profile before going into night.

But If I activate Wifi during night manually (or by using the phone as in #36) I do not want to enter the "Home" profile.

=> Somehow I have the feeling that "profiles" should have a priority and "independent" entry or activation conditions for profiles do not seem to fit.

Also connecting profiles in a tree and an entry conditions is not good, because my night profile should not only be activated at home, so it would have multiple parents, which is neither a tree anymore, nor really easy to visualize and to configure. But it could for sure happen, that we want this, that one profile is entered only if the conditions of some other profile is active.

So somehow I like the current structure (or how I understand how it should work right now, though not sure whether I really got it right):
Just talking about conditions which we can combine in tree, while the root is not visualized, siblings are processed in a defined order and if a condition matches its subtree is processed. And a profile can be attached at each node in the tree, maybe even the root, which is then the profile selected if nothing else matches. This way the conditions on the path from the root to a specific node are logically "AND"ed, an OR can be done by haveing two paths in the tree. Having a priority can be made by attaching a condition and the corresponding to the end of ALL paths. -> that can potentially be simplified by adding a property to a node (only meaningful at leafs) which stops the further processing of the complete tree.

To make it really simple to configure that structure, I think it would be good to create a wizard that:
allows you to switch to a profile, which 1. changes to that profile and asks about conditions which the user wants or wants not to be en entry for this profile... This is some magic, which would reorder the tree or add some conditions, but we should discuss such a wizard after the visualization and the logic of the conditions and profile changes is finally fixed.

[renyuneyun]

@ramack
Hmm, the longest single comment on github I've ever seen, but I like it :P

I see one thing I may need to emphasis in the documents (or somewhere else): "profile" isn't an accurate name for the idea behind it.
I have to admit the name "profile" is misleading because it sounds like that Easer is going to "fix" (or "load" something (e.g. settings) something to (or according to) a "profile". However, what this mechanism really means is to "do" something (e.g. change settings, as reflected by the name for this kind of plugins: OperationPlugin) (and "something" here could mean several things).
(A better name is always welcome...)

Therefore, it is not appropriate to revert to a profile (because we can't predict how many profiles would be loaded between two time periods). The appropriate way is to "re-"load a profile (in a different event).
However, it could be possible (without violating the semantics) to add the function to "record" some designated settings (e.g. wifi, brightness, ringer mode) before loading a profile (or after loading a profile?) and "load back" this recorded setting at some point. The only problem is that I don't see why people would need this (because we can always load a profile the second time)...

I agree users don't want to see a "complex" system, and it would be a better idea to make users not aware of the separation of Condition and Link, but give advanced users the chance to access and utilize this.

Maybe the expression (of this issue) is not clear enough and it seems to have caused confusion. I don't mean to bind one Profile to (exactly) one Condition (to form a Link). Each Profile could still be connected to several different Conditions (just like the current relation between Profile and Event) -- the difference is to separate the "condition" concept and (maybe) everything else (e.g. the "parent" concept, and maybe also "satisfied" or "unsatisfied" [or something similar]) to two different locations (Condition and Link).

The priority idea is actually two different things: to add priority to a "profile" or to an "event" (or "Condition" or "Link" if expressed in the proposed semantics).
I have (roughly) thought about adding it to "event" previously, and found it not really useful.
If we add priority to "profile", how should we define the semantics of profile? It would them be "a collection of operations PLUS ..." what?