[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Back to the clipboard, part II.
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2002-10-31 10:26:26
[Download RAW message or body]


 CC-ing kde-usability@ as that's maybe the list where this discussion belongs.

 This mail is going to be a bit longer, as I'll try to explain how the system 
works, and I'll also repeat some of the things Havoc said.

 Both the selection and clipboard are implemented using a mechanism which X11 
calls 'selections' (and clipboard is called CLIPBOARD there and selection in 
the non-X11 sense is PRIMARY). They're completely separate, and there's only 
one of them (there's one PRIMARY and one CLIPBOARD, you cannot have e.g. two 
PRIMARY selections). Also, as usually, nobody really bothered to define how 
they work, Xlib reference doesn't even seem to bother mentioning CLIPBOARD, 
and ICCCM is pretty vague about the meaning of PRIMARY (section 2.1.1.1).

 ICCCM doesn't also describe CLIPBOARD from the users' point of view much, but 
I don't think there's any problem with CLIPBOARD - it's simply the thing that 
things are explicitly copied into (usually Ctrl+C, not simply only selecting 
text), and the contents are explicitly pasted (usually Ctrl+V, but not MMB). 
Qt1/2 didn't even follow this, as it was only using PRIMARY all the time, 
even for Ctrl+C/V. Since QClipboard changed in Qt3 to behave like other X11 
apps (=more reasonably), and had PRIMARY and CLIPBOARD separated, the only 
way to get the old behaviour is syncing PRIMARY contents into CLIPBOARD. I 
personally see no good reason for doing this, but I don't really mind - it's 
broken behaviour, but only from the user's point of view, technically it's 
ok.

 Now, here comes PRIMARY, which will be a problem. I couldn't find in any 
"oficial" X11 docs the definiton of its behaviour, only independent docs 
describing how apps should do it (e.g. [2] or [3]). They of course either 
don't go into sufficient level of details, or they contradict each other in 
the details. I personally consider the right behaviour to be the table in 
[3], which the small change that the first row shouldn't say 'text 
highlighted with mouse', but simply 'highlighted, not matter how'. If you 
asked, most X11 developers would probably say this is the way it should be, 
as it makes things quite simple to implement, and it's one possibility how we 
can do it "right".

 The problem, of course, is that I don't think users would share this opinion. 
From the users point of view, it means that there is only one selection, THE 
selection, so in the whole X11 session, there's exactly one place where a 
text is selected. For example, Gtk+ apps do it this way (Gtk+1 apps have a 
small exception of the 'almost selected' gray selections). E.g. if you run 
gedit, write something, select it, then open it's configuration dialog and 
select one lineedit, the selected edited text will be unselected. If you 
select something in one Gtk+ app, and select something in another one, the 
first thing gets unselected. If you select something, and then click 
somewhere in order to unselect, MMB no longer works. The only selected text 
is simply THE selection, even if you select the text using Shift+arrows.

 Now say I'm reading some text in text editor, highlight one sentence (e.g. so 
that I can find the sentence quickly again), go to another texteditor, do 
some work, possibly selecting something, and when I go back to the first 
texteditor, the sentence is unselected. Not really pleasing, especially if I 
as Joe User have no clue about PRIMARY. This also means that 'copy link 
location' this way shouldn't set PRIMARY, as the link wouldn't be the 
selection (I couldn't find any example of this feature in Gtk apps though). 
Moreover I remember a bugreport, where somebody complained that opening a 
dialog which has a lineedit preselected changes PRIMARY.

 I also tried with MS Windows. There's usually one selection per application, 
so the problems with unselecting usually don't happen (unless you do 'New 
Window' in IE, they it looks like two apps, but in fact it's only one, having 
only one selection). Lineedits in config dialogs unselect as soon as they 
loose the focus. I also noted that selecting something in Notepad and 
selecting a lineedit in its config dialog doesn't unselect the edited text. 
Not that the selection in Windows matters much, as it's simply a visual 
representation of a selected text, and nothing more.

 In KDE/Qt right now, we probably have all possible styles mixed, as a legacy 
of all the hacks trying to workaround the old broken QClipboard behaviour. 
Selected text is not THE selection. If you select a lineedit and unselect, 
MMB still works. If you select e.g. in Kate using Shift+arrows, MMB won't 
paste that. In many cases, selection doesn't go away if you select something 
somewhere else (most Qt widgets do, I remember it was fixed before KDE3.0 in 
Nurnberg). If a lineedit looses focus, it unselects (but as said above, it 
remembers the selected text). Also 'copy link location' sets PRIMARY without 
showing it visually as the selection.

 I basically see two solutions:

 First one is the 'selection is THE selection' way of doing things. Should be 
easy to implement, consistent (also with other X11 apps, hmm, besides those 
not getting it right, or having their "right" different :-/ ). The problem 
here is the unselecting in other app, which maybe isn't that big problem, and 
the fact that 'copy link location' wouldn't work. We could probably loosen a 
bit the requirement and allow things like this 'copy link location' to set 
the selection (=PRIMARY) too, without having any visual representation. For 
apps which wouldn't set both CLIPBOARD and PRIMARY on such actions, there 
could be a Klipper action doing one time CLIPBOARD->PRIMARY sync (such 
syncing wouldn't cause any problems). The problem with autoselecting changing 
PRIMARY would remain, if it's actually a problem (PRIMARY is meant to be 
short-lived).

 The other possibility I see is saying that PRIMARY is something the user 
explicitly selected (maybe even only with the mouse, as Shift+arrows 
selection and MMB later isn't a thing I'd expect anybody to do). Selection as 
'the highlighted text' would be something independent, and it could be even 
done the MS Window style (having more selections, lineedits unselecting on 
focus out,...). In this case, one wouldn't of course know what PRIMARY is, on 
the other hand, PRIMARY is supposed to be short-lived. The biggest problem 
here would be beating TT to make necessary Qt changes, and beating everybody 
else to use it the same way, or living with the fact that we again do it 
differently than the others. I'm not sure if others would agree to this kind 
of behaviour, especially the die-hard old-fashioned X11 people wouldn't like 
it. But as far as I can say, this would be only breaking the common 
convention, as I'm not aware of anything forbidding this kind of behaviour.

 I forgot, there's actually third option - leaving it as it is. Easiest one.

 Erm, whatever. Did I miss something important?


[1] ICCCM - http://tronche.com/gui/x/icccm/  (section 2 mainly)
[2] http://www.freedesktop.org/standards/clipboards.txt
[3] http://www.jwz.org/doc/x-cut-and-paste.html

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
[prev in list] [next in list] [prev in thread] [next in thread]