The original request here was for a logical NOT operator, although it doesn’t make sense to create a logical NOT operator in Locale. Most of the time, NOT isn’t the right way of thinking about a Condition. For example, NOT 9 am to 5 pm could be redefined as 5pm to 9am. NOT at work would simply be the Default situation. For the other conditions built-in to Locale, thinking about the problem in a different way usually means that NOT isn’t needed. If a Condition truly needs NOT logic, then that should probably be put into the individual Condition’s UI itself rather than as part of the Edit Situation screen in Locale.

Although this request is for a NOT operator, I believe the underlying request here is a way of detecting the transition between situations. The strongest use case would be detecting when you’ve left a particular Location. While Locale can easily detect the transition between situations, providing a UI to allow the user to do something with that transition is extremely complex.

Today, Locale treats situations as a continuous event. When Locale determines that a situation is active, it applies that situation’s settings. When leaving a situation, a lower priority situation’s settings take precedence (usually the Defaults). This provides a single, consistent behavior that makes Locale easy to understand.

One suggested implementation is to have “On Enter” and “On Exit” settings within a situation. On Enter settings would work like the current settings within Locale, while On Exit would be applied when leaving a situation. But what if the On Exit settings of a situation are in conflict with the On Enter settings of a higher-priority situation? The number of arrangements that the user must think about has just doubled.

We’re still evaluating ways to solve the underlying requeste of “leaving a location”, without making the UI too complicated…