https://bz.apache.org/ooo/show_bug.cgi?id=128612
--- Comment #25 from Arrigo Marchiori <[email protected]> --- (In reply to damjan from comment #23) [...] > It seems like there are 2 approaches to X11 clipboard management: > > 1. The "aggressive" approach described in ICCCM as a "special client" under > "The CLIPBOARD selection", where the clipboard manager always dominates as > the clipboard owner, and if it loses ownership, it downloads the new > clipboard contents and becomes the clipboard owner again. > > 2. The "conservative" approach of > https://www.freedesktop.org/wiki/ClipboardManager where clipboard ownership > remains with the application and the clipboard contents can be explicitly > saved with the "SAVE_TARGETS" selection when the application exits (which > can be defeated, for example if Mousepad is killed with "kill -9", text > copied from it cannot be pasted after it's killed). > > Klipper only seems to use the aggressive approach. There is no mention of > CLIPBOARD_MANAGER or SAVE_TARGETS in its source (in fact, try running > "xlsatoms", and see if those even appear there). > > The flow through the Klipper source code (from reading, not debugging) seems > to be: > 1. SystemClipboard::SystemClipboard() will register a callback: > > ---snip--- > connect(m_clip, &KSystemClipboard::changed, this, > [this](QClipboard::Mode mode) { > checkClipData(mode); > }); > ---snip--- > > 2. An application like OpenOffice copies something to the clipboard. > 3. SystemClipboard::checkClipData() gets called, does a bunch of checks, and > calls Q_EMIT newClipData(mode, data); > 4. Since HistoryModel::HistoryModel() previously registered a callback: > > ---snip--- > connect(m_clip.get(), &SystemClipboard::newClipData, this, > &HistoryModel::checkClipData); > ---snip--- > > it will run HistoryModel::checkClipData(), which will save the item data to > history with insert(), and call: > > 5. SystemClipboard::setMimeData() which will put it on the clipboard again, > and take ownership of the clipboard, which will stop OpenOffice from pasting > from its internal clipboard. > > Now I am not too sure why pressing Ctrl+C twice works, there is even this > insightful comment: > > ---snip--- > // #80302 - OOo (v1.1.3 at least) has a bug that if Klipper requests its > clipboard contents > // while the user is doing a selection using the mouse, OOo stops > updating the clipboard > // contents, so in practice it's like the user has selected only the > part which was > // selected when Klipper asked first. > // Use XQueryPointer rather than > QApplication::mouseButtons()/keyboardModifiers(), because > // Klipper needs the very current state. > ---snip--- > > which means Klipper has been OpenOffice over clipboard ownership for a long > time... > > One hack which should fix this bug on KDE is including the MIME type > "application/x-kde-syncselection" (with contents "1"), because when that is > set, Klipper's SystemClipboard::checkClipData() will return early instead of > copying the clipboard and taking ownership, something it sets itself to > prevent the loop of pasting from itself. However this seems like an internal > implementation detail, that we cannot rely on in the long term. +1 > Besides, clipboard managers are desirable to users, and ideally we should > allow data OpenOffice copies to the clipboard to be pasted after OpenOffice > exits, at least in some limited form. > > Which would mean option 1 from comment 16 would be the best: > > ---snip--- > 1. Eliminate the internal clipboard, and make all clipboard formats > external, but protect them by obfuscation or encryption if necessary. This > would work correctly with all clipboard managers because they would copy all > our clipboard data and we would paste it back from them, and it would allow > pasting between different OpenOffice instances. > ---snip--- +1 > > but even this might not work on KDE, because these formats: > > (In reply to Arrigo Marchiori from comment #22) > > - the "bad working" clipboard just gives: > > text/plain > > UTF8_STRING > > STRING > > TEXT > > application/x-kde-onlyReplaceEmpty > > TARGETS > > MULTIPLE > > TIMESTAMP > > SAVE_TARGETS > > seem to exclude our custom formats, which we could use to represent the > internal clipboard externally :-(. Where is > 'application/x-openoffice-dif;windows_formatname="DIF"' for example? What > does "xclip -o selection CLIPBOARD -target TARGETS" give you in the "good" > case? Now on Ubuntu 22.04, KDE 5.24, using AOO 4.1.15, "good" case of copying a Calc cell including formatting: $ xclip -o -selection CLIPBOARD -target TARGETS text/plain;charset=utf-8 text/plain;charset=UTF-8 UTF-8 UTF8_STRING COMPOUND_TEXT STRING application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)" application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object Descriptor (XML)";classname="47BBB4CB-CE4C-4E80-a591-42d9ae74950f";typename="calc8";viewaspect="1";width="2259";height="417";posx="0";posy="0" application/x-openoffice-gdimetafile;windows_formatname="GDIMetaFile" application/x-openoffice-emf;windows_formatname="Image EMF" application/x-openoffice-wmf;windows_formatname="Image WMF" image/png application/x-openoffice-bitmap;windows_formatname="Bitmap" PIXMAP image/bmp text/html application/x-openoffice-sylk;windows_formatname="Sylk" application/x-openoffice-link;windows_formatname="Link" application/x-openoffice-dif;windows_formatname="DIF" text/richtext application/x-openoffice-editengine;windows_formatname="EditEngineFormat" MULTIPLE Do I understand that, according to your next comment #24, this issued was fixed on KDE 6? If so, we may consider the issue limited to KDE 5. -- You are receiving this mail because: You are the assignee for the issue.
