two forty four a.m. on UserVoice

Not on Conditions [updated]

2010-09-04T20:49:14+00:00

Ability to have NOT on conditions. This is most useful for location (e.g. leaving a location).

Fyrhtu said:

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

Not on Conditions [updated]

2010-09-04T20:47:40+00:00

Ability to have NOT on conditions. This is most useful for location (e.g. leaving a location).

Fyrhtu said:

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

Integrate with Scenes in HTC Sense [updated]

2010-09-04T19:04:29+00:00

The HTC Hero (and probably all subsequent HTC Android devices) allows the user to configure different desktops (scenes), with different widgets, shortcuts, backgrounds etc. For example, a user can have 'Work', 'Home' and 'Out' scenes, and then switch between them for different activities, providing useful access for the given activity. If locale could detect/control these scenes, it would enable both automatic switching of scenes based on rules, and different notification/network/etc profiles for each scene selected.

John Richardson said:

HTC really do need to open up the HTC Sense API - having scenes controlled by Locale would make Scenes 100% more useful!

Screen off [updated]

2010-09-02T03:47:01+00:00

Is it possible to make the phone switch to standby by mode? This would be valuable, since the phone could be made to switch off the screen when the phone is placed face up or face down on a table. This would allow for an increase of the screen standby time. Would also be nice if the screen automatically was switched on when the phone exits the situation.

Carter said:

While technically possible, I'm wary of implementing a true "screen off" setting. I could imagine the combination of some sort of third party plug-in condition and a screen off setting causing the screen to turn off once per second, effectively locking a user out of their phone.

What is the underlying goal with this request? Could you simply set the screen timeout to 15 seconds when the phone is face up or face down, and a longer timeout in the defaults? I believe that might effectively accomplish the same end result of turning the screen off very quickly when the phone is lying flat.

Proximity Condition (coupled with a screen disabler, maybe?) [updated]

2010-09-02T03:39:51+00:00

Is it possible to develop a condition contingent on the proximity sensor used to blank the screen during a call (moto droid)? This would be extremely helpful when coupled with a screen blacker setting (already exist?) while trying to get the phone out of your pocket without picking up before you can screen the call. Also, it would prevent the phone from going into car/dock mode when it's put into a belt case with a magnetic closure flap. Thanks! (Locale is the number one app I brag about on my Droid!)

Carter said:

I understand how accidentally answering the phone when pulling it out of your pocket can be annoying!

Android uses a "slide to answer" screen when the phone is ringing, and this gesture should make it difficult to accidentally answer the phone. Can you be more specific as to what you're experiencing?

Screen off

2010-09-01T08:16:24+00:00

danji suggested:
Is it possible to make the phone switch to standby by mode? This would be valuable, since the phone could be made to switch off the screen when the phone is placed face up or face down on a table. This would allow for an increase of the screen standby time. Would also be nice if the screen automatically was switched on when the phone exits the situation.

Not on Conditions [updated]

2010-08-29T04:55:14+00:00

Ability to have NOT on conditions. This is most useful for location (e.g. leaving a location).

erciesielski said:

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.

Support Live wallpapers for Rooted Users [updated]

2010-08-23T13:02:00+00:00

Carter (admin) responded:

Its too bad that Google has restricted the Live Wallpaper APIs. At two forty four a.m., we avoid implementing anything that requires private APIs, a rooted phone, or a custom ROM. We've found that such features require a disproportionate amount of development time and usually break across different devices and different versions of Android. With over 60 Android phones now on the Market, hacking at private APIs isn't sustainable.

I'll be happy to leave this open however, because it is possible that a third party developer will find this and implement it. (That's how other features like 3G and 4G toggle have been implemented).

Not on Conditions [updated]

2010-08-23T06:46:03+00:00

Ability to have NOT on conditions. This is most useful for location (e.g. leaving a location).

yvolk said:

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

Not on Conditions [updated]

2010-08-23T05:02:36+00:00

Ability to have NOT on conditions. This is most useful for location (e.g. leaving a location).

skylarsutton said:

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

Support Live wallpapers for Rooted Users [updated]

2010-08-23T04:34:54+00:00

actorandrew said:

I know that the original request to support live wallpapers was rejected because of how android handles live wallpapers in comparison to live wallpapers. However it may be worth re-investigating the ability to change wallpapers/live wallpapers for rooted users. There are already a couple of plug-ins that have support for root so I thought it might be worth a shot.

Support Live wallpapers for Rooted Users

2010-08-23T04:30:26+00:00

Proximity Condition (coupled with a screen disabler, maybe?)

2010-08-19T08:01:13+00:00

Kyle Goddard suggested:
Is it possible to develop a condition contingent on the proximity sensor used to blank the screen during a call (moto droid)? This would be extremely helpful when coupled with a screen blacker setting (already exist?) while trying to get the phone out of your pocket without picking up before you can screen the call. Also, it would prevent the phone from going into car/dock mode when it's put into a belt case with a magnetic closure flap. Thanks! (Locale is the number one app I brag about on my Droid!)

