Bug 561 - Feature request: Custom commands to be run on different events
Status:
REOPENED
Component:
Core
Version:
unspecified
Hardware:
All All
Importance:
P4 enhancement
Target Milestone:
---
Assignee:
Rob Caelers
URL:
Depends on:
Blocks:
Reported:
Oct 3 2006 12:36:32 UTC
by:
Fredrik Wollsen (Motin)
Modified:
Oct 28 2009 22:14:08 UTC
CC List:
alesmuc
Ray Satiro
WhoWhenWhatRemovedAdded
Rob CaelersAug 27 2007 14:03:59 UTCpriorityP2P4
Rob CaelersMar 11 2008 20:45:07 UTCresolutionFIXED
statusNEWRESOLVED
Kees-Jan DijkzeulOct 9 2009 11:08:16 UTCstatusRESOLVEDREOPENED
resolutionFIXED
ccRay Satiro
Kees-Jan DijkzeulOct 28 2009 20:51:00 UTCccalesmuc
Description
Fredrik Wollsen (Motin)  Oct 3 2006 12:36:32 UTC
I would really like to be able to run custom events on the different workrave events such as starting working-day, initiating forced break, start of manual break, end of micropause etc, but has not seen this possibility in neither http://www.workrave.org/features/ or man workrave. 

I would use it amongst other things to take screenshots of current progress, autosave current document (in case battery would drop during the pause!) and initiate backup-commands to be run while issuing the breaks. 

Seems very useful to me and shouldn't be timeconsuming to implement. When can we look forward to this you think?

Cheers!
Comment 1
Rob Caelers  Mar 11 2008 20:45:07 UTC
Workrave now supports events through dbus. At the moment only break events. More events can be added if there is demand. Example:

obj = bus.get_object("org.workrave.Workrave", "/org/workrave/Workrave/Core")
workrave = dbus.Interface(obj, "org.workrave.CoreInterface")
workrave.connect_to_signal("MicrobreakChanged", microbreak_signal)

def microbreak_signal(self, progress):
  if progress == "prelude":
     print "Micro break warning"
  elif progress == "break":
     print "Micro break started"
  elif progress == "none":
     print "Micro break idle"
  else:
     print "Unknown progress for: %s" % progress
Comment 2
Kees-Jan Dijkzeul  Oct 9 2009 11:08:16 UTC
I've got a request via e-mail, to have this exact same feature available on windows.

Ray, this sounds like it might be your expertise?
Comment 3
Ray Satiro  Oct 13 2009 05:35:22 UTC
Thanks for your e-mail Kees-Jan. Here's some of Babak's e-mail that you quoted:

> "The ability to run a file (exe,mp3,etc...) when the computer is locked for 
> rest and when it's back."
>
> With this feature there will be lots and lots of new things and we can do 
> with Workrave.
> personally, I'd choose to play a music when the computer is locked...
> AND ALSO, Turn-Off-Monitor.exe for when it's locked
> and Turn-On-Monitor.exe for when it's back....
>
> Please reply,
> thanks in advance

Workrave 1.9.0 crashes when attempting to play MP3s in Windows. Wow, I never even thought to test that! The command idea however is much more broad. In terms of priority there are some more important items/bugs on my Workrave list. And I don't know that it's worth writing if it's unlikely to be included in a release.

My initial thoughts:

What if I changed the 'Sounds' tab to the 'Events' tab, or Sounds/Events, something like that, and for each event in addition to playing a sound a file could be executed? Or no change to the GUI, (which would kind of defeat the point, or would it?), and Workrave would auto-detect and the user could choose say, a .bat file instead of a .wav, to execute or play, respectively. 

So basically everything could look the same, but if a user selected a .bat or .exe file Workrave would know that it should execute that file on event and not play media. Although I think most users would will want sound even if executing a script.

comments?
Comment 4
Kees-Jan Dijkzeul  Oct 28 2009 20:51:00 UTC
*** Bug 869 has been marked as a duplicate of this bug. ***
Comment 5
Kees-Jan Dijkzeul  Oct 28 2009 21:06:26 UTC
In your proposal, I'd have to choose between either a sound or an app, but not both (unless I program the app to play the sound instead of workrave). I think I'd like to have both. (That is, if I were interested in being able to execute commands :-)

Also, I'd not be happy if the UI secretly allowed you to select apps instead of sounds, without making it obvious to the user.

On a whole different line of thought: On linux events are broadcast using dbus. Isn't there a similar technology on Windows we could use? I am very much behind the times when it comes to Windows, but in the old days, I guess I'd register a COM component with some specific interface, and have workrave search for all components publishing said interface and send events to them.

As an end result, I'd have a sequence of events being broadcast to a single application (possibly written in Visual Basic or C# or something), allowing me to do some fancy logging or analysis. Maybe couple it to our companies time-writing or hour-tracking system or something. Having just the ability to start some app is of very limited use.

Just my ƒ0.05
Comment 6
Ray Satiro  Oct 28 2009 22:14:08 UTC
Yup there's DBUS functionality for Workrave Windows, all credit to Rob. Personally I don't use it and actually the test builds of Workrave I work with are missing DBUS. The ideas are intriguing though.

As far as you not being happy with the UI not changing at all for an enhancement like this, I can relate. At one point there was an Advanced Preferences panel proposed (ie Timers, User Interface, Networking, *Advanced*) but Rob and Raymond decided it would not be implemented in the UI -- although some changes we made live on in the backend. The reason for this (if I remember correctly) is they want Workrave to be as simple as possible. Getting approval for an "advanced" feature for the UI is unlikely (Rob can weigh in here).

If any change is forthcoming here it would probably be in the backend. We could continue to expand the advanced key and check for commands to take place at the time of an event, something simple like (assuming Windows & registry keys here):
HKCU\Software\Workrave\advanced\events
"MicroBreakStarted"="C:\\whatever.bat"

However we now again have something that would not be used by 99.9% of users, but could help that .1% (still significant; probably mostly admins and hackers). According to Rob's comment from 2008, in this specific case DBUS already covers events like this. Perhaps it's not asking too much to have the (advanced) user work with DBUS here? Or do you guys think it should be implemented in Workrave?