topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Thursday December 12, 2024, 11:58 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: IDEA: The human interrupt - say goodbye to human polling  (Read 5546 times)

insert_nick

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 76
    • View Profile
    • @insert_nick
    • Donate to Member
IDEA: The human interrupt - say goodbye to human polling
« on: August 28, 2006, 09:43 AM »
Hi to all there! This is an idea I had years ago, I've sometimes searched for an app like this because I'd like to have and use it a lot, but still no luck, I don't know if it exists btw I can't find it.

Really, I think this is an app that could potentially grow big so it would need some more development efforts than "one hour" of work I suspect ;)  Btw, I think the "core features" could be coded in a small amount of time by someone who knows how to take a map of the screen (something like a screenshot program). Maybe it's possible to make everything described here with AutoHotKey, but I've discovered it just yesterday so I'm not able to do it by now.

So let me try to explain the idea, then the app. Lot of times I'm there waiting for my PC to have a job done, or I simply would like to catch an event, and usually I have to use my eyes, even if I'd like to look elsewhere, or even turn the monitor off... I call it the damn human polling, something that imho should be reduced as much as possible, cause we "multitasking users" like to do lots of other stuff away from the PC when it's working for us, especially when it wants not to be disturbed to complete the work well. This is why interrupts have been invented, but still we have not a good and uniform system for human interrupts while using a PC: it is definitely something that should be hardcoded in the OS.

Meanwhile, waiting for an OS with this hardcoded, why not anticipate the times? ;)  Think to a system trayed app, which can be enabled/disabled. It lets the user define "interrupts", and "actions". When defining a new interrupt, there are some "primitives" that can be used, and logic operators. The most useful primitive for me (and this is what I'd like in the very first implementation of the app, if it should not grow in future, otherwise it will be useless for me) would be "look for event in desktop area": it would let the user define an area of the desktop with the mouse (the entire desktop being the biggest "area", and a single pixel being the smallest one... and in case of use of multiple desktops, it would be nice to support monitoring them too, but this is feed for advanced implementations!), then the user should define the "event" to look for, choosing e.g. between:
  • changes
  • becomes...
  • includes...
  • includes color...
  • (...other eventual ideas)
Choosing "changes", the app will look for whatever pixel change into the defined area; choosing "becomes...", the user have to also submit an image (or a color, if the defined area is just one pixel) for the app to confront with; choosing "includes color..." the user have to also submit a color for the app to look for its presence in the defined area; etc.

Another useful "primitive" would be "look for text in desktop": it would let the user define a word or a group of words, for the app triggering when the same text is found somewhere in the desktop. As a sample text, think something like "completed" or "100%" or "done" ;)

Another *very useful* one would be "look for window caption", so that we can trigger our app using the features of other apps like AutoIt2 or AutoHotKey, we let them trigger on the desired event not implemented in our app, and make them pop a window with the caption we've defined, so that a big amount of already implemented "primitives" is ready to serve the user ;)))

Ok, that's enough for primitives, of course there are lots of them we can invent, btw I think you've caught the concept by now.
It's important the "logic operators" implementation to bind multiple primitives: that is, the interrupt can trigger for example when the primitive "look for event in desktop area" OR "look for text in desktop" triggers; of course there will be AND, OR, NOT operators.

Then, the "actions": simply let the user define something to do; defining actions, they can be associated with interrupts. E.g. an action could be "execute program" (and the user will specify a path and parameters for the application to run), or "play sound file", or (really important for me, because I often have my speakers off) "play sound with PC speaker (beeper)", or "say...." (and the user specifies a text to read with voice synthesis), etc.

Moreover, the app should let the user define a label for every entry (interrupt + action), and it should be possible to load the app with a label as parameter: this way, an AutoHotKey script could detect that I'm burning a DVD, and automatically call the app passing the label parameter "scream_when_burned".

Good, I hope everything's clear. Let me summarize with an example setup:

  • entry "scream_when_render_completed":
    interrupt "progress bar reaches the end" = primitive "look for event in desktop area"
    action "play sound file"
    check frequency: "every minute"
  • entry "beep_when_burning_finished":
    interrupt "burning program has done is job" = primitive "look for event in desktop area" OR primitive "look for text in desktop"
    action "irritatingly beep with PC speaker until mousemove or keypress"
    check frequency: "every 5 seconds"
  • ...

You see, we can define as much "entries" as we want in the app, with corresponding one-word "labels"; each one is an "interrupt"-"action" pair, where an interrupt is defined as a group of primitives bound through logical operators, with every primitive having parameters defined by the user; every interrupt has a multi-word label, so that they can be reused for other entries; actions have a multi-word label too, so that they can be defined and reused at pleasure. I've specified "check frequency" values for each entry, because e.g. it would be unwise to check every microsecond if the render has been completed, maybe it would slow down the render itself! Or e.g. it would be useless to check every minute for a task which completes in about a minute; so it's clear that each entry must have a corresponding user-defined check frequency.

