Bug 67504

Thunderbird now does support the IDLE command. It may help to implement it in KMail.

This is true. It would make a lot more sense, you'll have to admit.

Only for the record: as the IDLE command needs a chance for the server to communicate actively with the client this is not fixable with the kioslave.

Couldn't this be implemented 'in' the kioslave - i.e. the slave doesn't receive any commands so it goes into an IDLE loop. And when a client (kmail or whatver) asks for a mail check, the kioslave responds with the newmail details it was given while it was in its IDLE loop. I haven't looked at the imap slave code yet, so i could be way off the mark.

*** Bug 78500 has been marked as a duplicate of this bug. ***

Perhaps this should be considered a bug in the KIO system itself, then. Why shouldn't the server be able to feedback with changes?
This has uses other than IMAP... FISH could use it to run FAM remotely and send back changed file info...

Could the KIO system have hooks/dcop callbacks for such changes of state? Are there plans for such a mechanism?

*** Bug 78371 has been marked as a duplicate of this bug. ***

A noticed that the tcp connection stays open while kmail is running. So the ioslave runs all the time, not?
Then is can't be that hard to implement some idle mode in the ioslave. The only question is how to report a state change back to the parent application...

*** Bug 120601 has been marked as a duplicate of this bug. ***

I have nearly a hundred folders in each of my two IMAP mail boxes.  It takes forever for some things to finish.  I'm using the 3.5.3 version of KDE.  I finally figured that I can just hit F5 to check for mail in only the current folder and within about 7 seconds I know if I have new messages in the inbox.  IDLE support is vital for me and for keeping the load on the servers down as well.    If I set the account to check for new messages periodically, it checks every folder within the account!   All I want periodic checks to look at is the Inbox.

It would be nice to see some KDE developers vote for this bug.  Perhaps then it would get more of the attention that it deserves.  Maybe there is another approach that could be used.  If a local maildir is supported via this application then would the FAM tool be able to notify KMail that there is new mail waiting?  If so, we could have another tool separate from KDE keep the local maildir synchronized with the remote IMAP server.
-Joe Baker

You can disable automatic check per folder (properties of the folder, you have the option in the [General] tab).

and I don't see how FAM could help here. in fact, instead of using kio, IMHO a first implementation of IDLE could be done in kmail, and send all the events to kmail. If it's an event that was triggered by kmail itself, just ignore it, else take the good action through the usual kio's.

Most imap server allow multiple connections from the same hosts (thunderbird uses often up to 4 e.g.) so it shouldn't hurt a lot, and is a first naïve, but existing solution to implement, before KDE 4.

There seems to be little intrest to implement this wish as it was opened almost three years ago.

Should we hire someone to do it? Collect bounty and pay for it? I could pay for this feature since I've a real use for this. Anyone else?

http://www.kontact.org/shopping/sanders.php

The problem is not really that there is no interest. It is not possible to
implement this with the current kioslave architecture but it will be
possible (I hope) with the new architecture for KDE 4. Otherwise I would
have implemented this months ago ;-)

Thanks Tommi, I posted my commitment with 100euros to Don. And I challenge the people in the vote list to join. 20 people with 40 euros would make 800 euros already.

Don't know how hard this would be to implement, perhaps someone could make an estimate for that?

> The problem is not really that there is no interest. It is 
> not possible to implement this with the current kioslave 
> architecture but it will be possible (I hope) with the 
> new architecture for KDE 4.

Any detailed information from kde4 Will the kioslave thing change
on parts what are showstoppers here? Has this been discussed among
developers working with kioslave for kde4? It would be really sad to see
this to be impossible again when they realease it someday.

Sorry, I don't want to sound annoying, but my coding skills don't scale
up for contributing to KDE so I try my best otherwise.

Juha Tuomala sagte:
> Any detailed information from kde4 Will the kioslave thing change
> on parts what are showstoppers here?


See http://pim.kde.org/akonadi/ and the kdepim-users mailinglist. The
kdepim structure will change completely.

Does anyone know if this limitation will be addresed in KDE4 ? 

I'd just like to point out that KDE3 does something which appears similar to IMAP IDLE support w.r.t local filesystems on Linux - where if you create a new file or directory e.g. from the commandline, Konqueror and file open/save dialogues update to show the new file without you having to press Reload/F5 on each of them.  Obviously these updates can't be coming from a KIOSlave - but is there a chance IMAP updates detected using the IDLE command could be delivered through the same channel?

