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
