[PATCH] Show the clipboard history when pressing the Paste button

[Simon Hausmann]

On Mon, Sep 22, 2003 at 12:28:22PM +0300, Andras Mantia wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
>   Here is an implementation of Datschge's idea: provide a list of the 
> clipboard history under the Paste button (similar to the history in 
> Konqueror). This is a generic implementation and by applying the patch every 
> application will benefit of it without any change. It creates a new action 
> class (KPasteAction) which communicates with Klipper via dcop. Of course 
> there is no guarantee that Klipper is running, in that case the button works 
> like before, and the only item in the menu is the current clipboard content. 
> So the patch contains the KPasteAction class (the code could be simplified in 
> KDE 4.0 if we inherit from KToolBarPopupAction and make the popupMenu() 
> method virtual) and a change in the KStdAction, so for Paste this class will 
> be used. 
>  I have only one problem with it that I couldn't solve cleanly: when a menu 
> item is selected, I change the clipboard with a DCOP call, but the clipboard 
> isn't changed immediately (see the debug output) and I have to use a 
> singleShot timer to send the "activated" signal. Otherwise the selected text 
> won't be pasted. I'm afraid a little about this issue as there may still be 
> cases when the timer is elapsed before the clipboard is set. Any better ideas 
> here? Setting the clipboard directly does not work and I get 
> "QClipboard::setData: Cannot set X11 selection owner for CLIPBOARD" in the 
> debug output.

I have to admit that I for one don't really like the idea of such a
dependency. (What if klipper gets removed one day?) . Plus the menu
will always be visible, even if klipper is not running. It will
appear as empty menu, which looks really ugly.

Technically on the patch:

1) The popupmenu appears to be leaked.
2) It's _much_ easier to perform dcop calls with DCOPRef than to do
   the (de)marshalling of the data manually
3) The if ( !client->isAttached() ) client->attach() is superfluous
   IMHO

Anyway, just my 2 cents.

Simon