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