Clipboard for the dummies

David Faure david at mandrakesoft.com
Fri Nov 1 14:01:26 GMT 2002


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 01 November 2002 12:03, Lubos Lunak wrote:
>  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
I think this would confuse me, as a user. It means that one can NOT use
LMB/MMB to paste something into a dialog box which autoselects a lineedit
when opening. To detail this: you LMB something, go to another app, open
a dialog, it autoselects a lineedit -> bingo, you can't MMB your stuff anymore.
IMHO if other selections than those made voluntarily by the user are being copied,
it makes LMB/MMB quite unusuable.

> - if there's nothing selected, MMB won't do anything
This doesn't sound too good for usability either. Often I'm glad that although
I clicked somewhere (in khtml or konsole) and lost the selected text, the
selection is still there, so it can be pasted with MMB into another app.
What would be the advantage of this behaviour?

> - 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 closed, MMB 
> will paste nothing
A combination of the above two drawbacks :)

> - if you select something in one app, previous selected text is unselected, no 
> matter where it was, even in other app (this a bit conflicts with the 'if you 
> don't know about MMB, it won't get in your way at all' claiming)
Indeed. Windows users might expect that it's possible to select text in different
windows/apps at the same time.... This sounds like quite a minor issue though,
my personal opinion is that it's not worth a setting.

>  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)
That's what I did in KWord, but I'm starting to come back on this decision.
(The reasoning at the time was: only text selected with the mouse can be pasted
with the mouse. But that's not how most people think, and there are things like
"copy link location" to complicate it all). My new reasoning would be more
along the lines of: what the user _voluntarily_ selects gets copied.
So mouse + keyboard put the selected text into the "selection",
but auto-select by lineedits wouldn't.

> - when there's no selected text, selection is still remembered (the last valid 
> selection)
Yup, I think that's a good thing for usability.

> - this is why Qt lineedits unselect on focus out, while Gtk ones don't
Hmm, what's the relation? Well, you mean that Gtk lineedits can't do that,
since that would lose the selected text, but I don't really see why Qt lineedits
have to do it either. Ok, doesn't matter.
(Note: they unselect on focus-out-to-another-widget, not when alt-tabbing,
this confused me a little bit at first, when trying to reproduce this).

> - when a text is selected elsewhere, previously selected text stays selected
Really? where? In my experience that's not true, all Qt/KDE apps obey the
X11 principle that there's only one selection - so when a selection notification
occurs the previous selected text is unselected... Works with QTextEdit, QLineEdit,
khtml...

> - explicit actions like 'copy link location' set selection, even if there's no 
> text selected
Said that way it sounds inconsistent... But the goal is simply to be able to paste
the link location with MMB, which makes sense IMHO (in the "selected with mouse,
pasted with mouse" logic, in particular). And of course it must be possible to
paste it with Ctrl+V too, for 'clipboard-only' users.

> - let's ignore the KDE2 style behaviour of mixing clipboard and selection, 
> which e.g. Emacs uses too, according to Havoc
... and which really annoys me in emacs :)

>  When all this summed up (except for the clipboard and selection mixing), it's 
> the other solution I included in the previous mail (let's call this variant 
> the 'Joe User solution'). Both of the extremes seems most consistent 
> solutions to me, but we can even choose something inbetween.
Hmm, what's the "Joe User solution" exactly? All I can gather from the "part II" mail
is that there would be support for having multiple "selected texts" at a given time,
i.e. no automatic "unselecting when a new selection is made in another app".
IMHO it makes sense to support this _only_ if people (e.g. ex-Windows users)
complain about this "auto-unselect" behaviour. However I wonder if it's really
a big annoyance (e.g. my wife, too used to Windows, asked for double-click
in KDE, but surely never noticed the auto-unselect issue).

>  I'd personally like the Joe User way of doing it, as I find this one the best 
> from the users point of view, and certain features of the X11-pure style can 
> be seen as misfeatures, but I expect a lot of people wouldn't like this and 
> would want the X11-pure style solution. Maybe we could have a setting for 
> either the Joe User way or the X11-pure style for the old fashioned ones, but 
> we should have a one, at most two ways of doing it - right now, all of the 
> four points above are true in some KDE/Qt apps/widgets and not in others.
Yes.

>  PS: Just in case you noticed, the recent qt-copy snapshot has a QLineEdit 
> bug, which prevents MMB pasting from working. Already reported to TT.
BTW I applied the fix to qt-copy, and I got the answer from TT that it's been fixed already,
AFAIK Dirk is evaluating a new qt-copy snapshot as we speak.

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
Get the latest KOffice - http://download.kde.org/stable/koffice-1.2/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9wok372KcVAmwbhARAi2GAKCnkMPvbC3LiTeeFdAS5bCim2mSdACeN8oO
ElulrlHEFnCyhDbFZcL9irs=
=B7jj
-----END PGP SIGNATURE-----





More information about the kde-core-devel mailing list