Not on Conditions [updated]

2010-08-19T06:49:19+00:00

Ability to have NOT on conditions. This is most useful for location (e.g. leaving a location).

yvolk said:

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

Not on Conditions [updated]

2010-08-18T17:46:08+00:00

Ability to have NOT on conditions. This is most useful for location (e.g. leaving a location).

skylarsutton said:

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.

delayed conditions [updated]

2010-08-12T07:54:44+00:00

Astrid supports Locale, so the obvious thing one might do is to trigger reminders when you, say, come home. However, getting reminded the moment you walk in the door (or more likely, when you're near your home) isn't always useful. You might just be dropping off your bag. So, a location condition that waits a configurable timespan, and then checks if it's still valid before firing off the actions would be handy. Some of the other conditions might also benefit (say, "if I'm *still* on the phone with mom after 30 minutes, then..."), while it would be rather useless for some (if it's still between 9 and 10 in ten minutes).

Brian White said:

Like Ryan said...

I've found that many conditions would benefit from "after being active for X time" (with X perhaps being seconds, minutes, or even hours).

- lost cell signal (after 10 minutes)
- wifi enabled (after 30s for it to connect)
- got up in the morning (after 1 hour)

Rather than have all the plug-ins try to support this, it would make sense to have it supported by the main app.

BTW, this would apply to both the condition appearing and the condition going away, probably with different delays for each.

Feature a link in the UI to a list of user-submitted uses [updated]

2010-08-10T22:21:23+00:00

I can think of a handful of obvious solutions, but I'm sure there are innovative ways of using Locale that might not occur to all of us. How about a user-submitted web-page (formatted for easy viewing on a handset) that lists various configurations and how they are helpful

Carter (admin) responded:

Good idea! This will be implemented once the UserVoice website becomes mobile friendly. In order to make that happen, consider adding some votes to UserVoice's own forum here http://feedback.uservoice.com/forums/1-product-feedback/suggestions/143027-develop-a-mobile-iphone-optimized-site?ref=title

Feature a link in the UI to a list of user-submitted uses [is now planned]

2010-08-10T22:21:23+00:00

make it easier to add locations with a large radius [updated]

2010-08-10T02:10:40+00:00

I'm currently using the beta version of Locale, and I'm waiting for a particular feature before I upgrade. I set up many city-wide locations (40km - 60km radius) to incite actions when I enter a particular market (ie. e-mail a list of folks to let them know I am in the area, change my phone settings based upon the status of the cellular service in the area, etc) I am constantly setting up new instances for the cities that I expect to be in over the upcoming weeks or months, and it is currently quite a challenge to create a location and then convince the maps interface to increase the radius as far as possible based on the current zoom level, zoom out a bit, increase the radius some more, and so on, until the radius covers the entire city. There are several methods I can see to make this process easier: a) when a broad-area location is entered (a city name instead of a street address) have the default radius set to something like 40km when it takes the user to the google-maps location setup screen. That would mean less fiddling to get the radius up to a reasonable level. This could have several possible levels. For example, if I enter just a zip code, the default radius could be 5km. If I just enter a city, the default radius could be 20km. If I enter a specific street address, the default radius could be 100m. b) If there was a way to adjust the default starting radius for new locations. This would be something set somewhere in the program's basic preferences and settings controls. c) In location entry process, you could provide a field to enter a starting radius (in meters, say) right alongside the entry field to enter the address or city. Then, I could simply decide to enter 20km radius for a small city, or a 60km radius for a larger metropolitan area, and it would be a simple matter to make minute adjustments on the googlemaps screen. Option c) is my current favorite.

marnoldster said:

Solutions:

1. As you drag the circle to a certain radius, automatically zoom out a level. To cover a whole city would take a couple of seconds of "stroking" the circle.

2. Use the pinch action change the circle radius. In that way the user could zoom out to whatever level they like, then pinch the circle - whose radius would be linked to the screen-size. In this way, if you are zoomed out far enough, a simple pinch will give you an averaged-sized circle, which in fact would be several thousand meters in radius.

Even more advanced: One finger is the circle centre point, and the second is the radius. Or the two fingers are the diameter. In this way a user could very cleanly do the radius AND position of locations.

Single finger actions should remain the same, as for position especially, it will probably be more accurate.

Duplicate situation [is now planned]

2010-08-09T23:02:44+00:00

This suggestion was previously raised, and closed because it appeared that one of the reasons for it was satisfied with OR. However, that is not the case. It would be tremendously helpful to be able to duplicate an existing Situation in order to create a new situation that is just slightly different. Some of my Situations have 5 or settings, and I just want to make another with slightly different settings or conditions. I would be much easier to use an existing Situation as a base.

Duplicate situation [updated]

2010-08-09T23:02:43+00:00

Carter (admin) responded:

This will be supported by a new feature added in Locale 1.3. It won't be pretty, but it'll satisfy this feature request!

I'll update this with more information when Locale 1.3 is released.