https://bz.apache.org/ooo/show_bug.cgi?id=128612
--- Comment #23 from [email protected] --- (In reply to Arrigo Marchiori from comment #22) > (In reply to damjan from comment #21) > [...] > > Running "./x11_clipboard_formats" after copying a cell should let you > > distinguish whether AOO has it, or some clipboard manager. > > When it is working "well", I see: > > $ ./x11_selection_owner > Invalid type of WM_NAME property. > window id 0x4900001, name (null) > > When it is working "bad", I see: > > $ ./x11_selection_owner > window id 0x0x2e00004, name Qt Selection Owner for plasmashell Meaning "Qt Selection Owner for plasmashell" takes clipboard ownership in the "bad" case. > > You can also examine the current X11 clipboard formats with: > > > > $ xclip -selection CLIPBOARD -target TARGETS > > > > and replace "TARGETS" with one of the listed formats to paste to stdout in > > that format. > > Using command: > $ xclip -o selection CLIPBOARD -target TARGETS > > - the "well working" clipboard gives a long series of supported formats > including several "application/x-openoffice-"something > > - the "bad working" clipboard just gives: > text/plain > UTF8_STRING > STRING > TEXT > application/x-kde-onlyReplaceEmpty > TARGETS > MULTIPLE > TIMESTAMP > SAVE_TARGETS > > FWIW on Ubuntu 22.04 a way to consistently get "good" clipboard, is pressing > CTRL+C twice in a row. I developed this habit and are living... well, > notwithstanding this issue. >From some reading, I think the source code for KDE's clipboard manager is in: https://invent.kde.org/plasma/plasma-workspace.git under the klipper/ subdirectory. 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. 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--- but even this might not work on KDE, because these formats: > - 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? -- You are receiving this mail because: You are the assignee for the issue.
