Meta Refresh Prefrence on Main Page?
I'd love to see the ability to set a META HTTP-EQUIV=REFRESH value on the main page. It's necessary, in my opinion, now that we have an API that allows users to add new tasks via interfaces other than the web page itself. For instance, if I add a few new things via a Quicksilver command, and then later return to my main Tracks page, which has been sitting in the background somewhere, those new items won't be visible until I refresh the page. As a result, I sometimes forget that such items are there for quite a while. But if the page refreshed itself automatically at some pre-set interval, such items would eventually show back up.
I see this as being implemented by a new preference. By default, the refresh would be set to '0,' which would mean not to include a refresh tag on the main page. A user could enter a numeric value equal to the number of minutes between refreshes. (When implementing the tag, this numeric value would have to be multiplied by 60, as the refresh tag counts in seconds rather than minutes.)
I see this as being implemented by a new preference. By default, the refresh would be set to '0,' which would mean not to include a refresh tag on the main page. A user could enter a numeric value equal to the number of minutes between refreshes. (When implementing the tag, this numeric value would have to be multiplied by 60, as the refresh tag counts in seconds rather than minutes.)
Leave a comment
I worry a little about this approach. What if you're in the middle of filling in a new action form when the refresh hits? Also, what happens to any flash messages that have been shown? It seems that a javascript that can set timeout on idle might be a better implementation.
I stupidly hadn't thought about that. Since I'm rubbish at javascript, can I assign it to you? At least the user.preferences part of it is done, at least ;-). And the default is zero, so people updating the trunk won't see any difference in behaviour by default.
Perhaps it could also be done by using a periodically_call_remote?
Perhaps it could also be done by using a periodically_call_remote?
Migrated to GitHub issue #295