Re: clipboard & klipper in X11 terminal

[<tim...@en...>]

Ethan Merritt a =C3=A9crit :
>> we should comply with ICCCM conventions,=20
>> explained in the previous links.
>>    =20
> I've just had a look at=20
>    <http://tronche.com/gui/x/icccm/sec-2.html#s-2.6>
>
> It seems to me that klipper is not acting in accordance with
> section 2.6.1.3.   As I read the standard, it says that when
> "another client" [in this case gnuplot_x11] acquires ownership
> of the clipboard, then the "special client" [klipper] is supposed
> to request the exported data and then immediately reacquire
> ownership for itself. =20
>
> This section does talk about synchronizing via the TIMESTAMP,
> but it mandates that the special client reacquire ownership
> regardless of the success or failure of TIMESTAMP match-up.
>  =20
> klipper is not doing this.  So far as I can tell, gnuplot_x11
> retains ownership of the clipboard until either it voluntarily
> gives it up [that was my 2 Feb patch] or some 3rd party
> application intervenes.
>  =20
You're right. The first link ( http://www.kdedevelopers.org/blog/280 )=20
explains that klipper used to behave that way, but changed later :
"Another possible solution was to use the fact that the clipboard owner=20
gets notified when it looses the ownership, so Klipper for quite some=20
time also tried to solve the polling this way. Klipper took ownership of=20
the clipboard and whenever it lost it, Klipper immediately asked the new=20
owner about the new text in clipboard and then took ownership again,=20
with this new text. This is not used anymore, Klipper no longer claims=20
clipboard ownership unless explicitly told so, as it causes some=20
trouble. First there's the problem if the clipboard content set by the=20
app is not text then it gets lost, and secondly, such extensive usage of=20
the QClipboard class was a good stress test for it. So good in fact that=20
it had revealed several bugs there that otherwise had gone unnoticed and=20
QClipboard maintainer at TrollTech is even allergic to bugreports about=20
QClipboard and Klipper even if they contain patches (you can find=20
evidence if you grep qclipboard_x11.cpp for klipper :-). There were KDE=20
releases that unfortunately had bad problems because of such bugs."
> Your patch may indicate that klipper regains ownership properly
> only if the TIMESTAMP comparison succeeds, even though section
> 2.6.1.3 says it should regain ownership in all circumstances.
>  =20
Yeah, they may have dropped the best solution for reasons that are not=20
true now, but finally it's not that hard to satisfy klipper needs with=20
"TIMESTAMP"... In any case, your patch seems to work too.

Best regards,

Timoth=C3=A9e