For local folders, it would be convenient to have the automatic mail check interval specified in seconds. For example , I run "fetchmail --idle" as a background process, and would like to not wait ~30s on average to be notified of a new message. Of course, it would be even better if Claws Mail watched mbox using inotify, and if "scan_all_after_inc" (update all local folders after checking for new mail) used the same mechanism at least for Inbox. That way, individual email messages could be delivered directly into Claws' MH Inbox by an external program, circumventing the whole mail checking mechanism.
Created attachment 1666 [details] Possible fix for this and Debian bug #712758 Apply with 'git am 0001-Fix-bug-2176-autochk_interval-granularity-is-low.patch'
Wouldn't it be better to only store the value in seconds? It can get calculated into hours and minutes when it needs to be displayed in the UI.
(In reply to comment #2) > Wouldn't it be better to only store the value in seconds? It can get > calculated into hours and minutes when it needs to be displayed in the UI. Probably, but that needs migration code not to lose configuration of current users, which also needs some testing to ensure correct migration. I took the lazy way: no migration code as minutes before are still minutes after upgrading, simpler widget management and just a minimal CPU overhead when calculating time. The other option is to just require all users to reconfigure their settings, but that looks even less desirable than migration code to me :)
Or just introduce new preference to store the value in seconds, and treat the current one as obsolete - prioritize its value (and convert to seconds) if it's found in config, but never write it to config. BTW, this could all have been easier if we adopted config versioning, like I suggested few years ago. :)
(In reply to comment #4) > Or just introduce new preference to store the value in seconds, and treat > the current one as obsolete - prioritize its value (and convert to seconds) > if it's found in config, but never write it to config. That's "migration code" explained, yeah :-) > BTW, this could all have been easier if we adopted config versioning, like I > suggested few years ago. :) Agreed completely. Not sure what has prevented config versioning from being adopted though.
(In reply to comment #4) > Or just introduce new preference to store the value in seconds, and treat > the current one as obsolete - prioritize its value (and convert to seconds) > if it's found in config, but never write it to config. To avoid leaving obsolete prefs behind, what about keeping current preference but with a new format hh:mm:ss (string): * on reading pref: - if just a number is found it's assumed to be minutes (nobody has to touch their configs) and converted to seconds internally - if hh:mm:ss is found, its converted to seconds * on saving pref: - it's saved as hh:mm:ss from internal seconds value This has a side effect of having also a human readable format in clawsrc :-)
Created attachment 1667 [details] Possible fix for this and Debian bug #712758 (v2) Re-implementation of fix using the existing preference but changing its meaning to seconds.
Created attachment 1668 [details] Possible fix for this and Debian bug #712758 (v3) Modified implementation taking advantage of config versioning.
I thought case 1 should come after case 0 in a switch(), not before, and the indentation inside case 1 code looks a bit iffy (mixed tabs and spaces), but apart from that, the patch looks good to me (and works well). :)
(In reply to comment #9) > I thought case 1 should come after case 0 in a switch(), not before, and the > indentation inside case 1 code looks a bit iffy (mixed tabs and spaces), but > apart from that, the patch looks good to me (and works well). :) Oops, I hadn't realized of the inverse order. For some reason I saw it like a stack of changes and seemed natural to put new versions on top of older, but no problem in reversing it and fixing indentation.
Changes related to this bug have been committed. Please check latest Git and update the bug accordingly. You can also get the patch from: http://git.claws-mail.org/ ++ ChangeLog 2016-07-23 03:04:02.908407091 +0200 http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=f6b41c373f554fc2e5ce8185f16946b2bb256a65 Merge: 4e79761 72a45f9 Author: Colin Leroy <colin@colino.net> Date: Sat Jul 23 03:04:02 2016 +0200 Merge branch 'master' of file:///home/git/claws http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=72a45f97e63a1f8f19adef80dc197a917207f7e1 Author: Ricardo Mones <ricardo@mones.org> Date: Sat Jul 23 03:00:00 2016 +0200 Update copyright headers for previous commit http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=bc779dcb02bc8bc8653dfc5201dcfecc457bd971 Author: Ricardo Mones <ricardo@mones.org> Date: Sat Jul 23 02:59:21 2016 +0200 Fix bug #2176: autochk_interval granularity is low This also fixes Debian bug “Please increase mail auto check period.” See: https://bugs.debian.org/712758 Former bug wanted sub-minute granularity and latter the opposite: just check a few times a day, so this allows user to specify also hours and seconds in addition to existing minutes to address both requests. Checking range was from 1 minute to 1 hour 40 minutes and now is extended to a range from 10 seconds to 100 hours minus one second. Default for new configurations is preserved (10 minutes). Configuration version is raised to 2 for migrating existing values from minutes to seconds.