I support this idea with my last vote :-) but I don't think it's easy to implement to be of real use (I mean, different people like different icons...)
But I will give you an alternative idea on how to easily know, in which situation you are now (I use this approach myself):
Set different Wallpapers for different situations! (There is such "Wallpaper" settings plugin...)
This way you may have any wallpaper you like for each situation and make it easily remembered.
E.g. I've set photo of my flat for the "At home" situation...

The weakest point of "Defaults" as they are in Locale is that this is SINGLE set of actions for ALL cases when we leave situations.
This is why in Defaults we have to set (to default values) _everything_ and this is why Defaults are not good in real life: we often have unnecessary changes.

@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 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.

@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 :-)

@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?

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.

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.

Hi pals,
Locale-Audio-Update-Notifier and RingGuard version that supports it's notification
are both being published on Google Market!
Please see screenshots at http://code.google.com/p/locale-audio-update-notifier/

Hello guys!
I've implemented first version of my "Locale Audio Update Notifier" setting plug-in,
put source code to the Repository and prepared .apk file for testing.

I've tested it with special version of RingGuard that x475aws sent to me... Currently it works "sometimes", I mean I couldn't figure out why RingGuard sometimes honors ("likes") my notification, sometimes - not :-(

Project Home Page: http://code.google.com/p/locale-audio-update-notifier/

Ok, please email me yvolk at yurivolkov dot com.
--
Yuri

So let's compare different scenarios to help you decide,
in which case RingGuard will have higher rating:
1. RingGuard is being used without Locale.
- No difference, if it was adapted as I propose or not.
2. RingGuard is being used with Locale AND no volume setting Locale plugin is used.
- Same as above: no difference.
3. RingGuard is being used with Locale AND some volume setting Locale plugin is used.
3a. RingGuard is the same as now - without modifications:
- If User sees "confirm dialog" when Locale decides to change volume, User has to figure out what happened: properly and quickly, - and then either confirm or cancel the dialog. Believe me, this is bad user experience :-)
- If User missed the moment, the volume wouldn't be changed, so desired volume change wouldn't occur at all. Bad too (e.g. if phone rings at night when User hopes it wouldn't...)
3b. RingGuard was adapted as I propose:
- User may see "confirm dialog" when Locale decides to change volume, but after a second or two... the dialog disappears.
- If User missed the moment (this means if he or she didn't look at the screen for some seconds...), the volume will be changed, as intended. Good, because User doesn't know about this.

...I am personally at the point 3a now and I don't like the situation. Do you know which app I will uninstall? ;-)

Hi x475aws,
_I_ may do these modifications:
1. I will write and publish the "Locale RingGuard setting plug-in". I just need your API specification to achieve this (I don't see it at http://www.openintents.org/en/intentstable , please post me).
2. To modify RingGuard itself
to make it accept Intent with Volume change info not only before actial Volume change, but also during "Wait time", that's already configurable in RingGuard,
I need your help. There may be two options:
a) You make these modifications yourself. In fact these are NOT Locale-specific modifications: they effectively extend breadth of your RingGuard usage...
b) You trust me to make these modifications in your code (we may discuss NDA privately).
I will do modifications and testing, and then
I will send modified version to you to be included in the next release on the RingGuard and published by you.

So what's your move?

(I've added comment some minutes ago, but it disappeared... so this reposting)

>yvolk, maybe I misinterpreted the word "exclusively" in Carter's statement
>"As long as users use your setting exclusively within Locale, then you'll always receive
> an Intent before Locale changes the volume."
No, I think you understood Carter right: he wrote about single "Settings plugin" that will change volume AND then send Intent to RingGuard.

> So you're saying users could combine a no-op RingGuard setting
> with the settings they already use?
2. Yes, my proposal will allow to use any existing Volume settings plug-in in combination with non-op RingGuard setting plug-in (the letter plugin is thus "RingGuard enabler" :-) ) .

3. What's about race condition, I think that it is enough for RingGuard to accept Intent with Volume change info during "Wait time", that's already configurable in RingGuard.
I personally have set the "Wait time"= 15 sec, so I'm sure this is enough time to wait for that Intent.
And of course, you'll have to create good Documentation for your "Locale RingGuard setting plug-in", describing what it does (and what it doesn't do) and how RingGuard app itself should be configured to work with Locale...

@x475aws It came to me that in order to "integrate" Locale with your application (RingGuard), you have to write VERY simple "Locale RingGuard setting plug-in"
that does nothing except sending your custom Intent to your application :-)
According to this approach User continues to use any "Locale Volume setting plugin" he or she wants (including built-in plugin), but in order to live with your RingGuard application User has to add to the "situation", that has "Locale Volume setting plugin" another setting plugin, the "Locale RingGuard setting plug-in" plugin.

The only problem may be in "Broadcast races". I mean information that volume was changed may be received by your application (sligthtly) before broadcast from "Locale RingGuard setting plug-in".
You should change RingGuard logic so that it may accept broadcasts that come even slightly after volume changes (maybe even upto some seconds...)

What do think?