Bug 2552 - in automatic checking, enable the use of different time intervals
Summary: in automatic checking, enable the use of different time intervals
Status: RESOLVED FIXED
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Other (show other bugs)
Version: 3.8.0
Hardware: PC Linux
: P3 enhancement
Assignee: users
URL:
: 2139 4004 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-11-25 18:54 UTC by Yed
Modified: 2018-07-14 09:25 UTC (History)
5 users (show)

See Also:


Attachments
patch (9.44 KB, patch)
2011-11-25 18:54 UTC, Yed
no flags Details | Diff
Patch version 2 (10.27 KB, patch)
2012-07-29 11:10 UTC, Yed
no flags Details | Diff
Patch version 3 (10.60 KB, patch)
2012-08-04 17:54 UTC, Yed
no flags Details | Diff
Patch version 4 (5.21 KB, application/octet-stream)
2012-09-01 11:05 UTC, Yed
no flags Details
Patch version 5 (13.70 KB, patch)
2013-05-14 19:17 UTC, Yed
no flags Details | Diff
Patch version 5.1 (13.75 KB, patch)
2013-05-14 19:58 UTC, Yed
no flags Details | Diff
Patch version 5.2 (13.75 KB, patch)
2013-05-15 09:26 UTC, Yed
no flags Details | Diff
Patch version 5.3 (19.42 KB, patch)
2013-08-06 12:43 UTC, Yed
no flags Details | Diff
Updated patch version 5.3 (18.51 KB, patch)
2016-08-28 21:58 UTC, rezso
no flags Details | Diff
Fixed updated patch (18.50 KB, patch)
2016-08-29 00:07 UTC, rezso
no flags Details | Diff

Description Yed 2011-11-25 18:54:37 UTC
Created attachment 1043 [details]
patch

When automatic checking is enabled, the time interval is a global one.
This request is to enable a custom time interval for each account, since all the configured accounts may not have the same importance.

I join a patch that do the following:
 - add a time setting in the page 'receive' of the account preferences;
 - set timers by accounts if they are requested, otherwise use the global one.

I did some tests and it seems ok.
If you agree to integrate it, I would like to enhance it (for instance, the case of a custom command for fetching mail is not considered in the current patch).

Regards,
Yed.
Comment 1 Yed 2012-07-29 11:10:55 UTC
Created attachment 1138 [details]
Patch version 2

Update: patch version 2
Comment 2 Yed 2012-07-29 11:13:41 UTC
Adding the patch version 2.

The accounts using a specific time interval was not first checked at startup, 
but only after the time interval.

Thanks to P
Comment 3 Ricardo Mones 2012-08-02 07:42:08 UTC
Some quick notes from reading the patch:

* The 'usespecfrq' member has an ugly name ;-) and, more important, is not required: an empty value in time_lapse should stand for "use the global setting".

* That should be also the default time_lapse value, not "10".

* All cases of incorporations or kinds of accounts should be considered
Comment 4 Yed 2012-08-02 09:46:40 UTC
> * The 'usespecfrq' member has an ugly name ;-) and, more important, is not
> required: an empty value in time_lapse should stand for "use the global
> setting".
This name is not *that* ugly... :'(
I used it temporarily, waiting to find something more appropriate, and in the end it is still here.
I want to keep a non-zero time lapse, so we can easily switch between the two modes without having to reset the time lapse.

> * That should be also the default time_lapse value, not "10".
I can't remember why I choose this value, but it looks fair for me.

> * All cases of incorporations or kinds of accounts should be considered
Well, I don't get this point... The specific time is available to all the accounts, isn't it?
Comment 5 Abhay S. Kushwaha 2012-08-02 11:34:03 UTC
Yed, what Ricardo is saying is:

1. Don't use usespecfrq at all.

2. Use only time_lapse. If time_lapse is "0" or "empty" it means the global figure for the application, as defined in Preferences -> Mail Handling -> Receiving -> Automatic Checking should be used.

3. This also means that you don't need to set a default value to time_lapse (you have set it to 10) since an empty value means the global "automatic checking" time value applies.

4. So in other words, you set time_lapse to be non-empty or non-zero only when you want to over-ride the global preference and make a particular account check for email at a specific interval.

5. I am not sure of Ricardo's comment about other cases of incorporations but I think he means that your patch doesn't seem to address the "External incorporation program". I think you earlier said that custom command for fetching is not yet triggered by your patch at custom interval. So I think he means that.

Hope this helps.

