Bug 8904

Bug still exists in KDE 3.1. 

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

Drag-and-drop to another application would be a useful feature for KAlarm, and 
possibly KOrganizer too.

Still valid for kdepim CVS 2004-06-30.

How did you try that? What kind of folder is the source and what kind of 
message it is? Works here, that's why I ask.

On Wednesday 07 July 2004 13:51, Carsten Burghardt wrote:
> ------- Additional Comments From burghardt kde org  2004-07-07 19:51
> ------- How did you try that? What kind of folder is the source and what
> kind of message it is? Works here, that's why I ask.

  Just tried it, the source folder is Inbox on a dimap account, and I get a 
"filename for clipboard contents" dialog.  I give it a filename, and it 
contains utf8 text and binary data of little meaning.

I see the same when dropping a mail from a local maildir folder.
The 'garbage' in the result looks like a QByteArray containing QStrings.
Will debug later, the garden calls :)

KMail creates a KPIM::MailListDrag. The result of the drag is a KPIM::MailSummary. What did you expect? The same as if you'd save the message? Well, sorry, but that's still not implemented.

Dragging messages to KDE PIM applications that can handle MailListDrags works very well.

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

I tryed with Evolution and it give interesting data:
- x-evolution-message (contain "file:///home/seb/evolution/local/Inbox\010568")
- message/rfc822 (contain the integral message)
- text/uri-list (contain "file:///tmp/evolution-501-3377/drag-n-drop-QEIsZ3/Re: basket")
When dragging more than one mail at a time, the uri-list contain a link
to a mbox file ("file:///tmp/evolution-501-3377/drag-n-drop-3muxAc/mbox"), but the rfc822 contain nothing (bad), the x-evolution-message add a '\0' and a
mail number for each mail at the end.

Just some toughts...

This shouldn't be too hard to implement.  We need to make sure that kmail decodes drops correctly (ie: it looks for what it wants, not just taking the first mimetype provided), and we need to modify libkdepim/maillistdrag.* to provide a mechanism to decode the data in full.

Created attachment 9896 [details]
start of a patch

I think this is the way to do it.  I just need to know how to store the right
pointers or variables in the drag object and turn those into a QByteArray
message/rfc822 when required.

CVS commit by staikos: 

Implement drag and drop of email to KDesktop, etc.
FEATURE: 8904
COOKIES: staikos@kde.org
X-Thanks-To: faure@kde.org, adam@kde.org


  A            kmail/textsource.cpp   1.1 [LGPL (v2+)]
  A            kmail/textsource.h   1.1 [LGPL (v2+)]
  M +1 -1      kmail/Makefile.am   1.330
  M +3 -1      kmail/kmheaders.cpp   1.705
  M +74 -4     libkdepim/maillistdrag.cpp   1.3
  M +24 -4     libkdepim/maillistdrag.h   1.4

I wonder if drag and drop to other applications has actually been implemented with the new code? In order to fetch the whole message, a class needs to be derived from MailTextSource which is defined as a virtual base class in maillistdrag.h. To fetch the message data, the virtual method text(), which takes the message serial number as a parameter, must be implemented. Am I right in thinking that for an application other than kmail, this is not actually possible since only kmail can access the message data by serial number?

On Wednesday 23 March 2005 11:07, David Jarvie wrote:
> ------- I wonder if drag and drop to other applications has actually been
> implemented with the new code? In order to fetch the whole message, a class
> needs to be derived from MailTextSource which is defined as a virtual base
> class in maillistdrag.h. To fetch the message data, the virtual method
> text(), which takes the message serial number as a parameter, must be
> implemented. Am I right in thinking that for an application other than
> kmail, this is not actually possible since only kmail can access the
> message data by serial number?


   It provides two different formats, the original KMail one, and the full 
contents.  The app is free to choose what it wants.  The one thing that 
should probably still be done is to make dragging of multiple messages 
actually create a proper mbox.  I have no idea how to do this with KMail 
right now so I didn't do it.

But the full contents are accessible only if the app derives a class from MailTextSource and implements the virtual method text(). The revised maillistdrag library files don't appear to provide any way for an app to implement this method. Only kmail has access to the data required to implement this method.

This was always the stumbling block in the past to fetching the full contents of messages - kmail provides no DCOP call to return the contents given a serial number. The new library methods don't appear to remedy this.

On Wednesday 23 March 2005 12:18, David Jarvie wrote:
> ------- But the full contents are accessible only if the app derives a
> class from MailTextSource and implements the virtual method text(). The
> revised maillistdrag library files don't appear to provide any way for an
> app to implement this method. Only kmail has access to the data required to
> implement this method.
>
> This was always the stumbling block in the past to fetching the full
> contents of messages - kmail provides no DCOP call to return the contents
> given a serial number. The new library methods don't appear to remedy this.


  ?? The new code puts the contents inside the drag object already...  That's 
how, for example, you can drop the messages onto KDesktop.  Am I somehow 
misunderstanding?

My reading of the code is that in order to access the contents of a dropped message, you have to call MailListDrag::encodedData("message/rfc822"). However, this method only returns the contents of the message via the member _src (a MailTextSource*). However, the libkdepim library doesn't define a non-virtual MailTextSource class, so I don't see how the contents can be extracted by calling the library functions.

On Wednesday 23 March 2005 14:01, David Jarvie wrote:

> ------- My reading of the code is that in order to access the contents of a
> dropped message, you have to call
> MailListDrag::encodedData("message/rfc822"). However, this method only
> returns the contents of the message via the member _src (a
> MailTextSource*). However, the libkdepim library doesn't define a
> non-virtual MailTextSource class, so I don't see how the contents can be
> extracted by calling the library functions.


   The drag source inherits from MailTextSource and reimplements it to give 
the text of a message with a given serial number.  The target calls 
encodedData("message/rfc822") and gets the text in a QByteArray.  It doesn't 
need to know about MailTextSource.

Any progress on this?

On Sunday 05 March 2006 10:22, Adam Porter wrote:
> Any progress on this?


I think I implemented this a while ago. Not sure whether it's in 3.5, 
but should be.

Till