I hope someone finds this idea interesting to implement, as I'd like to leave my PC doing its time-consuming tasks while I'm playing with my brother in another room and set loud horns to call me when the job's done and my PC is ready to go with other tasks. Or I'd like it to automatically turn off when it completes a big rendering, because I'm sleeping deep in my bed and there's no option in my rendering program, and the only thing changing in the screen when it completes is the progress bar reaching the end...


-- EDIT: A complete app would be very appetible if provides integrated tools for easying the process of interrupt definition as much as possible, almost "on the fly". Mainly, the primitives involving detection of graphics or texts in the desktop (changes, inclusions, coincidences, etc.) should have aid tools. I think to this process, e.g. for a CD burning job:
  • the user starts the burning with his favourite program
  • from the system trayed app, he launches the menu entry capture the no-trigger situation ("still working")
  • the app internally saves a dump of the words found in the desktop: something like a AutoHotKey's "window spy", done on every window of the desktop
  • the app lets the user define a rectangular region on the desktop with the mouse, and saves a dump image of the chosen region (and tooltips could hint the user on how to choose the region selection, and to try taking it as small as possible)
  • the app saves a dump image of the entire desktop
  • the user waits for the burning job to complete and go on "steady state", then from the system trayed app he launches the menu entry capture the trigger situation ("job done!")
  • the app again internally saves a dump of the words found in the desktop
  • the app saves another dump image of the the previously user-defined region
  • the app saves another dump image of the entire desktop

Having this done, the app can provide some sort of "diff" of the two text dumps, and a ready-to-use couple of images dumping the interesting areas, for the definition of the primitives; e.g. the user could set a primitive to search in the screen for the first region image (so there will be no fixed position for the area to watch), then watch the region in the found position and compare it with the second region image.

The more precise of you there maybe have noticed I've included also a "the app saves a dump image of the entire desktop" in the list, and again after the job's done situation; these dumps have no meaning it seems, as the user defines a specific region... but here it is why I've included them: the app could provide a "simulate!" feature; that is, after the user has defined everything, he could roughly try if everything should go well just executing a very quick simulation. It could be accomplished making the app show the first desktop dump image during a defined time window, followed by the second desktop dump image during another time window, and redirecting every text check to the text dumps rather than the real desktop entities, of course using the first text dump during the first time window and the second text dump during the second time window.

Maybe it seems a bit twisted to read now, but I have a clear idea that everything would be neat and easy to use for everyone if well implemeted. But, as previously anticipated, I'm convinced that this is not really a "coding snack", so if there is a more appropriate section in this forum where to post it, please let me know and excuse me, I'm really new there. Bye!
« Last Edit: August 30, 2006, 05:08 AM by insert_nick »

nudone

  • Cody's Creator
  • Columnist
  • Joined in 2005
  • ***
  • Posts: 4,119
    • View Profile
    • Donate to Member
Re: IDEA: The human interrupt - say goodbye to human polling
« Reply #1 on: August 28, 2006, 10:21 AM »
nice idea. should be relatively simple to implement with autohotkey i would think but i'm not the person to do it.

check out skrommel's 'pixelnotifier' autohotkey script to see a cut down version of what you are asking for. here's the link and scroll down the page https://www.donation...0;topicseen#msg34726

you could perhaps achieve the same results by using a program that monitors an applications cpu usage - i've got one somewhere but i can't remember the name of it at the moment.

(welcome to the forum by the way.)

insert_nick

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 76
    • View Profile
    • @insert_nick
    • Donate to Member
Re: IDEA: The human interrupt - say goodbye to human polling
« Reply #2 on: August 28, 2006, 10:50 AM »
Great! PixelNotifier and ProcessGuard scripts by Skrommel are very useful for my purposes! Thank you very much for the suggestion, now I've a way to roughly accomplish what I described. Anyway, the complete utility described in the post would be far more usable.

So I was right feeling this was a nice a place...

(welcome to the forum by the way.)

Thanks, bye!

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,914
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: IDEA: The human interrupt - say goodbye to human polling
« Reply #3 on: August 28, 2006, 11:01 AM »
yep, i also think this is a nice idea.

insert_nick

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 76
    • View Profile
    • @insert_nick
    • Donate to Member
Re: IDEA: The human interrupt - say goodbye to human polling
« Reply #4 on: August 30, 2006, 05:06 AM »
I've just added another (interesting?) section to the description of the idea, after the horizontal rule.