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

[Eugene Jansen]

Richard, I've had some problems with this in some of my own applications -
thanks for the effort!

Eugene Jansen
RF/GPS Systems Engineer
Surrey Satellite Technology Ltd
+44 1483 259813
http://www.sstl.co.uk
http://netfold.com/~vipec


> -----Original Message-----
> From:	Richard Dale [SMTP:Richard_Dale at tipitina.demon.co.uk]
> Sent:	Thursday, October 21, 1999 10:13 PM
> To:	kdevelop at barney.cs.uni-potsdam.de
> Subject:	Re: Cut, Copy and Paste [was : Re: Some bugs...] - FIX
> 
> 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? << File:
> kdevelop-1.0beta3autocopy.patch.gz >>