From "Event" to "Event" + "Condition"

[renyuneyun]

This is the current thinking, and welcome everyone to comment.

Currently, the so-called Advanced Scenario Condition provides a mechanism to set an Event to be persistent, meaning it will stay "true" after it's set to true, and another mechanism to set non-repeatable, meaning the corresponding Profile won't be loaded again when the condition/criteria for that Event is met again during the time this Event is "true".
These two mechanism can deal with many circumstances and can be seen as a weaken version of Condition (see below), but couldn't cover everything.

Therefore, I'm planning to split some of the Events to Conditions for better semantics:

• Event represents for short-term events (e.g. a specific app is launched)
• Condition represents for long-lasting (but changable) conditions (e.g. a specific app is on foreground)
  (This actually has been proposed by users, e.g. Add option for 'events' to be based on actual events, and not continuous behavior #55 )

My previous thoughts were based on the assumption that the persistent + non-repeatable + EventControlOperation combination is enough to cover all aspects of Condition (as said in #55), but now I think this may not be enough. I think, as said above, splitting them will introduce more clear semantics and make conditions easier to design. (Additionally, this will make better battery life.)

The current plan is to add a dedicated section for Condition (in addition to Event, Scenario and Profile), and the user should define a Condition prior to using it. (I'm also planning to rename the Event section, but have no idea what new name should be given. See the example for why.)
For example, a user may define a Condition representing the current location, e.g. home (let's call it home). Then, the user can select the home Condition when defining an item in Event (section), and specify a Profile; similarly, define another item in Event with "reversed" to home Condition and specify another Profile.
This looks almost the same as the current use case, but one of the biggest difference is that each Condition will have one instance persistently running. This means

1. You don't have to change your location before this is fired (Profile is loaded) in passive mode
2. It is especially useful when you want to chain for many layers. For example, like in Bluetooth headset action #85, you can specify two Conditions (one for bluetooth headset, one for location) in any order, and the check will always be the intuitive result.
3. Easer can always run in passive mode (which saves battery), because the only usage of active mode is to check the condition when a child Event is ready to be checked.

However, if introducing Condition, the previous Advanced Scenario Condition is most likely useless (maybe except for the "reversed"), but I'm not yet fully sure.
It is also a question whether I should add "enter Condition" and "leave Condition" as (shadow) Events?
Similarly, where should the "reversed" be put to? Should it be used for Scenario only, or should it also be applied to Condition? Where in the Condition mechanism should the "reversed" live (e.g. should it behave like the example above)?

[renyuneyun]

Closed because already implemented in v0.6.
Passive mode may be removed someday.