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

[Richard Dale]

I've been looking into how the Qt/KDE libs use the clipboard - they all use
XA_PRIMARY. I couldn't find any program which did anything with
the XA_SECONDARY buffer. I changed the two source files in Qt and KDE to use
'XA_SECONDARY' as a clipboard as an experiment - it still worked fine as long
as the apps were all using the hacked Qt/KDE libs (all the others were still
looking at XA_PRIMARY). But even after this fix, when text was selected, it was
still automatically copied to the clipboard (although XA_SECONDARY instead of
XA_PRIMARY).

So the solution was to change KDevelop - it has some code which automatically
copies the current selection to the clipboard when the mouse is released in the
editor. So here is a patch to kdevelop-1.0beta3 to make this behaviour optional.
I've added a new 'Auto Copy' option to the 'Options->Editor...' menu. If 'Auto
Copy Selection' is not enabled, then just selecting something will not copy it
to the clipboard. An item will only be copied with an explicit 'Edit->Copy' or
Ctrl+C command.

I've also fixed a bug in the code to replace the current selection with the
clipboard contents; the code was wrongly appending to the existing contents.

gunzip  kdevelop-1.0beta3autocopy.patch.gz

Copy kdevelop-1.0beta3autocopy.patch to the directory
above the KDevelop sources

$ cd <KDevelop source directory>
$ patch -p1 < ../kdevelop-1.0beta3autocopy.patch
$ ./configure
$ make
$ make install


-- 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdevelop-1.0beta3autocopy.patch.gz
Type: application/x-gzip
Size: 1631 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop/attachments/19991021/07a3ee26/attachment.bin>