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

[David Faure]

On Wednesday 24 September 2003 21:49, Andras Mantia wrote:
> On Wednesday 24 September 2003 19:43, David Faure wrote:
> > On Wednesday 24 September 2003 18:15, Andras Mantia wrote:
> > > +      if (klipper.send("setClipboardContents", m_popup->text(id)))
> > > +        kdDebug(129) << "Clipboard: " <<
> qApp->clipboard()->text(QClipboard::Clipboard) << endl;    
> > > +    }
> > > +    QTimer::singleShot(20, this, SLOT(slotActivated()));
> >
> > That's a very obvious race condition.
> > You should use call() instead of send(), in order to be certain that klipper
> > processed the call before using the clipboard. Then you don't need
> > the QTimer::singleShot.
> In the first (non-published) version I used "call" instead of "send". I don't
> know why I changed it to send. But what is sure that in that first version I
> also needed the singleShot, otherwise the selected text was not inserted.
> Well, I will test again.

I think a CVS policy says "don't commit code you don't understand" :)

> > Mmm, if we have the text in memory why do we have to ask klipper to
> > set the clipboard? Because it can be a shortened version of the text?
> > But then what happens if two texts have the same shortened version?
> > (or does klipper prevent against that?)... OK, this paragraph is about
> > something rather minor, you can ignore this :)
> I don't know another way to select a text from the clipboard history. Klipper
> doesn't have a DCOP method which I can use to select the N-th item from the
> menu.
Yes - the question is whether adding such a method wouldn't be better.
In theory it could be another source of race conditions, if klipper's contents
change between the time the menu's open and a menuitem is selected.
OK - I did too much multithreading recently - this one is very unlikely
I guess (clipboard contents usually only changes when the user asks for it :)

> > This action looks good to me, otherwise. I just hope it doesn't become
> > the standard action for KStdAction::paste, because e.g. in a vector
> > drawing application, seeing text contents to be pasted is totally useless.
> First I wanted to write you that you're right, it doesn't make sense in all
> applications. But even in a vector drawing (or some other type of)
> application it may make sense to paste text into. 
OK, but surely there are apps where it doesn't apply (kview/krita), or surely 
isn't the primary kind of thing you want to paste (many apps).

> Of course, the best would 
> be if Klipper would notice non-text object in the clipboard and we could
> handle it in the same way.
Yes, but the menu entries wouldn't be very helpful for non-text contents
("vector drawing 1", "vector drawing 2", etc.)  :)

>  Anyway, if you don't want it to be the standard paste action, I just don't
> commit the patch to kstdaction.cpp.
I think it could be a bit confusing for users.
Imagine a KWord user copying text - oh good it appears in the paste popup.
Then he/she copies an image frame - huh, it didn't work? It's not in the 
paste popup.... "Filtering" text-only copies can be a bit confusing IMHO, 
in non-plain-text apps. In KEdit / KMail / ... this will be great, of course.

In Konqueror (as file manager) the paste menu will have plain text entries
(huh? of course it works, since pasting text offers to create a text file
containing the text, but that's really not the common usage of the paste
action in a file manager...). It would be more useful to have urls there - but
anyway, better have no popup than really confusing entries, in e.g. konqueror
and kview/krita.

-- 
David FAURE, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).