PS: I'm very keen as a user to see this patch incorporated into CM! :)
Comment 6 Yed 2012-08-02 12:04:49 UTC
Thanks Abhay,
but the only unclear point is the last one, and I have answered the others.
Comment 7 Ricardo Mones 2012-08-02 12:58:56 UTC
> I want to keep a non-zero time lapse, so we can easily switch between the two
> modes without having to reset the time lapse.

Yep, already guessed that, but that's overkill. I don't think such preference
requires two widgets when, in a common usage, it's simply set on a few accounts and you're done for ages.

That you (for example) like to play with this option twice a day doesn't mean that all potential users of it are going to do the same, neither that they are going to like to click the checkbox and write the time when they could have been done just with writing the time _exactly_like_ the already existing global preference.

> > * That should be also the default time_lapse value, not "10".
> I can't remember why I choose this value, but it looks fair for me.

The point was that removing the checkbox requires it to be empty for keeping existing configurations working properly.
Comment 8 Yed 2012-08-02 13:39:55 UTC
> That you (for example) like to play with this option twice a day doesn't mean
> that all potential users of it are going to do the same, neither that they are
> going to like to click the checkbox and write the time when they could have
> been done just with writing the time _exactly_like_ the already existing global
> preference.

Maybe I am a weirdo, but I really like to click a checkbox to enable a feature (and I hope I am not the only one).
But I understand your point of vue, and since it is the claws mail way, I will update the patch according to this as soon as possible.
Comment 9 Yed 2012-08-04 17:54:16 UTC
Created attachment 1140 [details]
Patch version 3

Here we go, the changes are:
 - no more checkbox;
 - bugfix: the apply button now apply the changes;
 - fix warning during compilation.

By the way, the global timer uses a checkbox, so there is an inconsistency...
Comment 10 wwp 2012-08-12 15:10:14 UTC
The patch seems to work fine regarding to the per-account interval/delay settings.

But.. (there's often a but) I noticed one issue since I'm running w/ the patch applied: the receive dialog is showing (for both retrievals of accounts that have a specific delay and ones that use the global internal delay), whereas the global prefs say "show receive dialog" "only on manual receiving".

Does anybody reproduce?
Comment 11 Ricardo Mones 2012-08-14 07:24:19 UTC
Yed, thanks for the updated patch.

> By the way, the global timer uses a checkbox, so there is an inconsistency...

Indeed, that could be simplified I guess, and wrongly I thought it was ;) anyway that's a global preference, not an account preference, and probably deserves the checkbox even if it could be implemented without it.

wwp, I think problems with receiving dialog may not be related with this patch.  I'm suffering the opposite, i.e., not seeing the dialog at all, no matter the settings and without any patch applied (cvs32). In fact right now I have "Show receive dialog: Always" and "Close receive dialog when finished" unchecked and yet still no dialog appears when checking all accounts (one local and some IMAP at this box). Really weird.
Comment 12 wwp 2012-08-14 09:29:37 UTC
I see. My observation is probably wrong because, back from vacation, I did a massive update to the CVS HEAD and applied this patch as well.
Here I temporarily set global prefs so that the dialog is never shown, at least *this* works ;-).
Comment 13 wwp 2012-08-23 09:15:02 UTC
I sometimes wonder if we would better completely rework the retrieving-interval  feature in order to allow this per-account thing improvement:
- define a global retrieving interval granularity (say by default: 5min)
- define per-account retrieving interval, as a multiple of the granularity value,
for instance for account A, interval value could be 1 (1x5min=5min interval),
for account B, could be 6 (6x5min=30min).
This would allow slipping globally the interval values by sliding the global granularity instead of modifying by hand all the global and the per-account interval values, when for instance you want to slow down the retrieving interval (when in slow-motion mode, like in vacations or when network traffic is very high).
Comment 14 wwp 2012-08-23 09:18:41 UTC
Of course, to migrate to such rework, when running the new version for 1st time, we should set the global granularity value to 1 and set all accounts to current interval value found in prefs. With such implementation, all accounts would have a default interval value, this would not be a discardable settings.
Comment 15 Ricardo Mones 2012-08-23 10:21:42 UTC
> Of course, to migrate to such rework, when running the new version for 1st
> time, we should set the global granularity value to 1 and set all accounts to
> current interval value found in prefs. With such implementation, all accounts
> would have a default interval value, this would not be a discardable settings.

