On Friday 01 November 2002 12:03, Lubos Lunak wrote:
> After talking to some people, looks like the previous mail was too
> complicated.

Unfortunately I missed it, I hope my reply is not too late.

[...]
> Definition of terms:
> clipboard - copied in using Ctrl+C, Ctrl+X, pasted using Ctrl+V
> selection - the thing pasted with MMB, copied by selecting some text

Could also call it "PRIMARY".

> selected text - selected text, I use a different term than 'selection'
> because they're not always the same (again, it's inconsistent, and we n=
eed
> to decide)

Because it's not quite clear if PRIMARY is used for non-text data at all
(and extending the use of PRIMARY to any data would make even more
clarifications of the semantics necessary) I'd refer to the subset of
a component's data which the user selected for commands to be applied
on as "current selection" (of the component) even though one of the docum=
ents
identifies the current selection with the global PRIMARY. This includes
"selected text" and "selected something"

[...]
> The most in-the-spirit-of-X11 way, which Gtk, xedit use, is like this:
> Selection is selected text, and selected text is selection (the ONLY
> selection). Which means:
> - selected text, no matter how selected, will be pasted by MMB
> - if there's nothing selected, MMB won't do anything
> - if you open a dialog with a lineedit which autoselects the text (i.e.=
 the
> default, but you can start typing whatever you want immediately), this
> becomes the selection pasted by MMB, and as soon as the dialog is close=
d,
> MMB will paste nothing
> - if you select something in one app, previous selected text is unselec=
ted,
> no matter where it was, even in other app=20

This "traditional" mode should be supplied by all clients by using
a configuration option of some sort, but may be disabled by default.
In the following I'm going to talk about variations clients _should_ IMHO
support apart from supplying "traditional mode".

> Other apps, including KDE apps, usually use a less consistent mess, by
> allowing one or more of the following:
> - only text selected by the mouse becomes the selection (i.e. not text
> selected by keyboard, or autoselected lineedits)

All text selected by the user explicitely should cause the client
to claim PRIMARY, including mouse selection, keyboard selection,
and selection commands. Text selected for user-convenience should
not cause PRIMARY to be claimed (such as a dialog selecting
the text of a line entry as you point out). (Just what David Faure said)

> - when there's no selected text, selection is still remembered (the las=
t
> valid selection)

This is a good addition, cool. I think clients may impose reasonable limi=
ts on
this feature or not support it at all as it may be very difficult to keep
track of the deselected data if the current selection was very large.=20

> - this is why Qt lineedits unselect on focus out, while Gtk ones don't
> - when a text is selected elsewhere, previously selected text stays
> selected

That's very nice. Clients should be encouraged to offer different
selection styles for selected text in focused components, selected
text in unfocused components and selected text representing
PRIMARY if they support this extension, even though it appears the
Gtk 1.2 scheme didn't work out so well.

Not offering this feature causes inconsistencies between applications
dealing with text and applications dealing with other document types
or data, such as a 3d modeler. In addition, loosing the "current selectio=
n"
of a component offering discontinuous text selection can be very=20
annoying, much more then in a simple scenario (where selecting
a range of text is a relatively quick task).

Offering this feature will cause _minor_ confusion if a distinctive
way to highlight PRIMARY is not supplied but I agree that it's
probably not too painful due to the common usage pattern of
PRIMARY.

> - explicit actions like 'copy link location' set selection, even
> if there's no text selected (I couldn't find any such action in any Gtk=
2
> app to test, Havoc?)

This is a very bad idea because it mixes two concepts
seperated cleanly to allow a clear mental model to form in the user's
mind. RMB-paste should be enough. (This feature could be optional
"for power users" if provided at all.)

[...]
> Maybe we could have a
> setting for either the Joe User way or the X11-pure style for the old
> fashioned ones,

:*)

On Friday 01 November 2002 21:34, Martijn Klingens wrote:
> On Friday 01 November 2002 20:46, Michael Brade wrote:
> > First of all, 100% agreed with all that David said, yes to all points=
=2E To
> > me the following is most important: only add something to the clipboa=
rd
> > if the user invoked the selection. _Never ever_ use automatically
> > selected things like lineedits in dialogs or the selections done by t=
he
> > autocompletion feature for Ctrl-V or MMB. Those selections are IMO no
> > real selections, just to be able to delete them with only one keystro=
ke
> > (Del, for example).
>
> That has a tiny downside though: if you _want_ that part in Selection y=
ou
> have to explicitly reselect it, or press shift-left, shift-right to for=
ce
> the selection to be a manual one instead. Or does ctrl-c also copy to
> Selection in this case?

Ctrl+c should copy the component's current selection to the clipboard
thus copying the highlighted text (claiming CLIPBOARD).
Triple-clicking should highlight the whole line edit and claim
PRIMARY for the text (if triple-clicking is supported).

kai
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability