[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: [PATCH] Show the clipboard history when pressing the Paste
From: Simon Hausmann <hausmann () kde ! org>
Date: 2003-09-23 7:36:08
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic