X11 Clipboard implementation
Hi all, I've been poking around inside the wine clipboard system, in an attempt to make it properly compliant with the agreed upon specs over at http://www.freedesktop.org/standards/clipboards.txt At the moment, Wine mixes up CLIPBOARD and PRIMARY, which is not a good idea. Ideally, Wine would work like GTK, Qt, Mozilla and all the rest do, which is to keep CLIPBOARD for ctrl-c, ctrl-v type operations, and primary for selected text/middle click. When you select some text in say notepad, both CLIPBOARD and PRIMARY are grabbed, which is wrong, only primary should be grabbed. In a similar fashion, when you select Edit | Copy only CLIPBOARD should be grabbed. Currently, selecting text in Wine doesn't do anything (at least, not in notepad). So, the obvious way to fix that would be to introduce a new Wine-specific API, that lets the Wine controls call SetSelectedText or something, which then interfaces with X. So, I think x11drv/clipboard.c should be changed to basically eliminate references to PRIMARY, as without the ability to deal with middle clicks and grab-on-select, Wine has no business changing that selection. Therefore my questions are: 1) Should I try and hack up a patch to stop wine using PRIMARY? 2) What are the rules governing new wine specific APIs. I know the DLL Separation work is supposed to eliminate them, but there are no FAQs anywhere on it that I can see, could somebody explain this please? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
On Wed, 2003-02-12 at 05:22, Mike Hearn wrote:
Hi all,
I've been poking around inside the wine clipboard system, in an attempt to make it properly compliant with the agreed upon specs over at
http://www.freedesktop.org/standards/clipboards.txt
At the moment, Wine mixes up CLIPBOARD and PRIMARY, which is not a good idea. Ideally, Wine would work like GTK, Qt, Mozilla and all the rest do, which is to keep CLIPBOARD for ctrl-c, ctrl-v type operations, and primary for selected text/middle click.
When you select some text in say notepad, both CLIPBOARD and PRIMARY are grabbed, which is wrong, only primary should be grabbed. In a similar fashion, when you select Edit | Copy only CLIPBOARD should be grabbed.
Currently, selecting text in Wine doesn't do anything (at least, not in notepad). So, the obvious way to fix that would be to introduce a new Wine-specific API, that lets the Wine controls call SetSelectedText or something, which then interfaces with X.
You may be able to hack some of the controls to support text selection but you won't be able to do it for the general case. For example this wouldn't work in Word. So I don't see this working. In fact it could break assumption made by the application. In my opinion, the only way to copy data from a Windows App to X is via control-c/Clipboard API. In Windows, to copy data you generally need to select the data (Under X this would grab the PRIMARY selection) and then hit control-c (Under X this would grab the CLIPBOARD selection). In think we should always be grabbing both PRIMARY and CLIPBOARD and releasing them when we loose either (ClearAllSelections=1). This seemed to be the least confusing for many users as well. I'm in the process of finishing a large clipboard patch for CodeWeavers that should also address the dll separation issues. Hopefully I'll get the patch together soon and post it to the list.
So, I think x11drv/clipboard.c should be changed to basically eliminate references to PRIMARY, as without the ability to deal with middle clicks and grab-on-select, Wine has no business changing that selection.
Therefore my questions are:
1) Should I try and hack up a patch to stop wine using PRIMARY? 2) What are the rules governing new wine specific APIs. I know the DLL Separation work is supposed to eliminate them, but there are no FAQs anywhere on it that I can see, could somebody explain this please?
thanks -mike -- Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> -- Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca>
You may be able to hack some of the controls to support text selection but you won't be able to do it for the general case. For example this wouldn't work in Word. So I don't see this working. In fact it could break assumption made by the application. In my opinion, the only way to copy data from a Windows App to X is via control-c/Clipboard API.
Yes, true
In Windows, to copy data you generally need to select the data (Under X this would grab the PRIMARY selection) and then hit control-c (Under X this would grab the CLIPBOARD selection).
In think we should always be grabbing both PRIMARY and CLIPBOARD and releasing them when we loose either (ClearAllSelections=1). This seemed to be the least confusing for many users as well.
I don't agree with that, the X clipboard spec is very clear on this, and most apps are now in compliance. Mixing them together is what Qt used to do, and people found it very confusing when they couldn't figure out what was going on with the clipboard.
I'm in the process of finishing a large clipboard patch for CodeWeavers that should also address the dll separation issues. Hopefully I'll get the patch together soon and post it to the list.
Cool :)
-- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
On Wed, 2003-02-12 at 10:01, Mike Hearn wrote:
You may be able to hack some of the controls to support text selection but you won't be able to do it for the general case. For example this wouldn't work in Word. So I don't see this working. In fact it could break assumption made by the application. In my opinion, the only way to copy data from a Windows App to X is via control-c/Clipboard API.
Yes, true
In Windows, to copy data you generally need to select the data (Under X this would grab the PRIMARY selection) and then hit control-c (Under X this would grab the CLIPBOARD selection).
In think we should always be grabbing both PRIMARY and CLIPBOARD and releasing them when we loose either (ClearAllSelections=1). This seemed to be the least confusing for many users as well.
I don't agree with that, the X clipboard spec is very clear on this, and most apps are now in compliance. Mixing them together is what Qt used to do, and people found it very confusing when they couldn't figure out what was going on with the clipboard.
I though you wouldn't ;) As you pointed out, if we can't use text selection to pass data via PRIMARY (because Windows apps don't allow this) then it follows that we should only use CLIPBOARD. But when I select and copy text from Word, I want be able to paste it into my xterm! I find this to be a common complaint. I guess in Wine we have been simulating the selection of data into PRIMARY by assuming that if you copied data into the clipboard you probably selected it. Your right thought, Wine apps may be somewhat unique but at the end of the day its behaviour is non-standard. What does everyone else think? This is one area that most people will have an opinion :)
I'm in the process of finishing a large clipboard patch for CodeWeavers that should also address the dll separation issues. Hopefully I'll get the patch together soon and post it to the list.
Cool :)
-- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center -- Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> -- Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca>
I though you wouldn't ;) As you pointed out, if we can't use text selection to pass data via PRIMARY (because Windows apps don't allow this) then it follows that we should only use CLIPBOARD. But when I select and copy text from Word, I want be able to paste it into my xterm! I find this to be a common complaint.
If xterm can't use the CLIPBOARD selection then it's broken I'm afraid. gnome-terminal for instance can use both (shift-ctrl-v pastes clipboard). I guess Konsole is similar. The solution isn't to break wine, really it's to unbreak xterm (or for you to use a different terminal emulator). thanks -mike
* Ulrich Czekalla (ulrich.czekalla(a)utoronto.ca) wrote:
On Wed, 2003-02-12 at 10:01, Mike Hearn wrote:
I don't agree with that, the X clipboard spec is very clear on this, and most apps are now in compliance. Mixing them together is what Qt used to do, and people found it very confusing when they couldn't figure out what was going on with the clipboard.
I though you wouldn't ;) As you pointed out, if we can't use text selection to pass data via PRIMARY (because Windows apps don't allow this) then it follows that we should only use CLIPBOARD. But when I select and copy text from Word, I want be able to paste it into my xterm! I find this to be a common complaint.
I guess in Wine we have been simulating the selection of data into PRIMARY by assuming that if you copied data into the clipboard you probably selected it.
Your right thought, Wine apps may be somewhat unique but at the end of the day its behaviour is non-standard. What does everyone else think? This is one area that most people will have an opinion :)
And here's mine ... :-) I think Mike's right in that CLIPBOARD only should be used unless the actual visual text-selection itself can be hooked to use PRIMARY (which it seems probably can't happen in the general case). However I agree with you that people will want this to work how *they* want it to work, and the "Right Way" purists can go take a running jump. Or to put it more constructively, I think this should be configurable, presumably in the config file. I think as with all such things, the user is always right. BTW: I can envisage one day there being built-in Wine configuration and support in KDE and other all-for-one,one-for-all window managers - this sort of behaviour is likely to become a tick-box in a KDE configuration applet at some point just like every other little GUI tweak has become. Which is cool of course, I would like to control behaviour of the win32 support layer in the same place as I control behaviour of X11-native applications - so clipboard, mouse, keyboard (etc) should be as configurable as possible, not forced to be as "correct" as possible according to any one person's definition. Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/
I think Mike's right in that CLIPBOARD only should be used unless the actual visual text-selection itself can be hooked to use PRIMARY (which it seems probably can't happen in the general case). However I agree with you that people will want this to work how *they* want it to work, and the "Right Way" purists can go take a running jump. Or to put it more constructively, I think this should be configurable, presumably in the config file. I think as with all such things, the user is always right.
Well, I'm not bothered enough to start a flamewar over this. Suffice to say that the opposing view to that stance is that introducing "unbreak me" prefs just clutters the UI and makes things more confusing and less usable for the 95% of people who don't tweak the defaults.
BTW: I can envisage one day there being built-in Wine configuration and support in KDE and other all-for-one,one-for-all window managers
Most likely 3 things will/should happen: 1) Windows installed control panels integrated with the users desktop environment (ie quicktime control panel etc) 2) Wine control panel applets for configuring wine itself, I'd guess written using Win32. 3) Possibly desktop environment specific wine configuration applets, ie a kde-specific one, a gnome specific one and so on.
- this sort of behaviour is likely to become a tick-box in a KDE configuration applet at some point just like every other little GUI tweak has become.
Yup, which is why i use gnome2 now :/ The Klipper applet has a similar "please break me" tickbox so users who got used to having clipboard and primary mixed didn't have to adjust their habits when Qt3 came out. For everybody else, it's just another setting to accidentally toggle then wonder why their clipboard no longer works right, and to slow them down, clutter the ui etc
Which is cool of course, I would like to control behaviour of the win32 support layer in the same place as I control behaviour of X11-native applications - so clipboard, mouse, keyboard (etc) should be as configurable as possible, not forced to be as "correct" as possible according to any one person's definition.
I think adding XSETTINGS support to wine would do this, but as xsettings will probably be at some point replaced by a desktop neutral configuration mechanism I doubt there's much point until the whole thing has settled down. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
You may be able to hack some of the controls to support text selection but you won't be able to do it for the general case. For example this wouldn't work in Word. So I don't see this working. In fact it could break assumption made by the application. In my opinion, the only way to copy data from a Windows App to X is via control-c/Clipboard API.
Yes, true
In Windows, to copy data you generally need to select the data (Under X this would grab the PRIMARY selection) and then hit control-c (Under X this would grab the CLIPBOARD selection).
In think we should always be grabbing both PRIMARY and CLIPBOARD and releasing them when we loose either (ClearAllSelections=1). This seemed to be the least confusing for many users as well.
I don't agree with that, the X clipboard spec is very clear on this, and most apps are now in compliance. Mixing them together is what Qt used to do, and people found it very confusing when they couldn't figure out what was going on with the clipboard.
I think the old standard interface is good (select to copy, middle-click to paste) and generally consider apps that don't support it to be broken. I find it to be much easier to use than the Windows/Mac method which requires using menu items to copy text. I didn't believe the claims that Linux would suffer from widespread adoption by Windows users, but it seems that it is happening. At the very least, Wine should be configurable to work either way. I want all clipboards to use PRIMARY, because that is the behavior that I am used to. I don't care what some standards body claims is correct (at least not when it only affects how I use my computer, and not how my computer interacts with other computers). I would like to be able to select text in a window and then paste it into a Wine program, which can not be done with CLIPBOARD (or at least it is not the standard behavior of programs right now). I also want to be able to paste anything I cut/copy from Wine programs by middle clicking. Just because Windows has a worse user interface than Linux doesn't mean Wine has to follow. Ideally, I would also like to be able to paste by middle clicking. Since Windows does not generally use the middle mouse button, it should not cause problems for Windows programs to lose the middle button. But that is a less important feature. James
On Wed, 12 Feb 2003, James K Whiting wrote: [...]
Ideally, I would also like to be able to paste by middle clicking. Since Windows does not generally use the middle mouse button, it should not cause problems for Windows programs to lose the middle button.
Microsoft Word does... Plus, like setting PRIMARY on selection, 'stealing' the middle-button seems like it could be hard to implement so that it works in all applications. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner
I think the old standard interface is good (select to copy, middle-click to paste) and generally consider apps that don't support it to be broken.
Sure. Unfortunately it appears impossible to "unbreak" wine in this respect, as Windows apps will never consistantly notify the system when text is selected.
At the very least, Wine should be configurable to work either way. I want all clipboards to use PRIMARY, because that is the behavior that I am used to.
Well, that's the road that leads to prefs bloat, but that's another issue entirely.
I don't care what some standards body claims is correct (at least not when it only affects how I use my computer, and not how my computer interacts with other computers). I would like to be able to select text in a window and then paste it into a Wine program, which can not be done with CLIPBOARD (or at least it is not the standard behavior of programs right now).
Well that's kind of hard without breaking other programs. If I copy something to CLIPBOARD then select some text in PRIMARY, and press Paste in a wine app, which takes precendence? Most users would expect CLIPBOARD, especially if they were used to Windows. Trying to explain why the "wrong thing" was pasted because they selected some other text in the meantime is really really hard, I've tried. As a personal thing, I'd note that if you want you can install a clipboard mangler, but knowingly breaking agreed on standards simply because of what somebody is used to just causes problems for new users when it doesn't work how they expect which doesn't seem fair to me.
I also want to be able to paste anything I cut/copy from Wine programs by middle clicking. Just because Windows has a worse user interface than Linux doesn't mean Wine has to follow.
Again, stealing PRIMARY in this way tends to break other apps, although it's not quite so severe this way around, as people don't tend to keep stuff lying around in PRIMARY.
Ideally, I would also like to be able to paste by middle clicking. Since Windows does not generally use the middle mouse button, it should not cause problems for Windows programs to lose the middle button. But that is a less important feature.
It's pretty hard, if not impossible, to implement this in a consistant way (ie works for everything). Anyway, what Wine does currently is incorrect but as it doesn't cause dataloss in CLIPBOARD (as stealing the selection on select would do), it's not a major issue.
participants (6)
-
Francois Gouget -
Geoff Thorpe -
James K Whiting -
Mike Hearn -
Mike Hearn -
Ulrich Czekalla