Apache OpenOffice (AOO) Bugzilla – Issue 19508
problem with Xwindows-style select and copy
Last modified: 2017-05-20 10:45:28 UTC
Under linux and solaris, X-style copy by selecting, then clicking the middle button does the copy all right but leaves the cursor at the end of the initial selection, meaning that 1) if the place where the selection was pasted is far from the place where it was copied, you jump back after to the selection after pasting -- very annoying; but worse, 2) if you just go on typing as if the cursor had behaved correctly, you erase your initial selection!
I tested a few X applications, and found that about half had this "defect" (including OpenOffice.org 1.1.0) and about half behaved according to your desired description. Therefore, I'm changing this to an enhancement request and confirming.
reassigned to bh
OpenOffice.org Issue Tracker - Feedback Request. The Issue you raised has the status 'New' pending further action, but has not been updated within the last 4 years. Please consider re-testing with one of the latest versions of OOo, as the problem(s) may have already been addressed. Either use the recent stable version: http://download.openoffice.org/index.html or consider trying the new OOo 3 BETA (still in testing): http://download.openoffice.org/3.0beta/ Please report back the outcome so this Issue may be Closed or Progressed as necessary - otherwise it may be Resolved as Invalid in the future. You may also wish to search for (and note) any duplicates of this Issue that may have advanced further by checking the Issue Tracker: http://www.openoffice.org/issues/query.cgi Many thanks, Andrew Cleaning-up and Closing old Issues as part of: ~ The Grand Bug Squash, pre v3 ~ http://marketing.openoffice.org/3.0/announcementbeta.html
*** Issue 100582 has been marked as a duplicate of this issue. ***
*** Issue 95681 has been marked as a duplicate of this issue. ***
To grep the issues easier via "requirements" I put the issues currently lying on my owner to the owner "requirements".
the copy and paste works as faulty (under X11) as described with 3.2.1 too regards Thomas
Yes, please, someone fix this! Easily the most annoying openoffice bug! We've been waiting 11 years for someone to take a look at this!
related (might be the same issue, but the OP mentions other issues too): https://issues.apache.org/ooo/show_bug.cgi?id=114897 FYI, the issue is still present in 3.4.1.
From what I'm reading here, my assumption is that this is a problem with non-recognition of 3 button emulation in mice with scroll wheels, and corresponding actions for these. I am including a link to some information from x.org that may assist with resolving this. http://www.x.org/archive/X11R7.5/doc/man/man4/evdev.4.html
I am researching this. It looks as though there is logic to use the mouse scroll wheel as a "paste" function, but perhaps the variable is not set correctly, and/or, may be relying on either X implementation that is no longer used, etc.
Additional development notes on this from http://www.novell.com/coolsolutions/feature/11231.html: --- begin info --- *Cut and Paste Cut and Paste under the X Windows environment is provided by two mechanisms: Selection: text is selected for copying by dragging the cursor, then is copied to other applications by clicking the middle mouse button. The data is stored in the primary buffer. Most X applications support primary selection. Clipboard: applications can cut/copy/paste text using menu selections and common key shortcuts -- Control-C for copy, Control-X for cut, and Control-V for paste. The data is stored in the clipboard buffer. Many applications do not support this method. The AWT only supports the clipboard buffer. For primary selection functionality, developers will need to use JNI to make the required calls to the X server. --- end info --- AOO uno uses com.sun.star.awt, a lightweight version of java awt. Hence the same non-native interaction with X. more coming...
Changing to DEFECT, and documenting additional behavior with X "Primary" selection: * an X style drag (copy) operation followed by a middle mouse click (paste) within the same AOO text document fails. However, pasting information into a new document this same way works correctly. * X style copy&paste (drag to highlight followed my middle mouse click. ) into an AOO spreadsheet works OK. * X style copy (drag text to highlight) into other apps (I used with kedit) works fine. So, X "primary" selection is being recognized from AOO. * X style paste from another app INTO AOO text document also works. Summary. It is only when the X primary selection is used within the SAME document that this operation fails for me. Please record other results as needed.
Please test out the latest Linux build for your architecture from: http://ci.apache.org/projects/openoffice/ either Linux-32 or Linux-64 nightly (Enlgish only) and comment if there is any improvement in this situation.
I was not able to notice any change in the behaviour when using the latest build compared to older versions or even LO.
(In reply to thaenig from comment #15) > I was not able to notice any change in the behaviour when using the latest > build compared to older versions or even LO. Thank you for this feedback, and my apologies for the delay in responding. You are correct in your assessment that fixing the gtk build had no impact on the original statement of this issue -- that of finding the cursor still positioned at the end of the string being copied instead of where one might expect it -- at the end of the pasted entity. More to investigate.
Reset the assignee to the default "issues@openoffice.apache.org".