I like the idea, yep. But unless I understood it wrong, on 1st time run the
global interval should be kept as is and every account multiplier set to 1
(starting from current CVS sources, not from CVS + this bug's patch). I think
that would be easier.

Additionally account multipliers should be settable to 0 in order to disable
periodic check for the account only.
Comment 16 wwp 2012-08-23 10:26:59 UTC
> But unless I understood it wrong, on 1st time run the
> global interval should be kept as is and every account multiplier set to 1
> (starting from current CVS sources, not from CVS + this bug's patch). I think
> that would be easier.

Correct!


> Additionally account multipliers should be settable to 0 in order to disable
periodic check for the account only.

I disagree on that point: you can also disable/enable accounts for retrieval in the accounts dialog. Of course this could be bound to a "set multiplier to 0 in account prefs), but if you set 0 there, you loose the original interval value if you want to enable the account back later. (or I misunderstand your words).
To me the current way to disable/enable accounts is already fine and sufficient.
Comment 17 Ricardo Mones 2012-08-23 10:42:41 UTC
> Additionally account multipliers should be settable to 0 in order to disable
periodic check for the account only.

> I disagree on that point: you can also disable/enable accounts for retrieval
> in the accounts dialog. Of course this could be bound to a "set multiplier
> to 0 in account prefs), but if you set 0 there, you loose the original
> interval value if you want to enable the account back later. (or I misunderstand
> your words).
> To me the current way to disable/enable accounts is already fine and sufficient.

Ah, right, had forgotten about that! Yep, it sounds coherent now. Waiting for the
patch ;-)
Comment 18 Yed 2012-09-01 11:05:44 UTC
Created attachment 1153 [details]
Patch version 4

Sorry for the wait, here the patch.
It is indeed simpler than the previous ones.

By the way, somebody can probably find a better label in the account settings.

Regards,
Yed.
Comment 19 Colin Leroy 2012-09-05 09:15:02 UTC
Hi,

Seems good! Can you just reverse the "if (0 != account->autocheck_counter)", so that they read in the logical way instead of the "I fear I'll assign instead of compare" way? Coding style :)

Also, I'm not sure how to label the pref, "Check for new mail every X times global timer" seems not very clear but I have no better idea... Someone ?
Comment 20 Brian Morrison 2012-09-05 09:42:49 UTC
> Also, I'm not sure how to label the pref, "Check for new mail every X times
> global timer" seems not very clear but I have no better idea... Someone ?

How about:

Reduce mail check frequency by factor of x

or

Increase mail check interval by factor of x

??
Comment 21 Ricardo Mones 2012-09-05 14:03:51 UTC
User A and B have both several accounts.

User A has a global interval check of 10 minutes, wants just an account to be polled every 30 minutes. It would set account times global timer to 3. Right.

User B has global interval check of 60 minutes, wants an account to be polled every 10 minutes. How to do it with this patch?

Both use cases are perfectly valid IMO.
Comment 22 wwp 2012-09-05 14:11:39 UTC
User B is dump, Ricardo! He must set the global granularity value to 10, and 1 in his 10min account. IOW, I don't think user B case is pertinent (or I missed something).
Comment 23 Ricardo Mones 2012-09-05 14:24:15 UTC
And to keep it's current preferences will have to edit every other account setting 6 on the acount times.

And every time B adds an account has to remember to set it to 6, otherwise it will be polled every 10m. Remember B _wants_ a global poll every 60 minutes, it's just an account that's different. How do you explain him that he has to put 10 in global preference and 6 on every  other account just because wants one with a higher frequency?

Account times should be able to divide main frequency as well as it's able to multiply for covering B cases.
Comment 24 Yed 2012-09-05 14:54:00 UTC
We cannot divide the global timer or we lost the benefits of the granulosity to go back to the case of one timer by account.

As you said before, the account configuration is done only once, so it is not really a pain for user B, he just has to play with the settings one time.

It will help if we could add the global timer value in the label, so user B will not have to remember/look for it.
Comment 25 Ricardo Mones 2012-09-05 15:13:39 UTC
> We cannot divide the global timer or we lost the benefits of the granulosity
> to go back to the case of one timer by account.

No, it's just more difficult to calculate, which makes it a bit harder to implement, but if decimals are allowed you still only need one control to allow both behaviours, and may set almost any frequency (rounded to the minute anyway).

> As you said before, the account configuration is done only once, so it is not
> really a pain for user B, he just has to play with the settings one time.

The problem is that for user B the 'special account' frequency is conditioning the global setting, and forever, as she has to remember that on every new account. That's pretty counter-intuitive.

