Really headed next door now but..
This is from the original poster..
"I’m working on a productivity & RSI prevention app. So I want to notice
activity while my project is not the frontmost application."
On Sun, Dec 25, 2016 at 10:08 AM, Mike Bonner <bonnm...@gmail.com> wrote:
> And on that note, heading to see the family. Merry (insert your own
> acceptable season greeting or general wish for happiness here.)
>
> On Sun, Dec 25, 2016 at 10:08 AM, Mike Bonner <bonnm...@gmail.com> wrote:
>
>> Actually, the question boils down to "is the user active." not "what key
>> is pressed, was a screen scrolled(using what device) , or what button was
>> clicked." I could be wrong. /shrug The only recent issue that needed to
>> be solved is that scroll is an activity too, and there was no easy way to
>> get lc to see that as an action.
>>
>> This ignores the whole question and lets lc poll the os to see if there
>> was any HID action at all-- this (if I understand correctly) being the
>> ultimate goal.
>> So yeah, if you scroll with you belkin, its a scroll. As on a mighty
>> mouse. But for this purpose (again, if I understand correctly) it doesn't
>> matter. An action of any type, by a user (typing, scrolling, clicking,
>> using a touch screen) shows that the user is actually sitting at the
>> computer.
>>
>> If you have a different needs that just tracking idle/active time, this
>> is not for you.
>> Otherwise, there is no longer a need to look at keysdown() or
>> mousescreenloc at all. Just grab the number from the os. If the mouse has
>> moved recently, it'll be small. Same for keypresses, scrolls, clicks,
>> screen touches.
>>
>> So as in the example of catatonia.. Was it a poke, a tickle, a prod, a
>> kick.. If all you're looking for is signs of brain activity, it doesn't
>> matter. (simplified of course, because in those cases examining responses
>> to different stimuli DOES matter during evaluation.. but not so with the
>> desired goal)
>>
>> On Sun, Dec 25, 2016 at 9:51 AM, Richmond Mathewson <
>> richmondmathew...@gmail.com> wrote:
>>
>>> Aha: thanks.
>>>
>>> On 12/25/16 6:39 pm, Mike Bonner wrote:
>>>
>>>> The script does an end run of the whole situation. The os itself is
>>>> keeping track of the idle time between user events. All the script
>>>> does is
>>>> grab the current value. And since only HID (human interface devices) are
>>>> tracked, any mouse/keyboard activity in any app of the system will reset
>>>> the timer. So technically no, the scroll won't "register" in the lc
>>>> stack
>>>> (meaning it won't cause a handler to fire), but the OS does track HID
>>>> actions.. All the stack does is request the information from the os
>>>> (in a
>>>> loop), that information being the time since the last user activity.
>>>>
>>>
>>> So, the inevitable question is how one would use an idle time value to
>>> tell
>>> one that the end-user his performed a scroll (and whether up or down),
>>> as all
>>> those idle time values are are times in (?) micro-seconds.
>>>
>>> I assume (?) that, somewhere in the belly of the beast (Mac OS) a HID
>>> performed action
>>> must register as such, and also as WHICH HID was used, and WHAT action
>>> was performed on
>>> that HID.
>>>
>>> A forward scroll on my Belkin Nostromo is just as much a forward scroll
>>> as one on my mighty mouse.
>>>
>>> The question that started this thread concerns NOT whether one can pick
>>> up signals that HIDs are
>>> being used, but when they ARE being used, which of the activities being
>>> performed is a scroll.
>>>
>>> This seems remarkably like the problem with other people:
>>>
>>> 1. We can generally tell when brain activity is going on in other people
>>> (however, c.f. catatonia),
>>> and we can stick electrodes into parts of the human brain so that we can
>>> pick up electric pulses
>>> that tell us when the brain is receiving signals from outside the body.
>>>
>>> 2. What cannot (as far as I am aware) be worked out (if one is not
>>> cheating and looking at who
>>> is poking your volunteer in the stomach with a chopstick) is what is
>>> being done to make the brain
>>> register those signals.
>>>
>>> Richmond.
>>>
>>>
>>>>
>>>>
>>>> On Sun, Dec 25, 2016 at 9:29 AM, Richmond Mathewson <
>>>> richmondmathew...@gmail.com> wrote:
>>>>
>>>> Does that mean that if, say, I have a stack running your script in the
>>>>> stackScript
>>>>> and I'm scrolling a window in Firefox that that scrolling will
>>>>> register in
>>>>> the LC stack?
>>>>>
>>>>> The reason I am asking that question is because I don't quite
>>>>> understand
>>>>> how one effect a mouseUp
>>>>> while one is scrolling with one's mouse at the same time and the
>>>>> mouseUp
>>>>> not affecting the frontmost app.
>>>>>
>>>>> Richmond.
>>>>>
>>>>>
>>>>> On 12/25/16 5:56 pm, Mike Bonner wrote:
>>>>>
>>>>> I have an answer..
>>>>>>
>>>>>> Heres a sample script:
>>>>>> local sRunning
>>>>>>
>>>>>> on mouseUp
>>>>>> if sRunning is empty then put false into sRunning
>>>>>> put not sRunning into sRunning
>>>>>> loopit
>>>>>> end mouseUp
>>>>>>
>>>>>> command loopit
>>>>>> if sRunning then
>>>>>> put the last word of (shell("ioreg -c IOHIDSystem |grep Idle")) into
>>>>>> tIdle
>>>>>> put tIdle / 1000000000 into field 1
>>>>>> send "loopit" to me in 2 sec
>>>>>> end if
>>>>>> end loopit
>>>>>>
>>>>>> The script is in a button, and I have a single field on the card. The
>>>>>> math
>>>>>> is done to convert to seconds of idle.
>>>>>>
>>>>>> The are only 2 disclaimers here. First is that the value returned pre
>>>>>> 10.3
>>>>>> is hex so you'd have to handle that if you have an earlier osx. 10.3
>>>>>> and
>>>>>> after this solution should work fine.
>>>>>>
>>>>>> The second issue is is that on mac 10.12, the idle time won't update
>>>>>> on
>>>>>> typing. Its an osx issue for that specific version, but worst case
>>>>>> you
>>>>>> already have a method to track keypresses.
>>>>>>
>>>>>> On Sun, Dec 25, 2016 at 8:21 AM, Paul Dupuis <p...@researchware.com>
>>>>>> wrote:
>>>>>>
>>>>>> On 12/25/2016 10:05 AM, Terry Vogelaar wrote:
>>>>>>
>>>>>>> So it starts to become clear that it might not be possible to do
>>>>>>>> what I
>>>>>>>>
>>>>>>>> want. Although I hope to be wrong about that.
>>>>>>>
>>>>>>> I think it is very unlikely you can do this in LC - without
>>>>>>> externals or
>>>>>>> LCB widgets from "infinite Livecode".
>>>>>>>
>>>>>>> The active mouse and keyboard drivers capture events from these
>>>>>>> devices
>>>>>>> and pass that information to the operating system, which massages the
>>>>>>> data and passed a higher level of events on to the active
>>>>>>> application,
>>>>>>> which looks for such events and handles them. In the case of the
>>>>>>> LiveCode engine - or any app built on the LC engine - that is
>>>>>>> executing
>>>>>>> applicable messages for your scripts to handle.
>>>>>>>
>>>>>>> Most productivity tracking software works by effectively inserting
>>>>>>> code
>>>>>>> into where the device drivers meet the operating system, so that
>>>>>>> mouse
>>>>>>> and keyboard events are captured by the productivity app's as well as
>>>>>>> being sent by the OS to the active application as normal.
>>>>>>>
>>>>>>> Using LCB and LC9.0 you might be able to write an LCB widget that
>>>>>>> does
>>>>>>> this, but I am not familiar enough with current OSX APIs for event
>>>>>>> capture or drivers under OSX to or the state of work in LC9.0 on
>>>>>>> integrating OS API calls to say for sure.
>>>>>>>
>>>>>>> You are unlikely to be able to do what you want in LiveCode script
>>>>>>> alone.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> use-livecode mailing list
>>>>>>> use-livecode@lists.runrev.com
>>>>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>>>>> subscription preferences:
>>>>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>
>>>>>> use-livecode mailing list
>>>>>> use-livecode@lists.runrev.com
>>>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>>>> subscription preferences:
>>>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>>>>
>>>>>> _______________________________________________
>>>>> use-livecode mailing list
>>>>> use-livecode@lists.runrev.com
>>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>>> subscription preferences:
>>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>>>
>>>>> _______________________________________________
>>>> use-livecode mailing list
>>>> use-livecode@lists.runrev.com
>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>> subscription preferences:
>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>>
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>
>>
>
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
