Quote:
Originally Posted by DuckieTigger
In your ntpdate.sh, after moving the logfile to /mnt/us/documents/ntpdate.txt, why not opening that file so you can look at it? Like this (in red) in ntpdate.sh:
Code:
****snipsnip****
if [ x$RPT == 'xtrue' ]
then
mv $LOG /mnt/us/documents/ntpdate.txt
dbus-send --system /default com.lab126.powerd.resuming int32:1
lipc-set-prop com.lab126.appmgrd start \
app://com.lab126.booklet.reader/mnt/us/documents/ntpdate.txt
else
rm $LOG
fi
exit 0
Just tested it and it works - it will open up the logfile to look at it. Another idea to improve might be to have the logfile NOT in /mnt/us/documents, so that the indexer does not have to worry about it. Maybe have it in /mnt/us/opt/log/ntpdate.txt and add a KUAL button to:
lipc-set-prop com.lab126.appmgrd start app://com.lab126.booklet.reader/mnt/us/opt/log/ntpdate.txt
(not sure if that works in the menu.json directly, or if you have to wrap it around another shell script)
|
It is a though to keep in mind.
But I was assuming that people would do one of two things:
1) Read it and keep it (somewhere) for a "most recently set" record.
2) Just delete it.
And now with four time server addresses (ntpdate uses all that it can reach of the four, and then computes the 'best' of those) - -
And the last one of those the 'global' pool - -
The button should succeed more often that not. (a lot more often)
Anywhere in the world.
Once the end-user has acquired some confidence that the button works in their location - -
Then they can decide if they want the success record or not.
If they disable the success record, then the only time a report will be made is on a failure of some sort.
So far - we have had only a couple of dozen downloads - and only one report on if the button works (from twobob).
But still that is a thought to keep in mind.
Just need a bit bigger sample of user opinions now.
PS: Yes, any single line (including multiple statements) shell command will work in the "action" : field of menu.json .