Created attachment 21154 [details]
Work-around to get IDLE support in KMail

Here is a work-around to get IDLE support into KMail.

This patch will establish a connection to all folders in your mailbox and goes
into IDLE state. When a new mail arrives KMail will show that a new mail was
received just as you are used to it.

Additional Notes:
1) DO NOT MAKE ME RESPONSIBLE WHEN YOU LOSE YOUR MAIL
2) This patch is against KDE 3.5 branch
3) As this patch opens a connection for every folder, the server might not
allow so many connections as you have folders. So (if you are unsure) before
you enable this patch exclude some folders from getting checked for new mail or
watch the debug output.
4) If you change the configuration (see 2) you will need to restart KMail.
5) If the patch works for you, it should be save to disable the mail check
interval

Unfortunately I could only test this with my ISPs IMAP server which uses an own
implementation, meaning that there is a chance that this patch doesn't work
with your server.

I know it's a stupid patch (and I am not proud of it) but comments are of
course welcome!

As Carsten stated in #16 specific architecture changes are a prerequisite for IDLE support to be implemented. Has KDE 4 undergone these changes?

As this wish is the sixth most wanted feature of KDE at all, I'm curious if anything other than the workload on the developers is preventing it from beeing implemented.

Are there any news on this request? This feature would be really great!

Does KDE 4.3 support the notify mechanism required to implement IMAP IDLE in its basic kio abstraction? If yes, is there anything else missing for this much-needed feature in KMail?

Just so that people know, I pushed a few commits in trunk (latest one at that time being r1004137) which go in this direction. It adds the IDLE support to the Akonadi IMAP resource. User will benefit from it once we have an Akonadi based KMail.

Thanks for your attention.

You mean in kde5?

> You mean in kde5?

KMail 2, which is based on Akonadi, will probably be released together with KDE 4.5.

Nobody is thinking about KDE 5 yet :)

I'd love to see this implemented in Kmail.

With my other client marking a mail read on one platform (nearly) instantly shows it as read on other platforms.

With Kmail, not only is this not working, but Kmail delays sending notification to the server that a mail has been read until the next mail fetch. Simply clicking on and reading a message should send this notification to the imap server.

*** Bug 209934 has been marked as a duplicate of this bug. ***

Vielen Dank für Ihrer E-Mail. Leider bin ich z.zt. nicht im Hause.
Ich bin ab dem 06.01.2010 wieder im Büro erreichbar.

In dringenden Fällen wenden Sie sich an Herrn Nico Niepraschk unter nico.niepraschk@maxvis.de oder 03375 / 52 50 90.

Mit freundlichen Grüßen

Holger Hees

Hello, may I ask how is this feature as we're near kde4.4 ? 
 PF 2010 to all KDE folks :o)

Vielen Dank für Ihrer E-Mail. Leider bin ich z.zt. nicht im Hause.
Ich bin ab dem 06.01.2010 wieder im Büro erreichbar.

In dringenden Fällen wenden Sie sich an Herrn Nico Niepraschk unter nico.niepraschk@maxvis.de oder 03375 / 52 50 90.

Mit freundlichen Grüßen

Holger Hees

IMAP IDLE support is available in the akonadi resource. Kmail hasn't been ported to akonadi yet, so it's definitely not in KDE SC 4.4. If developers have enough time, it could be in KDE SC 4.5 or maybe even later. Akonadi support has been announced for Mailody almost two years ago (see mailody.net), but there haven't been any news since June 2008.

IMAP IDLE support would make kmail competitive again (e.g. thunderbird does support it) as IMAP gets more and more popular (e.g. gmail offering IMAP access with IDLE), but switching to akonadi is just not that trivial.

fyi, imap IDLE support for Gnome Evolution:

http://chenthill.wordpress.com/2010/01/11/evolution-with-improved-imap-support-imapx/

