Not on Conditions
Ability to have NOT on conditions. This is most useful for location (e.g. leaving a location).
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...
Fyrhtu
... That's not to say, however, that I wouldn't appreciate a "Leaving" condition; although it can be replicated with creative use of the Variables plugin, it would certainly be nice to have that baked in.
Fyrhtu
@erciesielski: The situation you've given doesn't require a "not"- it's a "Plugged in" AND "Between [sunset] and [sunrise]" Condition with lower priority given to it than a second condition, "Between [Sunset] and [Sunrise] AND "Plugged in" AND "Location:home."
You could also achieve a lot more by tossing in the Locale Variables plugin- but the core is the same; you don't need "Not" for the situation you're describing, you just have to thin... more
@erciesielski: The situation you've given doesn't require a "not"- it's a "Plugged in" AND "Between [sunset] and [sunrise]" Condition with lower priority given to it than a second condition, "Between [Sunset] and [Sunrise] AND "Plugged in" AND "Location:home."
You could also achieve a lot more by tossing in the Locale Variables plugin- but the core is the same; you don't need "Not" for the situation you're describing, you just have to think around it and find what the situation IS.
erciesielski
The reason I want this feature is because I want to use a "not at home" condition. When "not at home" and plugged in after sunset, I want my screen to dim because I obviously would be driving at night.
yvolk
@skylarsutton We are talking about different things: you need only "not" option for each condition with the same whole other logic. This indeed may be done easily.
I'm trying to change the logic of handling "entering situation" and "leaving situation" on the timeline in cases when we're "in" several situations simultaneousely...
So in fact two different tasks are under the same "Not on Conditions" topic :-)
skylarsutton
@yvolk - I've seen the API. Every condition responds in one of three ways:
1) i'm satisfied
2) i'm not satisfied
3) i don't know if i'm satisfied
The "implementation description" is a drop down in the edit situation page with "when condition is met" and "when condition is not met". If it's anything more than that you have WAY overengineered it. When the "not" option is selected just inverse the conditions response:
1) i'm satisfied becomes "i'm not sati... more
@yvolk - I've seen the API. Every condition responds in one of three ways:
1) i'm satisfied
2) i'm not satisfied
3) i don't know if i'm satisfied
The "implementation description" is a drop down in the edit situation page with "when condition is met" and "when condition is not met". If it's anything more than that you have WAY overengineered it. When the "not" option is selected just inverse the conditions response:
1) i'm satisfied becomes "i'm not satisfied"
2) i'm not satisfied becomes "i'm satisfied"
3) i don't know if i'm satisfied says what it is
Give me the source code and i could have this done in 10 minutes - it's not a difficult problem to solve in any way shape or form.
yvolk
@skylarsutton Unfortunately it's not so simple :-(
I've wrote some proposals on implementation of this feature (see below) but returning to them I see that they are far from perfect.
So the task still needs good implementation description. The idea is not enough.
skylarsutton
I find Carter very confrontational in these discussion forums - and frankly not interested in listening to user feedback. If your users have a need for a not condition (myself included) just make it already and stop arguing with them.
yvolk
@Carter “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?”
I’ve read Locale-Help once more and I see that in order to describe, how this may be easily understand by User and implemented by programmers, we need to enhance Locale “model” some more. Here are my suggestions:
1. Situations which “conditions” a... more
@Carter “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?”
I’ve read Locale-Help once more and I see that in order to describe, how this may be easily understand by User and implemented by programmers, we need to enhance Locale “model” some more. Here are my suggestions:
1. Situations which “conditions” are met are called “current” (not “active”, as it was earlier!!!). There may be one or more “current” conditions at any point in time. “Defaults” situation is always “current”.
2. “Active situation” is “current” situation with highest priority. At any point in time only ONE situation is “active”.
3. When situation becomes “active”:
3.1 Previous “active” situation becomes “current” (i.e. not active) and it’s "On Exit" settings are triggered.
3.2. “On Enter” settings of new “active” situation are triggered.
4. When device leaves “active” situation it’s "On Exit" settings are triggered. After this, next by priority “current” situation becomes “active” and “On Enter” settings of that new “active” situation are triggered.
5. This way “On Enter” settings of each situation will be always followed by “On Exit” settings of the same situation.
I think that above statements (accompanied by good picture…) will make clear for the User what happens :-)
yvolk
@Carter Let me show you that "Defaults" situation is NOT working as expected at least in some cases.
You're thinking about timeline on which different "Situations" appear as "islands" on the top of the "Defaults" ocean :-). If this was always a case "Defaults" situation MAY be used for setting ALL "settings" to their default values (although IMHO this is a bad practice to set ALL possible settings so often...)
But my experience shows that si... more
@Carter Let me show you that "Defaults" situation is NOT working as expected at least in some cases.
You're thinking about timeline on which different "Situations" appear as "islands" on the top of the "Defaults" ocean :-). If this was always a case "Defaults" situation MAY be used for setting ALL "settings" to their default values (although IMHO this is a bad practice to set ALL possible settings so often...)
But my experience shows that situations are more like a lot of different sized papers laying on a table: they overlap each other, and I often don't see the top of the table ("Defaults" situation) moving from one paper to the other. In this case "Defaults" doesn't work AT ALL, and my settings may not return to the default values for a long time producing UNPREDICTABLE behaviour of the phone.
One very common example of the "large pieace of paper that hides the table" is "At night" condition, in which (i.e. "when") I usially turn off sounds. My phone may encounter different "situations" at night, each of them may set something, but with curent version of Locale NONE of these settings will be returned back to default values, at least before night ends...
Is this case convincing?
Alex
I agree that it would be very nice to have "On condition starts" and "On condition ends", would be so flexible! And of cause some checkbox like "Go back to default" and grey out "On condition ends"
Mil
The main reason for me voting for this is so that I can achieve changes when "leaving a specific area" e.g. when I leave work. I think it would be really good if the location condition had a setting for (entry, during or exit) so that you can specify exactly what about the location sets of the triggers.
I can see some value in also having a NOT operator as well but I think the Leaving a location is more valuable to me.
yvolk
I've just wrote comment and my implementation proposal for the "Add new condition type of Leaving Situation" suggestion, and I think my proposal will allow to implement this suggestion ("Not on Conditions") also,
so in fact votes for both suggestions may be added :-)
Exuse me for the this crosspost, and cross voting :-)
----------------------------
I support this request,
and I think that it's implementation will make "situation" description much more intuitive for the... more
I've just wrote comment and my implementation proposal for the "Add new condition type of Leaving Situation" suggestion, and I think my proposal will allow to implement this suggestion ("Not on Conditions") also,
so in fact votes for both suggestions may be added :-)
Exuse me for the this crosspost, and cross voting :-)
----------------------------
I support this request,
and I think that it's implementation will make "situation" description much more intuitive for the User.
It's really simple to think in these terms:
- How do I describe situation? ("Condition" in Locale)
- What should be done on entering the situation? (currently "Settings" in Locale. I propose to rename this to "On entering the situation:")
- What should be done on leaving the situation? (new group of the same "settings" plugins. I propose to name it "On leaving the situation:")
In fact, in most cases settings "On leaving the situation" will mirror (revert) settings set for "On entering the situation". And both settings will be conveniently located in one place (in one "situation"). Today we have to figure out, which settings should be put into Defaults... and this is hard... at least for me. But I'm an IT professional, after all. I guess non-tech users are often at least disappointed...
Some common "situations" that will benefit from this new Locale feature:
- I came home/I left home (work, etc. ).
- The night started/ended (same for weekend...).
- I connected to Wi-fi/disconnected from it (same for Power source, bluetooth).
- Battery level dropped below 20% and I do not charge/battery is OK or I connected to the charger.
yvolk
I support this request, and I think that it's implementation will make "situation" description much more intuitive for the User.
It's really simple to think in these terms:
- How do I describe situation? ("Condition" in Locale)
- What should be done on entering the situation? (currently "Settings" in Locale. I propose to rename this to "On entering the situation:")
- What should be done on leaving the situation? (new group of the same "settings" plu... more
I support this request, and I think that it's implementation will make "situation" description much more intuitive for the User.
It's really simple to think in these terms:
- How do I describe situation? ("Condition" in Locale)
- What should be done on entering the situation? (currently "Settings" in Locale. I propose to rename this to "On entering the situation:")
- What should be done on leaving the situation? (new group of the same "settings" plugins. I propose to name it "On leaving the situation:")
In fact, in most cases settings "On leaving the situation" will mirror (revert) settings set for "On entering the situation". And both settings will be conveniently located in one place (in one "situation"). Today we have to figure out, which settings should be put into Defaults... and this is hard... at least for me. But I'm an IT professional, after all. I guess non-tech users are often at least disappointed...
Some common "situations" that will benefit from this new Locale feature:
- I came home/I left home (work, etc. ).
- The night started/ended (same for weekend...).
- I connected to Wi-fi/disconnected from it (same for Power source, bluetooth).
- Battery level dropped below 20% and I do not charge/battery is OK or I connected to the charger.
Oddur Snær
I actually bought this app thinking this was in there. seems such a basic feature to have.
khag07
Actually i just had another thought.. instead of just having "settings on condition start" and "settings on condition end" what if there was a way to create as many "settings groups" as you wanted.
to create a settings group you would be prompted for x y and z:
run z times, every y minutes, starting x minutes after condition start/end
*note z can be infinite and can't be zero
*note y isnt necessary if z=1
*there could also be an option to abort the x delayed event i... more
Actually i just had another thought.. instead of just having "settings on condition start" and "settings on condition end" what if there was a way to create as many "settings groups" as you wanted.
to create a settings group you would be prompted for x y and z:
run z times, every y minutes, starting x minutes after condition start/end
*note z can be infinite and can't be zero
*note y isnt necessary if z=1
*there could also be an option to abort the x delayed event if the condition becomes true again, i.e. if i leave work but i'm back before the x time is up then don't do the settings change
so to create a settings group of "run once on condition start" (this is what locale does now) you would choose x=0, z=1, y=doesnt matter since we're only running once
the biggest benefit to this isnt really repeating actions (i'm not sure many people would use this) but rather the delaying by a certain number of minutes and more importantly aborting the action if the condition changes. so if i have something set to change 5 minutes after i get home but i leave home within 3 minutes, then the action shouldnt happen
khag07
wouldnt it be smarter to have a 3rd section when you add a situation to locale? currently for each situation we have conditions and settings. immagine we had instead conditions, settings on condtion start, settings on condition end.
this way we could say when the condition begins (location equals home) turn on my wifi, but when this condition ends (is no longer true, i.e. when i leave home) turn off the wifi.
this is similar to defaults but we can set things to happen when specific conditions end... more
wouldnt it be smarter to have a 3rd section when you add a situation to locale? currently for each situation we have conditions and settings. immagine we had instead conditions, settings on condtion start, settings on condition end.
this way we could say when the condition begins (location equals home) turn on my wifi, but when this condition ends (is no longer true, i.e. when i leave home) turn off the wifi.
this is similar to defaults but we can set things to happen when specific conditions end. for example when the condition "location = work" ends i could send an SMS saying "leaving work" but I don't want to use the defaults for that since I don't want to send that SMS when i leave home.
this would also work well with time based events. i use my calendar to trigger events more often than I use location. when an event (say, a class, where I have my phone set to go on silent automatically) is over I can set my phone to turn back up.
i think this solution would be more effective than having a "not" condition and more effective than using the defaults.
also there is a problem with using the variables plugin to do this. you have to set the variables to turn back to false or reset to zero when a condition ends otherwise they continue to be true (is this incorrect? i have used the variables plugin only a little but this is the conclusion i have come to). by having an "settings on condition end" section we can reset variables that were set up in "settings on condition start"
i think this really is the best way to roll a few requests into one, namely the "not" and the "on condition end" ideas
vlbatcfcl
I want to have "Home" vs "Away from Home".
janiskfp
How about working with DroidMunkey and supporting their work to make this possible? There are a bunch of hurdles that are native to Locale that make setting these up tedious, and not intuitive. I think a partnership endeavor would be effective, and I think they'd love it.
Mat
I'm using the dock plug-in and I have settings that I want to start when I undock my phone. Right now I have to use the "Undocked" condition, which means it's on the majority of the time. I really only want it to trigger something once when I go from docked to undocked. This could not be accomplished using a "not on" condition, so I would like the "leaving situation" condition as a separate feature.
kinkymunkey
There is a new plugin called "Locale Variables" that will allow you to do stuff like this
You can set a string (last location = work or was_at_work = true) and then use it as a condition in another plugins.
Crazy powerful!