> It will help if we could add the global timer value in the label, so user B
> will not have to remember/look for it.

In that case would be better to put the final calculated frequency so the user doesn't need to do the math.
Comment 26 Abhay S. Kushwaha 2012-09-06 05:32:57 UTC
This "calculated to x times of global value" interval for checking emails isn't every intuitive.

1. It is difficult to understand compared to a simple method: "Check mail every X minutes for all accounts and for those accounts where you want it different, go in and set unique values." In the proposed implementation, the latter is modified to "go and set a multiple of a value set somewhere else".

2. It is not intuitive. I want to check all accounts every 10 minutes but one account only every 15 minutes. As of now, not possible without changing the global to "5" and then modifying all accounts.

3. It is not "faster for some accounts" compatible. Like Mones pointed out. In my case, I would check all accounts every 10 or 15 minutes but 1 account every 5 minutes and an urgent one every 1 minute if possible. Again, I would have to change the global to "1" and then re-set all accounts to actual values. And if I suddenly decide I want to check all accounts every 30 minutes without changing the frequency of the account I'm checking every minute, I have to go and change all accounts all over again!

4. One has to know maths to use it. Contrary to popular opinion of those involved in the discussion, many people don't know how to multiply, or are weak at it, or would prefer not to do it anyway. Forcing people to 'calculate' a multiple is too much work and a bad design decision.

Plus, a question... does this patch re-set the timers when mail is received manually?
Comment 27 Abhay S. Kushwaha 2013-01-03 19:46:06 UTC
Hey Yed, I hope you've not given up on this. :)
Comment 28 Yed 2013-01-04 11:46:10 UTC
Thanks Abhay :)
I have not given up (not yet), but (sadly) reaching the last goal is not a priority for the moment.
I hope I will be back on this soon, but everyone can contribute :).

And happy new year !
Regards,
Yed.
Comment 29 Ricardo Mones 2013-04-02 15:54:14 UTC
*** Bug 2139 has been marked as a duplicate of this bug. ***
Comment 30 swbraun 2013-04-02 17:41:57 UTC
Please reconsider for this patch what Abhay said.
I'm a simple user who is able to do maths and the multiplication of two numbers is no problem for me, but I don't want something like "mail check time intervals" to become a science.
Having to reconsider the global time "base" everytime I set a new per account time and having to remember that I will change ALL per account time, when I change the global pref is simply NOT userfriendly. I don't do these things very often but when I do it, I want it to be easy to use and do what I want it to do.
Having these "multiply sliders" makes this simple feature very complex but makes it hard to apply a real custom setup.
For example I want a 10 min default, I have one important account I want to check every 3 mins, and then there is one freemail account, that only lets you check your mails every 15 mins, but is not too reliable in that so I make is safe and want to check it every 16 mins. Can you explain me why I should use a global check interval of 1 minute and set ALL my default accounts to "10 x global" to achieve this configuration? Sorry, but this makes no sense and is super counter intuitive.
Please go back to the original idea to set independent values for the global and the per account values. Thanks! 
swb
Comment 31 Yed 2013-05-14 19:17:50 UTC
Created attachment 1262 [details]
Patch version 5

Hello everyone! 
Better late than never, this is the new version of the patch, designed to make everyone happy.
Here the features:
 - the default settings (autocheck & interval) are the same as the global settings, therefore there is nothing to do in most of the cases;
 - you can set a different time interval for each account using two methods:
   -- the first use the global setting as reference, and multiply it by a float. The interval is floored and indicated, so you do not have to do mathematics yourself;
   -- the second use a specific time, like in the first patch;
 - the 'receive_at_getall' ('Get Mail') boolean is used to enable/disable the automatic checking (it is already the case by the way);
 - the timers are reset after a manual fetch.

It was simpler than I thought. I have not found any bug yet, but the more testers the better.

Regards,
Yed.
Comment 32 Yed 2013-05-14 19:58:04 UTC
Created attachment 1263 [details]
Patch version 5.1

Damn! I forgot to update the timers when you enable/disable an account in the account window.

Regards,
Yed.
Comment 33 Yed 2013-05-15 09:26:56 UTC
Created attachment 1264 [details]
Patch version 5.2

A minor adjustment: the upper value of the timer was a little low (100); now it is set to 100000 (maybe a little high this time).

Regards, 
Yed.
Comment 34 Andrej Kacian 2013-08-05 20:22:37 UTC
Although the patch still applies cleanly to current tip of master branch, I get following compile errors:

