Community
Participate
Working Groups
When using a StyledText with MouseNavigation enabled, clicking the middle mouse button will paste the contents of the clipboard into the StyledText widget. This is undesired behaviour -- the middle mouse button should only scroll and not modify the contents of the widget.
In Gnome the middle button is used for paste operation. This causing undesired behaviour for eclipse. I see two options for us 1. Disable paste operation on mouse middle button click in GUI. users can use right click paste for paste operation 2. Clear clipboard when we enable mouse navigator The second one will cover only half of the cases. We should go with the first option. We should disable paste operation on linux on middle button click on linux
Only if MouseNavigation is enabled, please.
(In reply to Sravan Kumar Lakkimsetti from comment #1) > In Gnome the middle button is used for paste operation. This causing > undesired behaviour for eclipse. I see two options for us > > 1. Disable paste operation on mouse middle button click in GUI. users can > use right click paste for paste operation This would be a no-go for long term Linux users (me and my lab). Middle click is *the* killer feature on Linux. > 2. Clear clipboard when we enable mouse navigator > > The second one will cover only half of the cases. We should go with the > first option. We should disable paste operation on linux on middle button > click on linux Not sure if this is meant only *during* the mouse navigation in StyledText? Could you elaborate a bit more, how exactly you plan to disable the mouse middle button click, and if this will mean, usual text editing in Java code will have no "paste on middle click" feature *at all*? In this case I strongly disagree.
(In reply to Andrey Loskutov from comment #3) > (In reply to Sravan Kumar Lakkimsetti from comment #1) > > In Gnome the middle button is used for paste operation. This causing > > undesired behaviour for eclipse. I see two options for us > > > > 1. Disable paste operation on mouse middle button click in GUI. users can > > use right click paste for paste operation > > This would be a no-go for long term Linux users (me and my lab). Middle > click is *the* killer feature on Linux. > > > 2. Clear clipboard when we enable mouse navigator > > > > The second one will cover only half of the cases. We should go with the > > first option. We should disable paste operation on linux on middle button > > click on linux > > Not sure if this is meant only *during* the mouse navigation in StyledText? > Could you elaborate a bit more, how exactly you plan to disable the mouse > middle button click, and if this will mean, usual text editing in Java code > will have no "paste on middle click" feature *at all*? In this case I > strongly disagree. We have to enable mouse navigation using an api. My suggestion is when we enable mouse navigation we need to "disable paste on middle click" for that widget. We should not disable paste operation on other widgets.
(In reply to Sravan Kumar Lakkimsetti from comment #4) > We have to enable mouse navigation using an api. My suggestion is when we > enable mouse navigation we need to "disable paste on middle click" for that > widget. But this will mean, that if text editors start using mouse navigation, they will stop supporting "paste on middle click". So we accept a breaking change to support a "nice to have" feature. Do I understand it right, "middle click" is the hard-coded shortcut to enable this mouse navigation? Can't we configure that, or at least allow user to disable that shortcut which changes default system behavior? Can you please link this bug to the one where the "mouse navigation" feature was introduced?
(In reply to Andrey Loskutov from comment #5) > (In reply to Sravan Kumar Lakkimsetti from comment #4) > > We have to enable mouse navigation using an api. My suggestion is when we > > enable mouse navigation we need to "disable paste on middle click" for that > > widget. > > But this will mean, that if text editors start using mouse navigation, they > will stop supporting "paste on middle click". So we accept a breaking change > to support a "nice to have" feature. > > Do I understand it right, "middle click" is the hard-coded shortcut to > enable this mouse navigation? Can't we configure that, or at least allow > user to disable that shortcut which changes default system behavior? > > Can you please link this bug to the one where the "mouse navigation" feature > was introduced? Very good points here. Configuring the shortcut may be a good idea. @laurent what do you think?
Just found bug 544616 for preferences.
If MouseNavigation is enabled then middle click will be meant for bringing up the navigation icon...not pasting. We had a working fix before, and it was to block the paste action in StyledText upon middle button mouse down. IMO Andrey's idea is best, just allow users to enable/disable MouseNavigation for editors in some preference, and then we can keep the middle click paste for those who want it. I think MouseNavigation should be disabled by default, that way we don't break middle click pasting for all those who use it.
Well, when I worked on this feature I did not think about the "copy with middle click" behaviour :( I can see 2 solutions for this problem : a) On linux, activate the mouse scrolling only if a key is pressed (for example shift+middle click) b) Or enable the "mouse navigation" only if a "longer click" is fired. * If the user clicks quickly on the middle button, the content of the clipboard is pasted * If the user clicks more than 100 ms the "navigation cross" is displayed and the user can scroll through the StyledText Solution a) is pretty easy to implement (with state mask) but in this case users can be puzzled when switching operating system (activation by clicking on the middle button on mac & windows and shift+middle button on Linux) What do you think ?
(In reply to Laurent CARON from comment #9) > Well, when I worked on this feature I did not think about the "copy with > middle click" behaviour :( Sorry, I've missed to check the new feature completely. > Solution a) is pretty easy to implement (with state mask) but in this case > users can be puzzled when switching operating system (activation by clicking > on the middle button on mac & windows and shift+middle button on Linux) > > What do you think ? I think the "delay" sounds interesting, but I personally also have no problems with extra keys. The question is if we can really prevent "paste" to happen then?
Thanks to the state mask, we can "cancel" the paste event in StyledText if shift key if pressed. Anyway, it can be weird for users because this functionality mimics the "mouse navigation" of Chrome and Firefox but users will have to press a key... I'll work on the "delay" solution. Stay tuned !
New Gerrit change created: https://git.eclipse.org/r/138301
Gerrit change https://git.eclipse.org/r/138301 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=84153c9002a622b5a8568e5f5a4914d93cffa6ad
(In reply to Eclipse Genie from comment #13) > Gerrit change https://git.eclipse.org/r/138301 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=84153c9002a622b5a8568e5f5a4914d93cffa6ad In master now, leaving this bug open for the Wayland portions that still need fixing.
(In reply to Eric Williams from comment #14) > (In reply to Eclipse Genie from comment #13) > > Gerrit change https://git.eclipse.org/r/138301 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > > ?id=84153c9002a622b5a8568e5f5a4914d93cffa6ad > > In master now, leaving this bug open for the Wayland portions that still > need fixing. Verified in I20190408-1800 on Suse Leap 15 with Java 12
Verified in I20190408-1800 on Ubuntu 18.04 with Java 12
We still have a problem on X11 (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=545041) => I close this bug and work on bug 545 041. Please reopen if I did wrong.
