[Geany-Users] Problem with mouse copy/paste

[Alessandro Pasotti]

2014-05-08 9:46 GMT+02:00 Thomas Martitz <kugel at rockbox.org>:

> Am 08.05.2014 09:09, schrieb Alessandro Pasotti:
>
>> 2014-05-08 8:42 GMT+02:00 Lex Trotman <elextr at gmail.com <mailto:
>> elextr at gmail.com>>:
>>
>>
>>     On 8 May 2014 16:30, Alessandro Pasotti <apasotti at gmail.com
>>     <mailto:apasotti at gmail.com>> wrote:
>>     > 2014-05-08 2:23 GMT+02:00 Lex Trotman <elextr at gmail.com
>>     <mailto:elextr at gmail.com>>:
>>
>>     >>
>>     >> On 7 May 2014 22:36, Alessandro Pasotti <apasotti at gmail.com
>>     <mailto:apasotti at gmail.com>> wrote:
>>     >> > Hi,
>>     >> >
>>     >> > I'm not sure it is a geany bug but this is the only GTK
>>     application I
>>     >> > use
>>     >> > and I'm on kubuntu 14.04.
>>     >> >
>>     >> > The problem seems the same described here:
>>     >> >
>>     >> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1032119
>>     >> >
>>     >> > - Copy-paste with mouse wheel fails
>>     >> > + Left-click clears PRIMARY buffer selection (Copy-paste with
>>     middle-
>>     >> > + button/mouse wheel fails)
>>     >> >
>>     >> > To reproduce, try the following steps in gedit, geany or
>>     jedit (same in
>>     >> > old
>>     >> > bug-report):
>>     >> >
>>     >> > 1) Select some text, thus copying it to the primary
>>     >> > copy-paste-buffer-thingy.
>>     >> > 2) *Left* click somewhere on the document, thus clearing the
>>     selection.
>>     >> > 3) Click mouse wheel (middle click).
>>     >> >
>>     >>
>>     >> Many people brought up on cut/copy to clipboard and paste do
>>     not seem
>>     >> to grasp that the selection is a *selection*, it is not copied to a
>>     >> clipboard.
>>     >>
>>     >> The applications that the bug reporters call "working" are
>>     doing the
>>     >> wrong thing and copying the selection to the CLIPBOARD or
>>     internally
>>     >> preserving it even after it is unselected.
>>     >>
>>     >> When the middle paste is used it pastes the PRIMARY selection,
>>     or if
>>     >> there is no selection pastes clipboard.  So the applications
>>     doing the
>>     >> wrong thing will paste (either from their own internal copy or from
>>     >> clipboard), but those doing the right thing won't.
>>     >>
>>     >> Cheers
>>     >>
>>     >> Lex
>>     >
>>
>>
>>
>> Funny, it's about 20 years now that I'm using that method to quickly
>> copy-paste under linux using the mouse, just to discover today that it's
>> the wrong one :) Never too late to learn something!
>>
>> BTW it's a pity, because I find it much more quick and intuitive than
>> hitting various keyboard combinations like CTRL+SHIF+C or similar.
>>
>> Just to be sure, I did some quick tests (I'm on Kubuntu 14.04 64bit):
>>
>> mouse copy-paste  works fine (as I expected) in terminal applications
>> like konsole and xterm and works in mozilla FF and thunderbird.
>> Among IDE's it works fine under kdevelop, netbeans, eclipse kepler.
>> Ah, it also works in vim (didn't test emacs though).... I'm pretty sure
>> all curses-based apps work.
>>
>> Are you really sure that all these applications are doing it the wrong
>> way?
>>
>> It seems to me that clearing the selection/buffer when the user start
>> dragging would much better that clearing it on mouse down events.
>>
>
>
> I wonder why you even clear the selection with an additional left-click?
> Just select and middle paste directly.
>
>
I usually don't, but sometimes I do, for example it can happen that I want
copy-paste a piece of code but before pasting I notice that I need to type
a few charachters, in that case I click in the position, type what I need
to type, then paste.

I know this is not a show stopper, but I wonder (left aside discussions
about what is wrong and what is not) what tare the advantages/needs  to
clear the selection on left click.


-- 
Alessandro Pasotti
w3:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/users/attachments/20140508/a1e28d17/attachment.html>