Cut, Copy and Paste [was : Re: Some bugs...]

[Richard Dale]

Thanks for the explanation of what's going on, that's really useful.

My suggested solution would be to extend the 'KLipper' utility so you could
select the 'current text buffer', which would either be the primary or secondary
selection buffers. All KDE/Qt apps should copy and paste from the 'current text
buffer'. Then KDE could still be configured to have the existing behaviour, but
with the option of using the secondary selection buffer globally instead (where
there would only ever be one item in the Clipboard History).

It would be a shame if every app had to write its own code to improve copy and
paste behaviour though - one of the advantages of a framework like KDE should
be to ensure consistency by providing all the services that a typical app would
need (even if they aren't quite right to start with!). When you improve the
framework, all the apps pick up the changes when recompiled.

-- Richard

On Mon, 18 Oct 1999, holle at almaden.ibm.com wrote:
> To answer the question from below, yes it is possible to make a Copybuffer that
> does not get overwritten by selecting a region in the editor. Did you ever
> wonder why (x)emacs did not paste anything with Ctrl-y when you selected
> something in an xterm or so ?
> Here is the explanation, I learned it not too long ago:
> 
> X11 has "two" buffers for these purposes:
> The primary selection buffer. It gets filled with whatever text gets selected
> with the mouse.
> The secondary selection buffer. It does not get filled by selecting text but by
> explicitely transferring the contents of the primary selection into it.
> 
> So here you got it. It is possible, if the whole KDE team agrees to use the
> secondary selection buffer for this purpose. I think Qt does not use it so we
> would need to write our own classes, but then again looking at the "Advanced
> Editor" who can maintain selections without loosing them and with having a
> totally different paste sematic, maybe we can snatch some code ???
> 
> - holger
> 
> Richard Dale <Richard_Dale at tipitina.demon.co.uk> on 16/10/99 18:15:17
> 
> Please respond to kdevelop at barney.cs.uni-potsdam.de
> 
> To:   kdevelop at barney.cs.uni-potsdam.de
> cc:
> Subject:  Re: Some bugs...
> 
> 
> 
> 
> I think the middle mouse button should paste at the mouse pointer position too.
> 
> I don't like the KDE/X Window behaviour where just selecting some text
> automatically puts it onto the pasteboard. Why are there 'Copy' commands in the
> menus  - there doesn't seem to be a lot of point? By the time you've selected
> the text (even if it was in order to change the text to italic), its been
> written to the pasteboard overwriting what was there before. So I can't copy
> some text in one window with the copy command on the Edit menu, then select
> some text to be replaced in another window, and use the 'paste' command to
> replace the current selection with the copied text. On every other windowing
> system I've used this just works - Mac OS, OpenStep, Windows. I find this
> really inconvenient - would it be possible the change this behaviour with some
> sort of default option?
> 
> -- Richard
> 
> On Fri, 15 Oct 1999, you wrote:
> > Concerning the middle mouse button paste function
> > I like it that way actually. If I am using the keyboard I will always use
> Ctrl-V
> > to paste and the cursor will always be where I want it to. If I am using the
> > mouse to move some text around I do not use the keyboard then the "paste
> > wherever mosue cursor is" save me one click.
> >
> > - holger
> >
> > pezz at tkwcy.ee (Peeter Russak ) on 15/10/99 04:54:41
> >
> > Please respond to kdevelop at barney.cs.uni-potsdam.de
> >
> > To:   kdevelop at barney.cs.uni-potsdam.de
> > cc:
> > Subject:  Some bugs...
> >
> >
> >
> >
> > Hi!
> > There are some bugs I think should be corrected:
> >
> > * Pasting with mouse's middle button:
> >      When selecting some text with mouse and pressing middle button of
> >      mouse pastes selected text into the place of mouse cursor and not to
> >      the place of text-cursor as would be expected. CTRL+V does the right
> >      action.
> > * Parsing the sourcecode.
> >      Saving or reading in file that contaions line
> >           class Foo : public {
> >      gives an error:
> >      on `aName != __null && qstrlen( aName ) > 0' failed.
> >      Aborted (core dumped)
> >      Yes it has buggy syntax but lines like that can be found during
> >      fast coding or maybe at the moment of autosave. Maybe it's
> >      not a real bug at all, but a result of my little hack-and-pray fix
> >      to another bug: at least in 1.0-19991009-A source there's a missing
> >      function, only declaration was in h-file (name was something line
> >      yyWrap or smth, can't look at the source at the moment) and of
> >      course when linking it gave an error.
> > * Back button in the browsing bar
> >      Could the menu under Back button be in the reverse order? Smth like
> >      netscape's Back button; first step back is the first line in the
> >      menu, second is second etc. At the moment the first step back is the
> >      last one in the menu.
> >
> > --
> > Peeter
> >
> > P.S. Does anybody know where to get rpm of qt-2.0.2?