I doubt you've had time to think about the issues of using pupRadio with Pscheduler as yet, but before you do, and get too deeply into a pupRadio-interface-to-Pscheduler design based on how Pscheduler currently works interface-wise, I thought I should let you know of a possible minor modification to the latter, which would probably help you produce a better commandline compatible extension to pupRadio.
First of all, it was pupRadio that actually made me think about using Pscheduler, and really I stuck a button for the latter into Precord with that in mind (so I've been planning to nudge you in this direction for 'ages'...:-)
I expect that most people never or hardly ever use Pscheduler, which is a great pity, because it is a very useful application. I have read of a few people who have used it to make it play an audio file to wake them up in the morning, but of course pupRadio with Pscheduler would give all that and more...
I've actually found Precord with Pscheduler quite fun to play with, except that it is dangerous!... I forgot I had scheduled Precord to start recording at a specific time in the evening, and later in the day I discovered Precord had been running in the background (completely invisible since commandline started) recording my every movements for several hours...
But, yes, it also occurred to me that I don't 'just' want to use Pscheduler/Precord to snoop on myself... or anyone else for that matter, but what was missing in the possibilities was... pupRadio...
However, once you look at the way Pschedule works, you will notice that once you press "Add task", for a new task, you are taken to a new dialog in which you need to manually enter the program to be run and to manually supply an optional name for the new task. The problem is the "manually" part... To interface nicely with Precord, pupRadio, or any other program (rather than a human) it would be really nice if Pschedule allowed such programs to send these details as parameters - but Pschedule doesn't have that facility at the moment...
The fact that you come to the Add task, Edit, Delete, Run GUI isn't an issue, In fact, I feel that that is a good arrangement, since it allows you to immediately manage existing tasks prior to activating your new one. But when you then press the Add task button (having got to the first Pschedule GUI from pupRadio or Precord) it is painful to have to then manually have to enter the stuff I mentioned, when your program could have that all prepared already for entry. Yes, cut and paste would work, but that would be an untidy workaround. However, there is light on that horizon...
I have discovered that it is an entirely trivial matter to give Pschedule the ability to read the "Command" and the "Task name (optional)" from the command line. In fact I now use a specially modified Pschedule myself for exactly that. Fortunately, none of the major functions of Pschedule care at all really about anything being added as command line parameters so the modification is simple and consists of only:
one additional line to the main program /usr/local/pschedule/pschedule
one small alteration to another line of that program (to pass the parameters onwards)
and then,
minor alterations to two lines in the pschedule function program /usr/local/pschedule/func_new
I'll contact Zigbert about it to see if he would put these changes into his official code base; small though these additions are, they make a huge difference to the functionality of Pschedule when it comes to using it with apps like ours. And Pschedule is potentially a very useful core application, so such an addition would be very valuable (as we are both showing...;-)
In case you want to try the Pschedule mod yourself, here are the simple details - assuming you activate line numbers in Geany or your favourite text editor... i.e. Geany -> Edit -> Preferences -> Editor -> Display -> Turn on line numbers (it took me ages to find that!...):
In /usr/local/pschedule/pschedule:
insert a new line 20 containing:
Modify line 104 (within BUTTON_ADD) from:
Code: Select all
<action>. $PROGPATH/func_new</action>
to:
<action>. $PROGPATH/func_new \"$TASK\" \"$TASKNAME\"</action>
----------------------------------------
In /usr/local/pschedule/func_new:
Modify line 2 from:
Code: Select all
MODE="$1"
to:
MODE="$1"; TASKNAME="$2"
and also in func_new, modify line 52 from:
Code: Select all
if [ "$MODE" != "-edit" ]; then TASK='gxmessage "Happy Puppy"'; TASKNAME='Please enter the task name"'; fi #jake_take
to:
if [ "$MODE" != "-edit" ]; then "TASK"="$TASK"; "TASKNAME"="$TASKNAME"; fi #jake_take
Now, I can start Pschedule, from the commandline (or later version of Precord) with the likes of:
Code: Select all
pschedule "precord rec out.mp3" "Record file task"
i.e. in the form:
pschedule Command [Task Name]
so as soon as I then press "Add task" these two essential details are automatically then filled in. I think that is what you (and I certainly) probably want rather than having to enter such details manually or with cut and paste?
I could supply a diff, but the changes are so simple, and if Zigbert is willing to make these simple mods it would probably be easier and best, in terms of checking/testing, that he just adds them manually to his original code.
I haven't tested these mods thoroughly yet, but on reading the code they seem to have no effect on anything else; they just add the new functionality, quickly and easily. The reason the change is so minor is that the existing MODE variable only really matters when it is "Edit" mode, and the above changes are only concerned with "Add task" mode.
Anyway, I'll wait on your comments before bringing the matter up with Zigbert in case you have some extra desires or thoughts that would be easily catered for (now or in the future). I doubt it would be easy to modify Pschedule for anything much more, however, and from my point of view the rest of the app is just perfect for my purposes anyway.
)