[Annoyances] X-Windows Copy & Paste

[John Meacham]

On Tue, Aug 19, 2003 at 12:49:55PM -0700, George wrote:
> On Tue, Aug 19, 2003 at 12:14:32PM -0700, John Meacham wrote:
> > On Tue, Aug 19, 2003 at 03:35:13PM +0200, Kevin Krammer wrote:
> > Content-Description: signed data
> > > On Tuesday 19 August 2003 13:42, Richard Boulton wrote:
> > > > On Tue, 2003-08-19 at 12:09, Waldo Bastian wrote:
> > > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > > Hash: SHA1
> > > > >
> > > > > > this doesn't affect people who like everything to be all GUIy with
> > > > > > edit menus and whatnot, it is so apps without explicit edit menus
> > > > > > can co-behave with apps that do have them in a sane fashion.
> > > > >
> > > > > Apps without explicit menus can still use explicit key shortcuts.
> > > >
> > > > Two problems with that:
> > > >
> > > >      i) It requires users to know about some secret method for
> > > >         putting the copy into the clipboard. Secret in the sense that
> > > 
> > > Without it the user has to know about the secret that selecting anything 
> > > will destroy his clipboard content.
> > But this is a single 'secret' global to the enviornment.
> > the other secret was a keybinding which had to be learned on an
> > app-by-app  basis. 
> 
> The solution then is to standardize the keybindings.  It is really stupid to
> have different apps have different keybindings for the same exact things.
> Especially for Cut/Copy/Paste there seems to be quite a consensus on the
> keybindings, so I don't see the problem here.

standard keybindings would be a perfectly acceptable solution. better in
fact. my proposal only applied when apps, for some reason or other,
cannot use standard keybindings or menus. Pretending such apps don't
exist is counterproductive, my only concern is interoperability, i.e.

it shall be possible to transfer text from any app to any app via
selections.


> > right now, there is no good answer. with app-specific keybindings the
> > answer becomes even more unsatisfying, oh.. look in the man page.. or if
> > it doesn't have that.. look at the source code..
> 
> There shouldn't be "app-specific" keybindings.  It still seems to me like
> you're trying to solve the wrong problem.  "xterm" and other non-gui
> terminals and apps tend to completely ignore the user interface and have
> everything (not just keybindings) in an per-app way.
> 
> One of the reasons why I don't use xterm is it's complete lack of UI.
> 
> > > If an application does not provide any obvious way to cut/copy it won't 
> > > occur to the user that he can cut/copy from there, like it would be on 
> > > systems without PRIMARY selection.
> > > 
> > > IMHO its more or less a decision by the application developer. If he does 
> > > not want to support both methods, he does not have to.
> > > If he wants to support both, he should do it in a way that lets other 
> > > developers make that decision for their applications.
> > Ack! this is what got us into this mess. 
> > 
> > This is what my proposal is trying to Allow. apps which only support one
> > type of cut-n-paste. 
> 
> And how does using CLIPBOARD with explicit copy cut and paste not address
> that issue?

this does address the issue and is a very good solution. my proposal
included this as a solution in fact. There was an exclusive or, if you
have an explicit copy/paste then nothing changes. (except to make sure
you are setting PRIMARY as well as CLIPBOARD on copy, but everything
does this anyway) If you have an app without explicit copy then you must
add it. or LESS PREFERENTIALLY do something else, but only if you have
very very good reason. I can understand that you feel that there is a
never a good reason not to add an explicit copy, but the universe of X
applications is large, and my primary concern is making sure that it is
interoperable with each other meaning that we must tell people that if
they wish their app to be able to cut-paste with other apps AT ALL, they
must provide a mechanism for copying to CLIPBOARD.

> > right now, it is impossible to get by with a single form of cut-n-paste
> > UI interface.  everyone must supply 2 UI mechanisms to be sure they can
> > communicate with everyone. my proposal would allow you to say, use your
> > wine apps (which just uses the clipboard metaphor) with xterm (which
> > just uses the mouse drag metaphor) or turn off the mouse-selection style
> > drags alltogether.
> 
> So you propose solving it by having different UI mechanisms in different
> apps.  How the hell do I know as a user that wine app is different from
> xterm?  The clipboard.txt does mention the selection PRIMARY thing as
> an "easter egg" for technical users.  Apps should then just support
> explicit cut and paste using the CLIPBOARD.  The PRIMARY thing can
> stay in as "an easter egg" that need not even be documented much.
> If PRIMARY is kept separate as it should be, then it does not interfere
> with apps properly using CLIPBOARD.

just saying PRIMARY is an easter egg doesn't work if there are apps
where it is the ONLY mechanism for selection/pasting. this is what I am
trying to fix. so that we MAY tell people it is an alternate method
which is never necisary.


-- 
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - john at foo.net
---------------------------------------------------------------------------