http://bugs.winehq.org/show_bug.cgi?id=18448
Summary: Wine does not support X11 clipboard Product: Wine Version: 1.1.21 Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: tarasov.igor@gmail.com
There are 2 clipboards in modern linux distributions. First one is handled by X11 and another one by DE.
In order to copy into first one you just need to select text. In order to paste from that clipboard you need to click middle mouse button (wheel).
Second clipboard is managed by DE and in order to access it you use DE-specific hotkeys, usually ctrl/shift+insert and ctrl+c/v/x.
The later one is supported by wine, so you can easily copy text from wine applications into linux programs and vice versa.
But the first one, X11 clipboard is not supported at all. This is not just matter of convenience and ease of use, you can't just select some text and then middle click it into browser, for instance. The problem is that this sometimes break some applications.
For instance, take very popular linux dictionary, StarDict. It is very handy, since you can just simply select some text in any application and translation pops up. But if you try to do that with any wine application, this won't work. This makes usage of StarDict very inconvenient.
Also, middle-click is supported by wine, but it's support is incorrect. When you middle-click into wine application, it does paste text, but not from X11 clipboard (as one might expect) but from DE's one.
http://bugs.winehq.org/show_bug.cgi?id=18448
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 2009-05-12 11:24:06 --- Wine of course does support X11 clipboard. What X11 protocol you are talking about? And mouse button clicks as well as key pressed are handled not by Wine but by Windows applications.
http://bugs.winehq.org/show_bug.cgi?id=18448
Igor Tarasov tarasov.igor@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Wine does not support X11 |Wine does not support X |clipboard |primary selections
--- Comment #2 from Igor Tarasov tarasov.igor@gmail.com 2009-05-12 12:54:37 --- The protocol is ICCCM: http://tronche.com/gui/x/icccm/
Here is a good short article on the subject: http://www.jwz.org/doc/x-cut-and-paste.html
So, what I am talking about is PRIMARY selection, as opposed to CLIPBOARD selection.
Now, wine supports CLIPBOARD selection, but does not support PRIMARY selection.
Middle mouse click should paste from PRIMARY selection buffer, but in wine it does paste from CLIPBOARD. This is incorrect.
P.S: edited bug description to specify problem better.
http://bugs.winehq.org/show_bug.cgi?id=18448
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WORKSFORME
--- Comment #3 from Vitaliy Margolen vitaliy@kievinfo.com 2009-05-12 21:17:24 --- Did you set "HKCU\Software\Wine\X11 Driver\UsePrimarySelection" to true?
Works for me.
http://bugs.winehq.org/show_bug.cgi?id=18448
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #4 from Vitaliy Margolen vitaliy@kievinfo.com 2009-05-12 21:17:40 --- Closing
http://bugs.winehq.org/show_bug.cgi?id=18448
--- Comment #5 from Dmitry Timoshkov dmitry@codeweavers.com 2009-05-12 22:35:18 ---
From dlls/winex11.drv/clipboard.c:
* Wine's internal clipboard is exposed to external apps via the X * selection mechanism. * Currently the driver asserts ownership via two selection atoms: * 1. PRIMARY(XA_PRIMARY) * 2. CLIPBOARD * * In our implementation, the CLIPBOARD selection takes precedence over PRIMARY, * i.e. if a CLIPBOARD selection is available, it is used instead of PRIMARY.
So it's an intentional choice. And as Vitaliy said there is a registry key (UsePrimarySelection) which changes the behaviour.
http://bugs.winehq.org/show_bug.cgi?id=18448
Igor Tarasov tarasov.igor@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|WORKSFORME |
--- Comment #6 from Igor Tarasov tarasov.igor@gmail.com 2009-05-13 03:29:36 --- Okay, thanx. This made thigs a bit different, and while something started to work, there are still some problems, so I reopen the bug.
1. How can unexperienced user get to know about this registry item? Why there is no such item in winecfg? Why this option is DISABLED by default? I don't see ANY reason for this.
2. As ICCCM shows, PRIMARY selection gets filled not on copy command, but when text is selected. I am not sure if this is possible to add to wine since there seems to be no adequate system options in windows, and native application support seems to be required, but maybe various system text-related controls might support that out of box (edit, richedit etc)? It would be very cool if wine supported that. So, while StarDict becomes useable with this option enabled, but it still reacts on copy, not on selection. But this is anyway better than nothing, thanx again.
3. PRIMARY selection support is wrong with both UsePrimarySelection enabled and disabled. Here is a test:
a. Open some linux plain text editor. b. Type "Hello world". c. Select "world". Now PRIMARY selection holds "world". d. Copy it (ctrl+c). Now both PRIMARY and CLIPBOARD selections hold work "world". e. Select "hello". Now PRIMARY selection holds "hello", CLIPBOARD holds "world".
The test: In any linux text editor you may click middle mouse button and get word "hello", and use paste command to get "world".
In wine: with UsePrimarySelection disabled: pasting, or clicking middle mouse button returns the same value: CLIPBOARD one, "world". With UsePrimarySelection enabled: pasting or middle-click produces the same result: PRIMARY selection, "hello".
So, wine behavior in both situations is wrong, since this is not how PRIMARY and CLIPBOARD selections work in X, and this is not what users expect from it. And if it is internal choice, then it violates ICCCM in the way it treats selections. And there should be, at least optional, way to make wine work as expected.
http://bugs.winehq.org/show_bug.cgi?id=18448
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |winex11.drv Summary|Wine does not support X |Inconsistence in behaviour |primary selections |with UsePrimarySelection | |turned on and PRIMARY | |selection
--- Comment #7 from Dmitry Timoshkov dmitry@codeweavers.com 2009-05-13 05:33:20 --- PRIMARY selection is disabled by default because that's not what users coming from Windows expect. IMHO it's not worth adding it to winecfg due to that. Feel free to send a patch to document it.
Again, handling middle mouse button (as well as other buttons and keys) is up to a Windows application, not to Wine. Wine just passes events to the app.
The only thing to consider in this bug is inconsistence in behaviour with UsePrimarySelection turned on. But it's just an enhancement IMHO.
http://bugs.winehq.org/show_bug.cgi?id=18448
--- Comment #8 from Igor Tarasov tarasov.igor@gmail.com 2009-05-13 06:03:10 --- (In reply to comment #7)
PRIMARY selection is disabled by default because that's not what users coming from Windows expect.
But isn't it what users using linux expect? Wine by default uses linux window manager, so that windows behave not like in windows, they may have another button set etc, but that's okay, since we're in linux, and we try to integrate wine applications as seamless as possible, right?
Then, why do we break that seamless integration with selections?
IMHO it's not worth adding it to winecfg due to that.
There are options for above-mentioned window manager in winecfg, so why not having this one?
Feel free to send a patch to document it.
Not sure I understand well what exactly should be documented.
Again, handling middle mouse button (as well as other buttons and keys) is up to a Windows application, not to Wine. Wine just passes events to the app.
Umm... In windows, applications ignore middle-click. You can't paste text in notepad in windows using middle-click. But you can do that with the same native notepad.exe in wine. So, who's pasting text on middle-click - wine or application? That's wine who reacts on middle-click, and it reacts not correctly.
So, wine made an attempt to get integrated into linux in this area, but made it wrong.
Wine should either igonre middle-clicks for pasting (as windows applications do) or behave as linux applications do. Currently wine behavior is not logical.
http://bugs.winehq.org/show_bug.cgi?id=18448
--- Comment #9 from Dmitry Timoshkov dmitry@codeweavers.com 2009-05-14 03:02:43 --- (In reply to comment #8)
PRIMARY selection is disabled by default because that's not what users coming from Windows expect.
But isn't it what users using linux expect?
For a Linux native application - yes, a Windows application is a different animal, it behaves how Windows developers see it fits.
Wine by default uses linux window manager, so that windows behave not like in windows, they may have another button set etc, but that's okay, since we're in linux, and we try to integrate wine applications as seamless as possible, right?
That's not always possible or feasible, but Wine does an attempt, yes.
Then, why do we break that seamless integration with selections?
IMHO this behaviour with selections is confusing even for Linux users. But we have an option to enable it for those (rare enough obviously, you are the first one to complain) who prefer it.
Umm... In windows, applications ignore middle-click. You can't paste text in notepad in windows using middle-click. But you can do that with the same native notepad.exe in wine. So, who's pasting text on middle-click - wine or application?
It's the Edit control in user32 which does it. Now let's imagine that a Windows application subclasses an Edit control and say displays a custom context menu on middle mouse button click, but Edit in Wine also goes ahead and does a paste text...
Currently wine behavior is not logical.
You see now how it's not logical to try running a Windows application under a not native platform :-) Now try to imagine a feeling of a Mac user running Wine with X11 under the hood...
http://bugs.winehq.org/show_bug.cgi?id=18448
--- Comment #10 from Igor Tarasov tarasov.igor@gmail.com 2009-05-16 04:36:13 --- (In reply to comment #9)
But isn't it what users using linux expect?
For a Linux native application - yes, a Windows application is a different animal, it behaves how Windows developers see it fits.
The problem is that what we are talking about is not something linux-only, or windows-only. We are talking about tool that let us transfer information from linux programs into windows and vice versa. And we can't just say "this shouldn't work, since it does not work in windows" because this tool is of two sides. Some kind of support is required on both ends. And there should be not great difference in how wine applications work in this area, since clipboard is something that is being used system-wide. Users should not meet any troubles using this tool.
Then, why do we break that seamless integration with selections?
IMHO this behaviour with selections is confusing even for Linux users.
Well, until you try to use that. For instance, you meet some inactive url on a page. How can you visit it? In one click! Select it and then click middle button. If you copy/paste something, if you use clipboard, using mouse only it takes: 1) select 2) right-click 3) click copy, and then in the application 4) right-click 5) click paste. With primary selection: select, and in target application click middle button.
This is VERY convenient. It's just not everyone is aware of it.
But we have an option to enable it for those who prefer it
...which does not work as it should.
(rare enough obviously, you are the first one to complain)
Funny thing is that I've reported this problem and started digging only after I've got several complains from users, who experienced troubles with StarDict. So, I am far from alone, many users just don't understand WHY their dictionary is not working with wine apps, but they notice that it does not work.
It's the Edit control in user32 which does it. Now let's imagine that a Windows application subclasses an Edit control and say displays a custom context menu on middle mouse button click, but Edit in Wine also goes ahead and does a paste text...
Well, isn't it what wine really does right now? I repeat it: you can't paste text into edit control with middle click in windows. But wine provides this functionality, but in incorrect way.
Currently wine behavior is not logical.
You see now how it's not logical to try running a Windows application under a not native platform :-) Now try to imagine a feeling of a Mac user running Wine with X11 under the hood...
Okay, that's funny. I stress it again: middle click should either not work, or it should paste PRIMARY selection, as it is with any other application. And the perfect solution is to make all selected texts go into PRIMARY selection, at least for standard controls.
BTW, there is no such thing as PRIMARY selection in winodows, which means that it support could be added quite transparently into wine applications. That is, windows applicaions won't even notice that something has changed.
http://bugs.winehq.org/show_bug.cgi?id=18448
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WONTFIX
--- Comment #11 from Vitaliy Margolen vitaliy@kievinfo.com 2009-05-16 09:58:29 --- (In reply to comment #10)
I stress it again: middle click should either not work, or it should paste PRIMARY selection, as it is with any other application.
By default - no. If you do not like this, use registry to change the behavior. So far no one except you raised this "issue". Changing default because one person wants it won't fly.
http://bugs.winehq.org/show_bug.cgi?id=18448
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Vitaliy Margolen vitaliy@kievinfo.com 2009-05-16 10:02:17 --- BTW Firefox pasts primary selection or clipboard content depending on which was added last.
-
wine-bugs＠winehq.org