Version: (using KDE KDE 3.5.1) Installed from: Compiled From Sources OS: Linux I would like to be able to access the actual messages in KMail folders via the DCOP interface. There is a function to do this in FolderIface.cpp, but it is commented out, I think because the message references become invalid if the folder is changed. Thanks, Kovid.
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.