yux0 / reduxcomputing-proximity

Automatically exported from code.google.com/p/reduxcomputing-proximity
0 stars 0 forks source link

Option for successive out tests #7

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
A great addition would be the ability to test multiple times before an
"out" is declared. I often get false negatives (resulting in a screensaver
firing off while I'm working), but two successive checks of the same status
would likely prevent that.

Original issue reported on code.google.com by mtravisb...@gmail.com on 24 Aug 2009 at 4:13

GoogleCodeExporter commented 8 years ago
I have to concur. This was a feature in an earlier release that seems to have 
vanished. The false negatives I get 
with this new version make it practically unusable.

Original comment by gregtrot...@gmail.com on 18 Sep 2009 at 4:50

GoogleCodeExporter commented 8 years ago
I have this same problem.  I really like the idea of this program but the false
positives are making the program unusable.

Original comment by bertwag...@gmail.com on 10 Nov 2009 at 7:13

GoogleCodeExporter commented 8 years ago
False positives happen (to me) with all apps that check the bluetooth status 
(Proximity, MarcoPolo, BluePhone, HomeZone, shell-tools). It also happens - 
less often 
though - on the windows (xp) machines (with Toshiba and Widcom Bluetooth 
stacks). I assume, this has little to do with Proximity.

My Out_of_Range-AppleScript therefore asks, if the script should really be 
activated. The default button being "Cancel", the timeout 3 seconds. If I am 
working, and this 
pops up, I just hit return (on the keyboard) and it's gone. Minor 
inconvenience, but bearable (for me).
If I am *not* at the machine, this dialog exits after 3 seconds and the script 
continues (locking the machine, stopping the media players and that stuff).

Of course the script could just be dismissed the first time and fire only after 
having been called twice or three times.

Handling this in a script makes it quite flexible (how many seconds to timeout? 
should there be a timeout at all?, how many times after a "false negative" to 
fire? warning 
by sound? warning by growlnotification? should it only run when in a certain 
network?). Although any further development on Proximity.app would be 
wonderful,  I 
wonder how many variations could be implemented in Proximity.app before it gets 
too overloaded. I would like Proximity.app to do just *one* thing: Track/Detect 
devices 
in the bluetooth range.
Maybe doing this in a script isn't the worst way of all. 

I know this is not the solution people are looking for (since it is not 
implemented in Proximity.app) but might be a workaround for the one or the 
other. It's not meant to 
be lecturing, but to help those, who are stuck with the current version 1.5.

Original comment by wolf.mce...@gmail.com on 3 Dec 2009 at 9:43

GoogleCodeExporter commented 8 years ago
I've just messed around with the program and it functions quite smoothly. I 
don't
have any false positives. The only gripe I have with it is the lack of changing 
the
range of sensitivity, which I had with blueproximity in Ubuntu. The applescript
approach is nice though as it forced me to dabble with it and get a bit 
familiar with
applescripts. Not sure why others are having issues with random screen 
activations...

Original comment by mec...@gmail.com on 18 Dec 2009 at 12:37