Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.13) Gecko/2009082120 Iceweasel/3.0.14 (Debian-3.0.14-1) Build Identifier: I20090611-1540 In the editor component, when selecting text sections by keyboard (or any other means but mouse interaction) the PRIMARY buffer (as opposed to CLIPBOARD, both in X terminology) should not be altered. As it is now eclipse is broken for select + middle-click copy-n-paste as it alters the buffer every time text parts are shift+arrow selected etc. See http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt for reference. Correct behavior is illustrated by any GTK or QT app. Severity is rather grave since this breaks common and expected X copy+paste operations with Eclipse. Reproducible: Always
Praveen, do you want to investigate this?
(In reply to comment #1) > Praveen, do you want to investigate this? Sure, this is really interesting for me. I will start working on this.
(In reply to comment #0) > In the editor component, when selecting text sections by keyboard (or any other > means but mouse interaction) the PRIMARY buffer (as opposed to CLIPBOARD, both > in X terminology) should not be altered. The referred link indicates that the interpretation 'a' has lot of problems and thus suggests the best practices as - * selecting but with no explicit copy should only set PRIMARY,never CLIPBOARD * middle mouse button should paste PRIMARY, never CLIPBOARD Since interpretation a) has lot of problems, it seems to imply that PRIMARY is *not* only being used for Mouse selection. Any selected text (either through keyboard or mouse) can be stored onto PRIMARY buffer. Even apps such as Firefox, nautilus, gedit etc implement the same behaviour as Eclipse. > As it is now eclipse is broken for > select + middle-click copy-n-paste as it alters the buffer every time text > parts are shift+arrow selected etc. Why do you think that Eclipse is broken for select (copy) + middle-click (paste)? Eclipse is able to set the Primary buffer with the selected text (through mouse or keyboard) and that can be pasted through middle-click successfully.
(In reply to comment #3) > (In reply to comment #0) > > In the editor component, when selecting text sections by keyboard (or any other > > means but mouse interaction) the PRIMARY buffer (as opposed to CLIPBOARD, both > > in X terminology) should not be altered. > > The referred link indicates that the interpretation 'a' has lot of problems and > thus suggests the best practices as - > * selecting but with no explicit copy should only set PRIMARY,never CLIPBOARD > * middle mouse button should paste PRIMARY, never CLIPBOARD > > Since interpretation a) has lot of problems, it seems to imply that PRIMARY is > *not* only being used for Mouse selection. Any selected text (either through > keyboard or mouse) can be stored onto PRIMARY buffer. Even apps such as > Firefox, nautilus, gedit etc implement the same behaviour as Eclipse. Yes, alternative b) is what good behaving X programs should do. You're correct that also keyboard selected text seems be stored (GTK+ seems to do this, Emacs and QT which I mostly use doesn't). However the part that annoys at least me is that automatic selections seems to also get stored in PRIMARY buffer. When using eclipse I keep losing clipboard all the time. This doesn't happen in Firefox, Kate, Konqueror, Emacs etc. For example, when using eclipse, hit Ctrl-F for search - clipboard temporarily set to whatever search phrase was last used, afterwards it's erased completely. Same goes for Ctrl+H and lot's of other dialogs. Do the same in Firefox, Ctrl-L. Current URL is "selected" by default, clipboard however is not lost. > > > As it is now eclipse is broken for > > select + middle-click copy-n-paste as it alters the buffer every time text > > parts are shift+arrow selected etc. > Why do you think that Eclipse is broken for select (copy) + middle-click > (paste)? > Eclipse is able to set the Primary buffer with the selected text (through mouse > or keyboard) and that can be pasted through middle-click successfully. I think the basic annoyance is that there's lot's of way that text is automatically "selected", which erases the parts that the user has really selected and thus expect to remain in clipboard.
(In reply to comment #4) > However the part that annoys at least me is that automatic selections seems to > also get stored in PRIMARY buffer. > > For example, when using eclipse, hit Ctrl-F for search - clipboard temporarily > set to whatever search phrase was last used, afterwards it's erased completely. > Same goes for Ctrl+H and lot's of other dialogs. > > Do the same in Firefox, Ctrl-L. Current URL is "selected" by default, clipboard > however is not lost. It is the native behavior of GTK that the automated selected text gets copied into PRIMARY selection buffer. The same behavior might not be seen with Firefox due to that fact that it's UI is mostly rendered using it's javascript engine and part of it by GTK. Since this is the native behavior, I hope the reported problem can not be fixed.
*** Bug 296247 has been marked as a duplicate of this bug. ***
*** Bug 294464 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > [...] > When using eclipse I keep losing clipboard all the time. This doesn't happen > in Firefox, Kate, Konqueror, Emacs etc. > > For example, when using eclipse, hit Ctrl-F for search - clipboard temporarily > set to whatever search phrase was last used, afterwards it's erased completely. > Same goes for Ctrl+H and lot's of other dialogs. > > Do the same in Firefox, Ctrl-L. Current URL is "selected" by default, clipboard > however is not lost. > [...] > I think the basic annoyance is that there's lot's of way that text is > automatically "selected", which erases the parts that the user has really > selected and thus expect to remain in clipboard. Yes, that is the point which annoys me most. I work around this behaviour by using klipper to save my recent selections and re-activate if pre-selected text overwrites the clipboard. For me this is a major usability annoyance. Please fix this for Eclipse 3.5.2. Thanks.
Another example of this is the CCombo control: The Mylyn task editor invokes CCombo.select(index) to set the selected value on the category chooser when the task editor controls are constructed. CCombo.select(index) calls text.selectAll() which replaces the clipboard content on Gtk: text.setText (list.getItem (index)); text.selectAll (); This means merely opening a task editor replaces the clipboard contents which doesn't seem right. CCombo should at least provide API that supports selecting values without this side effect.
Any news here? This is really annoying and should be implemented for Eclipse 3.6 Helios.
OK, let me describe in more detail how this error disturbs my workflow _every day_ I work with Eclipse: * Select some longer section of code or text, e.g. a check-in comment in the commit dialog * Press OK -- the code is committed and my selection contains the lengthy comment * Switch to the Mylyn task * Paste... * Ooops... now my selection contains useless stuff as "joerg", "External dependency", "defect" what-ever pre-selection happened to select Now comes klipper to the rescue: * Move mouse pointer down from the top-level display to the lower-level display of my dual-screen setup since the klipper is in the other task panel * Select the saved selection with the comment * Directly move to the correct place in Eclipse (never anythings else -- pre-selects may happen!!!) * Paste... * phew... it finally worked Steffen Pingel tracked down this issue with Mylyn as a limitation of the Platform.SWT component. So please correct this, it is really annoying!
Would really appreciate if somebody answers.
*** Bug 316162 has been marked as a duplicate of this bug. ***
Form fields with default-selected text (e.g. the workspace selection dialog on startup) also replace the buffer contents. I use klipper as Jörg does, but this is still extremely annoying! Please fix!
Yes, please do. This is a constant annoyance.
GtkEntry does not provide any API to change the selected text without changing the PRIMARY clipboard. The PRIMARY clipboard is changed when gtk_editable_select_region() API is called. This is the line of GTK code which causes this problem: https://git.gnome.org/browse/gtk+/tree/gtk/gtkentry.c?id=d2ba7d75c3d5909f57dd778989bffaa984878990#n4939 The same problem described in comment#4 happens in gedit (native GTK app). I believe there is nothing SWT can do to fix this without proper support from GTK.
How about filing a suitable RFE to GNOME GTK? You probably know best what a suitable API extension could be. Thanks, Jörg
(In reply to comment #17) > How about filing a suitable RFE to GNOME GTK? > You probably know best what a suitable API extension could be. > > Thanks, Jörg From a quick conversation with GTK developer - he is not really willing to add or accept such an API to alter PRIMARY behaviour especially considering that wayland would not have such mechanism (http://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml See wl_data_device). With that said any such API will have to be x11 specific and the general path seems to be for gtk to become less coupled to X11 with the general trend being towards wayland.
Maybe I'm completely confused but I think PRIMARY selection was added to wayland/GNOME recently: - https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection - https://bugzilla.gnome.org/show_bug.cgi?id=762560 So maybe this is fixable now? Destroying my clipboard contents whenever I select text with a keyboard is highly annoying.
Could someone (In reply to Felix Schwarz from comment #19) > So maybe this is fixable now? Destroying my clipboard contents whenever I > select text with a keyboard is highly annoying. Hi Felix, I'm trying to reproduce the case of the clipboard being destroyed when selecting text. Currently, if I do copy text into the clipboard and select text after, I can still output the clipboard without it being overridden.
Bug triaged. Visit https://wiki.eclipse.org/SWT/Devel/Triage for more information.
This isn't something SWT can fix. GTK modifying the PRIMARY selection when doing pre-selected text in a text box isn't something fixable from our end. PRIMARY selection is an X11 concept which is likely gone in GTK4 anyways. Sorry about that. :/ (In reply to Felix Schwarz from comment #19) > Maybe I'm completely confused but I think PRIMARY selection was added to > wayland/GNOME recently: > - https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection > - https://bugzilla.gnome.org/show_bug.cgi?id=762560 > > So maybe this is fixable now? Destroying my clipboard contents whenever I > select text with a keyboard is highly annoying. Wayland supporting PRIMARY selection != GTK's behaviour changing, as GTK is trying to de-couple itself from window manager specific concepts like PRIMARY selection.
*** Bug 314065 has been marked as a duplicate of this bug. ***