(In reply to comment #35)
> fyi, imap IDLE support for Gnome Evolution:
> http://chenthill.wordpress.com/2010/01/11/evolution-with-improved-imap-support-imapx/

pgnet - how do i enable this for my KMail?

damnshock, may I ask for elaboration on the resolution of this bug as "UPSTREAM"?

UPSTREAM from KMail POV is Akonadi which does support IDLE.  All we need is a release (or beta) of KMail using Akonadi.  And according to <http://dot.kde.org/2011/03/15/9th-annual-pim-meeting-renews-commitment-innovation> such a version should be here RSN (like this year).

Unfortunately, nothing using Akonadi *actually works*, so that will probably also be the day I start looking for a new mail client. No reason this couldn't have been fixed in KIO.

Luke-Jr may I ask for an elaboration of that?
I've been using KMail2 (the one with akonadi) for quite some time now and except for being a bit slow it works fine.

@Torgny Nyblom
So... i complain for the extreme slowness of kmail and you tell me it's going to be even worst?
That is great.

(In reply to comment #40)
> Luke-Jr may I ask for an elaboration of that?

I have to agree with Luke, ever since the kaddressbook moved using Akonadi, it has caused tons of wasted working hours. Apart of being terrible set of feature regressions, it's either screwing up the mysql database, not starting with broken NFS locks, somehow screwing its own configuration - one day it works and on another everything just disappears. Not to mention that the config dialogs aren't really a text book example.

Don't get me wrong, ever since I first heard about Akonadi I thought it's going to be the most important improvement for KDE. And in some way it is. But how it's implemented, just undermines every good goal that it's trying to achieve. 

At the time being, we have just gone backwards in everyhing that Akonadi touches. Can't say that I'm waiting kmail's akonadi support.

KAddressBook doesn't work at all since it was switched to Akonadi. I don't think I've even tried to use KOrganizer. It's a pain to maintain a text file for my address book, but that's all I have now.

kaddressbook works for me with akonadi.  Perhaps it depends on the distribution how well the addressbook works in combination with akonadi.

I just started it for the first time on my new PC, added my address book, and it shows nothing. Furthermore, there isn't even a place to select the category I want to filter for...

I found something like a workaround for KMail 1 some time ago. It involves 3
things:

1.) Configuring the mutt mail client which supports IMAP IDLE using muttrc to
run a script whenever new mail arrives. This is my muttrc, it also makes mutt
cache mail headers to reduce traffic and disables some other things not needed
when abusing mutt like this:
http://qar.ath.cx/~squall38/muttrc (goes into ~/.muttrc and you need to edit it
to fit your account settings)

2.) The script that's triggered by mutt. It notifies KMail via DBUS to refresh
the Inbox.
http://qar.ath.cx/~squall38/muttKMail.sh (should go into ~/bin)

3.) Launching the mutt mail client in the background on logon (GNU "screen" has
to be installed for this to work)
http://qar.ath.cx/~squall38/muttbackground.sh (the script makes sure there's
always only one mutt instance running, also should go into ~/bin)

It's a little unusual maybe but that's how I got rid of having a 5-minute
refresh interval in KMail 1. And it works.

@ Timo - You're confusing democracy with open source. They are not the same thing, open source means that you can write your own solution and even contribute it back if there is interest. It does not mean that developers need to listen to your opinions.

I voted for this feature, but I also have respect for the thousands of people who contribute their time and effort to open source software. I have nothing but contempt for those who think that they entitled to service when they have paid nothing for a product and who contribute nothing but their snide comments.

Can you please stop spamming with the summary changes? It whines to the whole watcher list every time.

As the reporter I'm getting all these updates on this ridiculous issues for years spamming my inbox...

Guys, just do it or let it be. But stop babbling about it for decades!

Please, reopen and close again as RESOLVED / FIXED when we have KDE-PIM/Akonadi ready. For the rest: the best "workaround" for this is a switch to KDE-PIM/Akonadi.

The performance of KDE-PIM/Akonadi trunk is marvelous. In fact, it's EONS faster than KMail 4.4 when it's about IMAP (GMail IMAP server: KDE-PIM 4.4, several days to sync; KDE-PIM/Akonadi, seconds to sync). Ask your distributors and don't forget to ask for Akonadi 1.5.1 and KDE 4.6.1.

KDE-PIM/Akonadi has been out for a long time now, yet I don't see IDLE support anywhere.
What's the current status of this issues? As far as I can see in this bug report, the intention was that IDLE support was to be included.

imap has idle support...
and work fine.

As far as I know kmail1 does not support Imap Idle, does it? It's Kmail2 (the akonadi based one) that supports IDLE.

Should we close the bug as WONTFIX as kmail1 code is not mantained any more?

no closed as fixed in kmail2
When we implement a feature in kmail2 we can close it as fixed.