[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    RE: Selection-to-Clipboard Inconsistencies
From:       "Jamethiel Knorth" <jamethknorth () hotmail ! com>
Date:       2004-06-04 17:05:09
Message-ID: BAY7-F89MXgfTZ4yrTc00058ba7 () hotmail ! com
[Download RAW message or body]

Okay, I still haven't gotten any reply about this. I think it's fairly 
important, so I'm going to go ahead on it. If nobody comments otherwise, 
I'll be sending the following recommendation to the xdg mailing list (the 
place where they work on freedesktop.org specifications) this Saturday 
night:


---- Begin What I Would Send ----

There appears to be no current standard for how to treat keyboard 
selections, as opposed to mouse selections, in regards to the cut/copy/paste 
buffer. I would like to recommend the following three additions to the 
freedesktop.org specification on treatment of cut/copy/paste buffers. [1]


The following paragraph should be added after the summary of the proper 
behavior and before the bulleted list describing the problems with the 
improper behavior:

Regarding how keyboard selections, no standard has yet arisen. To clarify 
usage, selections made by the keyboards should be treated the same as 
selections made by the keyboard. The PRIMARY selection is treated as the 
current selection, not the selection last made by the mouse.


The following point should be added to the list of things application 
programmers should do to support this standard (likely as the second point):

- selections made using the keyboard should be treated the same as
   selections made using the mouse


There is likely a need for some reference to keyboards in the historical 
section of that document as well.


For examples of where this is currently being done differently:

OpenOffice: treats mouse and keyboard selections the same.
Mozilla: treats mouse and keyboard selections the same.
Qt Widgets: ignore keyboard selections.
GTK Widgets: fail on both keyboard and mouse selections.
AbiWord: treats mouse and keyboard selections the same.
KWrite: treats mouse and keyboard selections the same.
The GIMP: fails on keyboard selections.

This is a significant inconsistency problem in how the cut/copy/paste buffer 
is treated, and it is apparently not addressed anywhere.

---- End What I Would Send ----


I would also like to be able to note how KWord handles this. If anyone can 
inform me on that, it would be nice. If anyone disagrees that this is a 
usability issue, they should probably note that as well. And, if anyone has 
comments on what I am sending, they should probably give some notice before 
I send this Tomorrow night.


>From: "Jamethiel Knorth" <jamethknorth@hotmail.com>
>Date: Thu, 03 Jun 2004 02:03:40 -0400
>
>This was something I had noticed before, but not thought much of. I checked 
>again, and it is still there.
>
>Selecting text is inconsistent in how it goes to the clipboard. In some 
>programs, selecting text using the keyboard allows it to be pasted with the 
>middle mouse-button. In others, selections made by the keyboard do not.
>
>In all Qt widgets, selecting text with the keyboard doesn't replace the 
>text in the buffer.
>
>In the KWrite widget, it does.
>
>I personally prefer to have the selections made by keyboard be sent to the 
>buffer. I think it is more consistent to have the middle mouse-button paste 
>whatever was last selected, not whatever was last selected by the mouse.
>
>Some standardized behavior should be chosen, to enhance consistency on the 
>desktop.
>
>I would much prefer to change Qt, as KWrite is more reasonable and is 
>following the standard. At the least, Mozilla and OpenOffice both perform 
>the same (selection by keyboard replaces the buffer), and we know for a 
>certainty that many users will have those applications in their desktop.
>
>As far as I can tell GTK apps (I tried gAIM, gFTP, and AbiWord) are just 
>flat-out broken. Selecting text with either the mouse or the keyboard 
>erases the buffer but doesn't replace it. AbiWord performs the same as 
>OpenOffice for text selected in the body of the document, but not in the 
>common GTK widgets.
>
>I didn't get to test KOffice, as it's broken at the moment for me. If 
>anyone can find some other examples of how this is used, that would be 
>good. I can't find any motif applications on my computer to test them, 
>although that's not too important as they are really fading away. If anyone 
>has a GNOME installation to work on, it might be good to check how some of 
>the GNOME programs handle this.
>
>I looked at what was up on freedesktop.org and saw nothing about this. They 
>mention middle-mouse-button paste, but don't seem to state the behavior for 
>text selections in the matter, only for the separation between selecting 
>text and giving explicit copy/cut commands. Depending on what other people 
>have to say here, we should send something along to freedesktop.org as 
>well.

_________________________________________________________________
MSN 9 Dial-up Internet Access fights spam and pop-ups – now 3 months FREE! 
http://join.msn.click-url.com/go/onm00200361ave/direct/01/

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]