Re: 6 API-ish issues

[Owen Taylor <otaylor redhat com>]

Karl Koehler <koehler or uni-bonn de> writes:

> Hi ,
> 
> This issue about whether focussing an entry should 
> take PRIMARY is really getting hot. I'm afraid I'm heavily biased, too, 
> havin the following in mind :
> a) select some  text
> b) clear entry
> c) paste this text into entry
> Using the clipboard, this is easy: a) is select and put into clipboard,
> and c) restores from the clipboad; but requires extra key-presses.
> I know some people who love this on windows; I don't.
> With PRIMARY only, this is also clearly possible if focussing the entry
> in b) does not take the selection. In emacs-like entries, type ^a^k
> ( cursor to front, delete-to-end-of-line ) to do this .
> Maybe one can assign a key to "delete content of entry".

I think this case is a fairly good demonstration of why PRIMARY is 
hard to use in some cases.

It only works for you at all because you know ^a^k. The typical
way to replace the contents of an entry for most users is to select
it's contents. (GTK+-1.2 had right-drag to select without taking
primary, but it's not like aa lot of people ever figured that
out, not to mention the fact that it prevents context menus.)

A clipboard user would do:

 - Select text
 - hit C-c
 - triple click on entry (or click on entry and type C-a)
 - hit C-v

Which can be done easily with one hand on the keyboard and one on 
the mouse. While, with PRIMARY and emacs keybindings, you have to do:

 - Select text
 - Click on entry
 - Type C-a C-k (moving hand back to keyboard from mouse for the C-k)
 - Middle click (moving hand back to mouse from keyboard,
   probably bumping the mouse enough you have to realign it with
   the entry.)

There are certainly cases where PRIMARY does provide an easier
interface... e.g., highlight URL in emacs, middle paste into
anywhere in a mozilla window. But considering that the worst
that happens with CLIPBOARD is that you need a few more keystrokes,
while with PRIMARY, you sometimes need a lot of gymnastics or
advanced planning, I think we need to favour CLIPBOARD where
there is a conflict.

> I have not understood how PRIMARY can still work as Cut&Paste system
> for a widget if it takes PRIMARY on getting focus; maybe somebody can
> enlighten me ?
> If I have two entries, and want to append some text of one into the other,
> how would that work ( assuming that positioning the cursor requires
> having focus ) ?

Clicking on an entry to focus it doesn't select the contents, just tab
in, or hitting a mnemonic to focus it.

> Because if is does not, one could keep the paste-feature, silently,
> and do the highlighting without touching the selection...

I hope everybody agrees that if you have a highlighted-but-not-PRIMARY
state, it has to be visually distinct from the PRIMARY state. 
As mentioned above we had such a state in GTK+-1.2, but got rid
of it for GtkEntry and GtkTextView because:

 - The mouse binding to select in that state got reused for context menus.
 - We didn't have a spare color to use for it.
 - It made the code simpler
 - It kept the API simple (there was no API for highlighting without
   selection in 1.2.)

Plus, I think users that don't know about PRIMARY would be rather confused
when highlighted text was sometimes one color, sometimes another for
no apparent reason.

Regards,
                                        Owen