Clipboard problems (yes, again)

[Lubos Lunak]

On Wednesday 30 October 2002 17:38, Carsten Pfeiffer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> On Wednesday 30 October 2002 16:52, Lubos Lunak wrote:
> >  Uhm, *cough*. Let's forget the fact that I am the one (hell, THE one)
> > fixing it. It's simply causing trouble. Big trouble, like freezing apps
> > (pre KDE-3.0 times). They're hard to find. If people had to choose
> > between
>
> But that was due to the bad QClipboard API and some bugs in both Qt classes
> and KDE apps due to that, no?

 Yes, the problems were mostly Qt bugs, which showed only because of Klipper's 
extensive clipboard polling. But the current one is a bit different, it's 
rather a bug in the system itself. Setting selection from clipboard is a 
weird thing to do, because you're usually supposed to set the clipboard from 
the selection (see the possible loop already?). In this QTextEdit case, when 
doing cut, first the clipboard was set to the selected text, and then the 
selected text was removed. But setting the clipboard set also the selection 
(the X11 selection), which caused clearing the selection in QTextEdit, and 
therefore there was nothing to remove. This is completely unexpected 
behaviour from the programmers points of view.

 This specific case could be fixed (even though it's probably more worked 
around than fixed). But there may be possibly other problems, I don't know. 
Rather than risking them, I find removing the feature a better solution. The 
only reason for this feature so far has been only 'the users are used to the 
old behaviour'. The old, inconsistent, KDE-only behaviour for which we were 
getting bugreports for KDE1/2. I simply consider annoying few users for a 
week until they get used to it worth avoiding all the possible trouble. You 
cannot please evebody of course, but even if it stays as configurable, we'd 
still risk getting bugreports that are caused by this yet don't suggest the 
relationship in any way (#48024 is a nice example).

> >  So either tell me why this should be done, so we can find some suitable
> > solution (which may even be me slapping self and saying 'stupid me'), or
> > I'll fix the problems the way I'll find most suitable. Or I can also just
> > leave the problems be. But the problem _is_ there, and I expect them to
> > be there even after fixing this one.
>
> The problem is cases like right-clicking on a link in konq and choosing
> "Copy Link Location". This should set both clipboard and selection. There
> are/were several apps setting only the clipboard and forgetting about the
> selection.

 This is the thing I mentioned in the first mail - the definition of 
'selection' is somewhat unclear. Strictly speaking, it shouldn't set the 
selection, because it's not the selection ICCCM suggests it to be. On the 
other hand, this is the only reason why it shouldn't be done, and ICCCM (as 
always) isn't strict about it. Maybe we should define selection as something 
you selected using the mouse (or maybe some special action like this copy), 
and not make any relation between it and selected texts in apps.

 In this copy link case, it would be probably better to fix the apps, 
especially now with the new QClipboard API, rather than doing the syncing 
automatically. As a fix on the Klipper level, IMHO it would be better to have 
an explicit action(shortcut) which would once do the clipboard->selection 
copy.

 To sum it up a bit:

 I'd ideally like to see all syncing gone, but the only thing I really don't 
want is the automatic against-the-stream setting clipboard->selection. 
Keeping the syncing option in KClipboard as one-way selection->clipboard 
syncing could probably stay without causing any harm, as this way of the flow 
is natural (I don't see how this could be useful though - I still fail to see 
the usefulness of the automatic syncing). And the syncing disabled by default 
of course. Also the Klipper polling can stay, I have even few ideas how to 
make it hog the system less (some X11 code for Klipper required though, and 
implementing some missing features in QClipboard too).

>
> KClipboard could get a check to only do this when clipboard and selection
> are not equal already.

 This would not help in all cases I think, and I'm also afraid this check 
would be quite complicated (after only a while of thinking about it, so maybe 
I'm wrong). The thing hidden behind the simple QClipboard API isn't that 
simple.

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