- Furthermore this patch unifies the way pasted text and dropped text (as in d'n'd) is handled in our KMLineEdit (which is used for the address input fields).
svn path=/trunk/kdenetwork/kmail/; revision=183020
Make sure all messages are marked as being transfered even those that
are already retrieved this fixes a bug whereby messages already received
could be deleted causing a dangling pointer.
This also fixes a pre kmcommands bug whereby if a message was deselected
after it was transfered but before the modal transfer dialog was shown
then the message could be deleted causing a dangling pointer and a crash.
VS: ----------------------------------------------------------------------
svn path=/trunk/kdenetwork/kmail/; revision=175969
// are based on the command design pattern.
//
// Historically various operations were implemented as slots of KMMainWin.
// This proved inadequate as KMail has multiple top level windows
// (KMMainWin, KMReaderMainWin, KMFldSearch, KMComposeWin) that may
// benefit from using these operations. It is desirable that these
// classes can operate without depending on or altering the state of
// a KMMainWin, in fact it is possible no KMMainWin object even exists.
//
// Now these operations have been rewritten as KMCommand based classes,
// making them independent of KMMainWin.
//
// The base command class KMCommand is async, which is a difference
// from the conventional command pattern. As normal derived classes implement
// the execute method, but client classes call start() instead of
// calling execute() directly. start() initiates async operations,
// and on completion of these operations calls execute() and then deletes
// the command. (So the client must not construct commands on the stack).
//
// The type of async operation supported by KMCommand is retrieval
// of messages from an IMAP server.
svn path=/trunk/kdenetwork/kmail/; revision=175794
Carsten Burghardt
Ingo Klcker
Michael Haeckel
Don Sanders
Malcolm Hunter
Dirk Mueller