GNOME Bugzilla – Bug 270406
Add quota support to IMAP/POP accounts
Last modified: 2008-09-23 22:40:27 UTC
I would like to check my IMAP quota with evolution. I can do it nice with Thunderbird, it alerts me if my quota is nearly full. The same were very good in evo. Of coure you can do it for POP3 too.
I had a go at implementing this for IMAP in October 2004, and sent a patch to the evolution-patches list around then. However, the patch was against the old IMAP implementation. I put the quota against the INBOX name; screenshot here: http://people.redhat.com/dmalcolm/ScreenshotOfIMAPQuota.png
(See also bug 251262)
adding patch keyword
THe patch I sent was in October 2004 here: http://lists.ximian.com/archives/public/evolution-patches/2004-October/007793.html (It's probably bitrotted now)
I'm not sure I'd want the quota shown right there in the folder list (although some sort of indicator when it was "nearly full" might be nice.. maybe a change of icon or something), but I'd certainly like to see it in the Properties dialog for a folder and/or account.
The GTK_STOCK_DIALOG_WARNING icon [1] might be an appropriate indicator. And it should display a tooltip saying something like "Your account is nearly full." Also, I think it should go next to the account name rather than INBOX. That way you can still see it when you collapse the folder list for that account. [1] http://developer.gnome.org/doc/API/2.0/gtk/gtk-Stock-Items.html#GTK-STOCK-DIALOG-WARNING:CAPS
But isn't quota limit a per-folder setting in IMAP? In that case, the warning icon should probably be put on the relevant folder, not the whole mail account, since the quota limit can be different for different folders in one account.
Apple uses an "account property" window instead. We could merge the subscription list and some of the account specific behaviour in there. It would be easier than having to go in prefs->accounts->specific account every time. Screenshots attached.
Created attachment 97900 [details] leopard-launch-gal-18.png
Created attachment 97901 [details] leopard-launch-gal-19.png
Created attachment 97902 [details] leopard-launch-gal-20.png
Created attachment 97903 [details] leopard-launch-gal-21.png
(In reply to comment #8) > Apple uses an "account property" window instead. We could merge the > subscription list and some of the account specific behaviour in there. It would > be easier than having to go in prefs->accounts->specific account every time. I like that idea. I've never been happy with the Folder Subscriptions dialog. Might also be a good place to let the user mark particular folders as "inactive" (meaning they should not be checked for new mail).
Bumping version to a stable release.
Created attachment 108082 [details] [review] proposed eds patch for evolution-data-server; A bit simpler solution than the first one by Dave.
Created attachment 108083 [details] [review] proposed evo patch for evolution; It also requires a little bit changes on the Evolution side. This works in Properties of the folder, which also means no way how to show it for POP, because it uses local folders, shared between all POP (and similar) accounts.
Milan, you can read a bit about NotZed's comments at http://lists.ximian.com/archives/public/evolution-patches/2004-October/007866.html - if you are offline, it wont work :) - Everytime, I open it it is queried from the server. Read Notzed's comments. He has some other things. Great start.
I know it doesn't work in offline mode, in that case you will not see the number in folder preferences.
I'll copy here his points and comment to them, so we can make a view of it: >- You can't call any provider methods directly from evolution-mail code. >It isn't gauranteed to be dlopened by then, and you can't link with them >directly. I do not do it here, thus should be fine. >- I think you should just put the quota usage and limit values directly >into the CamelFolderInfo structure, and just use a known value, probably >defined to ~0 to define 'unknown value'. This simplifies memory >management and the code significantly. I did this as a virtual function of CamelFolder, which returns -1 to indicate "I do not know", which will cause hide of the quota information from folder properties dialog. >- Add a bit to the folderinfo flags to say if the quota value is >inherited from the parent. >- currently the code defines some values in a camel header which are >only used internally inside the mail code - unecessary. >- use camel:getv to get the quota values directly from the folder object >for the properties popup window. This is other approach, you know. >- the additional traffic - what can you do eh? We need to cache things >more agressively anyway but thats a mostly unrelated issue. For my implementation, it shows the actual quota usage on the folder only when in online mode, and asks server for the actual values, which is right thing, I think. And of course, it asks in time of the dialog creation, so no special traffic in other places. >- the generalisations, we should probably try to get all of the features >of all quota systems. e.g. some might have an alarm value or a limit >beyond which some features become disabled progressively. If this is >very complex then we might have to look into a more complex system, on >the other hand maybe it can be abstracted to something useful without >it, at least in the public api. Hmm, I didn't get this point much. I know my approach is not much generic, because for example for IMAP, server can define more than one quota limit, thus we should show more than one item there, with a name of the resource, but the name is server specific and I'm not sure whether I want to show there such words defined on server to user, also because they are usually in capitals, which looks strange a bit. You usually want to stay in touch with thunderbird, maybe we can check how it acts for some server supporting more quotas, or at least other quota than STORAGE.
> > >- the generalisations, we should probably try to get all of the features > >of all quota systems. e.g. some might have an alarm value or a limit > >beyond which some features become disabled progressively. If this is > >very complex then we might have to look into a more complex system, on > >the other hand maybe it can be abstracted to something useful without > >it, at least in the public api. > Hmm, I didn't get this point much. I know my approach is not much generic, > because for example for IMAP, server can define more than one quota limit, thus > we should show more than one item there, with a name of the resource, but the > name is server specific and I'm not sure whether I want to show there such > words defined on server to user, also because they are usually in capitals, > which looks strange a bit. > > You usually want to stay in touch with thunderbird, maybe we can check how it > acts for some server supporting more quotas, or at least other quota than > STORAGE. > Quota isn;t just about displaying the usage. But also the alert limit. You know in GW, I get a warning when Im in 85% usage or so. May be you can display the warning limit also. Which is what he meant. Just make sure your code is extensible for that.
Created attachment 108175 [details] [review] proposed eds patch ][ for evolution-data-server; OK, still implemented only for IMAP, but now one can ask for a folders quote information, this time returned as a structure, which can contain more than one quote information. It keeps the name of the quote. I'm not sure whether to localize this name here or in evo itself. For imap, there are two sample names, STORAGE and MESSAGE, but one can define its own name for a quota(s). It works only in online mode for IMAP, which is correct, I think. I also think it allows to extend this to anything, because you can ask for a quota on some folder and what you'll do with the returned information is up on you. I used this in evo part to show the quota itself to user in a folder property dialog.
Created attachment 108176 [details] [review] proposed evo patch ][ for evolution; Things got complicated a bit, I realized that I should retrieve quota information in a thread, not in a main thread, because it uses connect lock and in time of retrieving new mails/updating summary info, it get stuck. So added new operation.
EDS part seems fine to me (I haven't tested it) Milan, I dont think you use mfp_dialog_got_folder to get it in the other thread. Or Im missing something. I still see + folder = CAMEL_FOLDER (prop_data->object); + if (folder && (quota = camel_folder_get_quota_info (folder)) != NULL) { + CamelFolderQuotaInfo *info; + + for (info = quota; info; info = info->next) { + char *descr; + int procs; + on the mainthread.
Created attachment 108468 [details] [review] proposed evo patch ]I[ for evolution; I'm so sorry, I should learn to read... obviously...
Milan, seems fine now. Commit it to trunk.
eds part committed to trunk. Committed revision 8632. evo part committed to trunk. Committed revision 35366.
*** Bug 551807 has been marked as a duplicate of this bug. ***