And, likewise:
<https://www.facebook.com/#>
I hope everyone can find their moment of peace and tranquility, whatever
their views on religion.
Richmond.
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 <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
_______________________________________________
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
