Bug 121844

Created attachment 14817 [details]
A patch that adds a method unreadMessageHeaders() to FolderIface

unreadMessageHeaders() returns the From, Subject and Date fields (separated by
the # character) for each unread message in this folder. Since it uses
getMsgBase(), it should be fast.

*** This bug has been confirmed by popular vote. ***

How about if the subject contains "#"? I think you should at least use another delimiter for this.

Well, since there are only 3 fields, the first and last are guaranteed to be From and Date, all the middle fields will then be subject. However, if you know of some printable character that is guaranteed to never be in the subject, I can easily make that change. The reason it needs to be a printable character is so that the output of the dcop commandline client also makes sense. 

Another alternative is to delimit the fields by substrings, rather than single characters, but that make parsing of the output in a script unnecessarily difficult IMO.  

A few questions.  It doesn't look like it leaves out unread messages in the Trash folder.  It should if it does not.  Also, is it possible to get the body of the message given the parameters that this function returns?  Even more, is it possible to specify a certain folder and only display the unread messages of that folder?  That would be extremely helpful with scripting.

The way this works is, forex, with the commandline client
dcop $(dcop kmail KMailIface getFolder /Local/inbox) unreadMessageHeaders

This will return the headers for unread messages in /Local/inbox. If you don't want messages in Trash, just don't call it on the Trash folder. 

I could add a field that gives the message index, which could then be used with another (to be written dcop method) to fetch the body of the message, but the reason I wrote this patch, is that I am developing a mail ticker with SuperKaramba that lists unread mails in a user-specified set of folders. Fetching headers is fast as kmail stores them locally, however, for a remote (IMAP) mailbox, it would have to download the message body. 

I cansee, however, that in some situations getting the message body may be useful. I'll modify the patch to add the message index to the returned fields as well and upload it soon. I'll also have to add a function to get the message body by index.    

Cool thanks.  Here's what I'm working on.  I'm writing a perl script that gets the  unread messages of a specific folder, Security in my case, and text messages my cell phone with that security message.  That way, if a security issue ever arises, I am immediately notified.  This dcop interface will be perfect for my script.  Thanks again.

Created attachment 14839 [details]
An expanded DCOP interface that allows for the fetching of unread messages as well

Changed unreadMessageHeaders to return fields in the format
index#from#date#subject.
Added 4 new functions:
1) touch( index): Marks message as read
2) requestMessageText( index ): Starts ASYNC loading of message body
3) isMessageTextAvailable( index ): ASYNC loading completed?
4) messageText( index ): return the body (text/plain, text/html) parts of the
email as plain text

There is some documentation on these functions in the patch. I will also upload
a test script demonstrating how to use them with the dcop commandline client.

Created attachment 14841 [details]
BASH script demonstarting how to use the interface to get message body

Edit the script and change the folder and message variables to suit your kmail.

Thank you Kovid for your contribution. KDE is in feature freeze for the 3.5 branch, so this feature cannot be added to KDE 3.5.2, though. Would you like to port your patch to trunk ( future 4.0, trunk/KDE/kdepim/kmail in the SVN server ) so that it appears in the next major release?

> KDE is in feature freeze for the 3.5 branch,

Yes, but... :-)
KDE 4 is far away. Can this patch introduce any serious regressions?

Additionally KDE 3.5 is a very long living branch and many people would be happy to see this patch in KDE 3.5.2 or KDE 3.5.3

> KDE 4 is far away. Can this patch introduce any serious regressions? 

It is a KDE-wide regulation. In any case, maintainers would be more authorized to comment about it.

Furthermore, you are always welcome to patch the software yourself, that way you can help the original author of the patch to improve/debug his patch through feedbacks too. Alternatively, you can ask your distribution's maintainers to incorporate this patch into their packages.

Created attachment 15015 [details]
Patch against TRUNK

Patched against trunk. I can't actually test the patch in KDE4 as I don't have
a working kde4 environment at the moment.

Created attachment 16187 [details]
DCOP interface patch against KDE4 kmail

I have migrated the patch to KDE4. It is tested against kmail from HEAD. Works
well for me. Can this be included now?

Thanks,

Kovid.

Re-assigning to KMail2. Not sure this can be done rightnow with dbus which took over DCOP in KDE 4.

Afaict, in PIM 5.5.1, retrieving messages via DBUS is still not implemented. Maybe I was just unable to find it. I searched the interfaces of kmail, Akonadi's NewMailNotifierAgent, and some Akonadi IMAP resources. It also seems that KFolderIFace didn't make the transition from DCOP to DBUS, and getting the number of (unread) messages in a folder is now impossible, too.