From kde-core-devel Thu Oct 31 10:26:26 2002 From: Lubos Lunak Date: Thu, 31 Oct 2002 10:26:26 +0000 To: kde-core-devel Subject: Back to the clipboard, part II. X-MARC-Message: https://marc.info/?l=kde-core-devel&m=103605998601617 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/