[Annoyances] X-Windows Copy & Paste

[George]

On Tue, Aug 19, 2003 at 12:42:20PM +0100, 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.

And right click menus.

> 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
>         users have to read the documentation to know about the
>         shortcuts, and most users never do that.  In applications with
>         menus, the user can look at the shortcut listed beside the menu
>         option, but xterm, pterm, etc don't have such menus.
>         
>         I don't think we should be aiming just to make it possible to
>         use the clipboard - we should be aiming to make it easy.

Seems to work in windows though.  People expect the same shortcuts that are
used in the apps with menus to work elsewhere, and they generally do.  It is
not a secret.  Selection modifying your clipboard would be a very secret
thing.  Since it would only do this in some cases, it would seriously confuse
people.  I can imagine being quite confused myself by this as I would never
expect it.  If I could only select somewhere then I'd never imagine that it
would copy the selection.  That's why most people never discover the
select/middleclick thing.  My mom used linux for about 5 years now and never
discovered it on her own.  She does however try to use the same keybindings
that copy/cut/paste in some apps in places where they aren't bound and gets
confused (and I get phonecalls that her computer is broken).  Even openoffice
gets things wrong and the keybindings don't always work and things don't
always appear in menus.

You can also add a rightclick menu to everywhere where you have text to
select to have a mousable only way of copying.

>     ii) It requires the key shortcuts to be captured by the terminal - I
>         know that the developers of pterm are always concerned about
>         capturing any more keys than neccessary because it risks
>         breaking applications running in the terminal by stopping them
>         receiving key presses the user might have intended for them.
>         
>         Key shortcuts, like menus, aren't always appropriate.

You have to capture some keys.  True that Ctrl-C is not the best for use in
terminal.  But that's ONLY the terminal case, you'd be proposing to put
select whacks clipboard behaviour in other read only text scenarios.

And a terminal that is user friendly needs to have a menu anyway.  Otherwise
you rely on user knowing some key combos anyway so you can't say that
"learning" some key combos would be bad for the user.

> The problem, I think, is that it isn't possible to have the implict
> copy-on-drag UI metaphor as well as the explicit metaphor in the same
> desktop at the same time without keeping them entirely separate (and
> requiring all applications to support both), or running into confusing
> UI messes where applications don't interoperate as users expect them
> to.

I'll quote you for you to perhaps see what is the best solution:

"and requiring all applications to support both"

> The solution proposed by John Meacham is the best compromise I've
> seen so far.

And this is the confusing UI you were talking about just above.  It is
confusing to me and I'm computer literate I would say.

If you use that proposal you are suddenly requiring all apps to follow some
standard.  Why not just follow the standard of supporting both and keeping
them separate.

Also I see no great harm being done if an app supports ONLY explicit
copy/cut/paste and not the PRIMARY.  The PRIMARY is more of a special kind of
thing for "power users"

> An alternative would be to try and move to one or other of the schemes
> entirely, and get rid of the other.  Since some developers feel strongly
> that one way is best, and some the other, this isn't going to happen.

What would this achieve.  Why not just support both since we pretty much
already do in most apps.  Supporting CLIPBOARD in an explicit copy/cut/paste
scenario is the more important one of the two.  So an app should be required
to support that, and support PRIMARY (that is completely separate!) as an
extra.  You can see this in Wine then as you say where they don't support
PRIMARY at all.

> Does anyone know of any User Interface professionals who've done a study
> of this problem?

I would say Apple likely did a lot of user testing on this and they seem to
use the explicit copy/cut/paste method.  Windows does this as well.  I would
bet both did user testing on this.

George

-- 
George <jirka at 5z.com>
   You have the right to food money providing of course you don't mind a little
   humiliation, investigation and if you cross your fingers rehabilitation.
                       -- The Clash