[Annoyances] X-Windows Copy & Paste

[George]

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.

What you're proposing is a different behaviour to be learned on an app-by-app
basis.

> the whole point of this excersize is to make cut-n-paste EASY and
> FUNCTIONAL for new users.  to do that one needs to be able to answer
> questions like 
> 
> 'how do I copy text?'

"Press Ctrl-C or select Edit/Copy from the menu and that should work
anywhere" should be the correct answer.  If that doesn't work then the
applications should be fixed.

> 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?

> 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.

George

-- 
George <jirka at 5z.com>
   This book fills a much-needed gap.
                       -- Moses Hadas (1900 - 1966)