account.c:1767:2: warning: data definition has no type or storage class [enabled by default]
account.c:1767:2: warning: type defaults to ‘int’ in declaration of ‘inc_acc_autocheck_timer_set’ [-Wimplicit-int]
account.c:1767:2: warning: parameter names (without types) in function declaration [enabled by default]
account.c:1767:2: error: conflicting types for ‘inc_acc_autocheck_timer_set’
In file included from account.c:46:0:
inc.h:112:6: note: previous declaration of ‘inc_acc_autocheck_timer_set’ was here
account.c: In function ‘password_get’:
account.c:1871:2: warning: comparison between pointer and integer [enabled by default]
make[4]: *** [account.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Comment 35 Yed 2013-08-06 12:43:45 UTC
Created attachment 1286 [details]
Patch version 5.3

Outch! Indeed, it is quite a mess with the last sources... and a real headache to fix, thanks to the minimalist diff provided by cvs @#$!
This version should work with the last git sources. No more cvs, great!

Regards,
Yed.
Comment 36 Yed 2013-08-18 15:07:45 UTC
Is there someone reviewing this patch? I did not have any feedback, it is quite depressing...
Comment 37 Paul 2013-08-18 16:14:33 UTC
At the risk of adding to your depression, in my view this idea is far too convoluted with its relative timers and "multiplicator". Why not just a global setting as we have now, and an account setting. If the account setting is set then use that, else use the global setting.
Comment 38 Paul Rolland 2013-08-18 16:45:14 UTC
I agree. I've just finished applying this version to 3.9.2 (must be done manually), and it's getting complicated. 
The original version was much better IMHO, from a user perspective.

Paul
Comment 39 Yed 2013-08-18 17:05:49 UTC
I personnally use both. The timer hooked to the global setting is useful to easily adjust the frequency for those accounts, depending on the situations. The other one is useful for the accounts which have to be checked whatever the situation, or to easily reduce the frequency of a particular account when its connection is becoming problematic.

There is no complication: the global timer is used by default; if an account has to be treated in a different way, the user has the choice. In the end, the user has a complete control of the frequency checking of its accounts.
Comment 40 wwp 2014-04-29 14:25:04 UTC
I was stuck with an old CVS version of CM, with version 3 of this patch (with which all went fine) for more than one year. Now back to the latest GIT version with patch versio 5.3. I hope we're still looking forward to merge the patch!
Comment 41 rezso 2016-08-28 21:58:22 UTC
Created attachment 1680 [details]
Updated patch version 5.3

Updated patch v5.3 for CM 3.14.
Any chance to add this feature to CM?
Comment 42 rezso 2016-08-29 00:07:37 UTC
Created attachment 1681 [details]
Fixed updated patch
Comment 43 Paul 2016-08-29 08:30:45 UTC
I'm still of the opinion I made in comment #37 - it's far too convoluted.
Comment 44 Andrej Kacian 2017-07-05 11:35:01 UTC
(In reply to comment #43)
> I'm still of the opinion I made in comment #37 - it's far too convoluted.

Fully agreed. I think that any progress here should be based on the last patch before the ridiculous multiplier was introduced - the patch in comment #9.
Comment 45 wwp 2018-04-04 07:06:18 UTC
*** Bug 4004 has been marked as a duplicate of this bug. ***
Comment 46 users 2018-07-14 09:23:04 UTC
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	2018-07-14 11:23:04.278745916 +0200
http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=dd72700e412351f1bb2317c68b5528eba0ec9fc3
Merge: aa30051 df5a927
Author: Colin Leroy <colin@colino.net>
Date:   Sat Jul 14 11:23:03 2018 +0200

    Merge branch 'master' of file:///home/git/claws

http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=df5a927761513ef5fac8ead8fef34d31ebd090a0
Author: Andrej Kacian <ticho@claws-mail.org>
Date:   Sun Jun 17 15:10:50 2018 +0200

    Allow separate autocheck configuration for accounts.
    
    Accounts can have their own autocheck intervals, or follow
    global interval.
    
    This separates the autocheck configuration from 'Get all'.
    config_version is bumped to 3, because meaning of
    "receive_at_get_all" in account configuration has changed.
    
    Closes bug #2552: in automatic checking, enable the use of
    different time intervals
    Closes bug #2837: Detach automatic email checking from 'get all'
Comment 47 Andrej Kacian 2018-07-14 09:25:14 UTC
This feature is now in latest git.

Note You need to log in before you can comment on or make changes to this bug.