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

List:       kde-usability
Subject:    Re: Selection-to-Clipboard Inconsistencies
From:       Art Carney <greencarrots () nospammail ! net>
Date:       2004-06-05 16:48:39
Message-ID: 200406051248.39652.greencarrots () nospammail ! net
[Download RAW message or body]

On Friday 04 June 2004 01:05 pm, Jamethiel Knorth wrote:
> 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.
>


I hope that your proposal isn't adopted. Automatic middle copy from a keyboard 
selection is very annoying when I have something in the X clipboard.
_______________________________________________
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]