Detect scroll activity (when LC is not frontmost)

Richmond Mathewson richmondmathewson at gmail.com
Sun Dec 25 12:27:53 EST 2016 

Aha!

On 12/25/16 7:19 pm, Mike Bonner wrote:
> 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 <bonnmike at 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 <bonnmike at 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 <
>>> richmondmathewson at 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 <
>>>>> richmondmathewson at 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 <paul at 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 at 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 at 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 at 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 at 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 at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

More information about the use-livecode mailing list