On Sun, Aug 25, 2002 at 10:15:47AM -0400, Maks Orlovich wrote: > Not really, it just means that Mozilla sets both PRIMARY (Unix > select/middle-click keyboard) and CLIPBOARD(Ctrl-C/Ctrl-V clipboard) while > KDE only sets CLIPBOARD ; both behaviosr look in line with the clipboard > behavior agreement to me (see > http://www.freedesktop.org/standards/clipboards.txt);
Okay then that means that gnome-terminal et al are bugged because according to that document: - middle mouse button should paste PRIMARY, never CLIPBOARD Which they do because using Copy Link Location with them works fine with konqueror and then using the middle mouse button. So basically we're back to inconsistent behavior. Except this time without the help of a helper application to let me set the PRIMARY (pressing Ctrl+Alt+V with klipper running and selecting what I just copied) there is no way to paste it. As far as I'm concerned this is a step back. Even if selection copying was confusing to some users at least you could always paste by hitting the middle mouse button. Now you can't. So all we've done is traded one confusing interface for another. That document makes for situations where you will not be able to paste in apps that only support the middle mouse button. There are two ways of fixing this: Method 1: Requires changes in the window manager so it could be made to work with minimal amount of effort: a) disable selection copying by default in applications that support CLIPBOARD. Provide an option to allow power users to re-enable this behavior. Preferably in the window manager's configuration. b) synchronize CLIPBOARD and PRIMARY. Provide an option to disable this. Now since selection isn't putting anything PRIMARY in apps that support CLIPBOARD, CLIPBOARD won't be changing. Which means you have to explicitly put something in the CLIPBOARD in those apps. For the legacy apps you can still use selections to copy. But that is their only interface. That's just the way they work. Meanwhile you've provided options to the user so if they don't like the default behavior they can change it. Now before you say "it's inconsistent that some apps copy on selection and some don't." No it's not. Those are legacy apps that don't provide any other way of copying. They will be in an ever decreasing minority. And even in Windows some apps have selection copying (mIRC comes to mind). But they are a minority and users can deal with this just fine. Method 2: Requires changes in all the legacy apps (yeah right what a pain in the arse): Make middle click paste CLIPBOARD or PRIMARY whichever is newer. This is what gnome-terminal and xterm appear to be doing now. Ctrl+V et al would still only paste the CLIPBOARD. But power users who are using the middle click would have a consistent method of pasting. And users using the middle click to paste into apps that only have that interface would have a way to paste CLIPBOARD. This is probably the better way of doing it but it takes more work because you have to fix all the apps out there. I certainly don't care, nor do I think most users do, what some person at freedesktop.org (or whoever it was that wrote that) says how the clipboard should work. I just want it to work. And as it stands now it works less than it did before. > the reason this doesn't > matter in HEAD is that you can configure the clipboard code in kdelibs to set > PRIMARY on CLIPBOARD being set, AFAIK. You used to be able to do this with klipper but since 3.0.1 it's been disabled: http://lists.kde.org/?l=kde-core-devel&m=101699731318404&w=2 Re-enabling this doesn't reliably solve the problem. Now if the feature worked right it would make my clipboard behave the way I expect it to... Did they move this feature somewhere else in HEAD? The funny thing is this is all really irrelevant. khtml (that's the part of KDE that actually implements copy link location) already seems to be trying to update PRIMARY *AND* CLIPBOARD. Granted my understanding of QT is limited. But that's what appears to be going on here: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/khtml/khtml_ext.cpp?rev=1.45&content-type=text/vnd.viewcvs-markup Take a look at slotCopyLinkLocation(). The code appears to be emulating a drag. And the comment even says it's updating both clipboards. Which means the KDE developers aren't intending to follow the standard you gave me. AND there is a bug in KDE because this doesn't work right anymore. Further open up kedit. Type something in. Now select it with the keyboard (yes using the keyboard is important here). Now drag over some text in some other app. Now go back to kedit. Choose edit Copy. Go to Eterm or rxvt. Hit the middle button. You're going to get whatever you dragged over just now. Then go back to Kedit. Unselect and make a new line. Choose Edit paste. You get what you copied in kedit. This is exactly the type of behavior that your standard expects. Now let's do something similar with konqueror. Drag over something. Go to konqueror and choose Copy Link Location. Now try to paste with the middle mouse button in Eterm. You get *NOTHING*. That's because Konqueror is trying to put the text in PRIMARY but botching the job. Which means IMHO it's violating the standard worse than changing PRIMARY and CLIPBOARD because now it's whacking whatever is in my PRIMARY and not even replacing it right. Now anyone still wanna argue with me about this being or not being a KDE bug? -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org If your love has no hope of being welcomed do not voice it; for if it be silent it can endure, a guarded flame, within you. - The Wisdom of the Sands
