Package: klipper Version: 4:3.2.1-1 Severity: normal Followup-For: Bug #214514
I can confirm the report by [EMAIL PROTECTED] that klipper can typically be unfrozen by pressing the Alt key, and that the problem persists in 3.2. OpenOffice integration with the KDE clipboard is still poor. Here is how I reliably reproduce the frozen effect: 1. Open OOo Writer afresh and read in a document 2. Mark a few words by dragging the mouse over them 3. Press the copy button in oowriter's toolbar 4. Press the clipper icon in the systray You may get no response, in which case click again. In most cases, klipper will now freeze. If you're not getting the freeze, try marking a larger area of text, and repeat steps 3 and 4. The effect is most easily reproduced when you first start oowriter. After making some clips and reading them into klipper, the system seems to get unstuck. Try doing the same thing with a spreadsheet in OOo -- mark some cells, press copy, click klipper icon -- freeze. The freeze appears to be related to the interface between OOo and the klipper. Copy-and-paste behavior within OOo, if I'm recalling correctly, used to mimic Microsoft Windows behavior, in that text was not moved to the clipboard unless you pressed the copy icon. Now just marking text moves it to the clipboard, but there may be a remnant of the old behavior -- when you now click the copy button (even though you don't need to anymore), and then move to klipper, klipper freezes. Note that clicking on an item in klipper has the effect of removing all formatting from that text. OOo apps will conserve formatting during cutting and pasting, and so will klipper -- unless you select the item within the klipper menu. At that point, the formatting goes. In some ways, this is a bug, but I find it a very useful feature. If I want to strip text of formatting, which I often do as I go from OOo to html, I use this feature of klipper to get raw text. I therefore think that the current functionality is correct and useful, though it would be even better if there were an explicit option to keep or strip the formatting. In any case, something about this transition from OOo's old copy-and-paste behavior, and/or the half-way conversion feature in klipper, may be causing klipper to freeze when getting data from what OOo. Perhaps OOo is still keeping its own internal clipboard, and this is not properly synchronized with klipper. This additional detail to the original bug report is focused on OOo apps, and it may be that the problem is confined to those apps. I'll submit an update if I find it's triggered in conjunction with other applications. Integration with OOo is obviously a serious issue, as the OpenOffice.org suite is playing a major role in making the Linux desktop attractive to non-geeks. Cheers, David -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.24 Locale: LANG=C, LC_CTYPE=C Versions of packages klipper depends on: ii kdelibs4 4:3.2.1-1 KDE core libraries ii libart-2.0-2 2.3.16-1 Library of functions for 2D graphi ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libfam0c102 2.7.0-5 client library to control the FAM ii libgcc1 1:3.3.3-1 GCC support library ii libice6 4.3.0-5 Inter-Client Exchange library ii libpng12-0 1.2.5.0-5 PNG library - runtime ii libqt3c102-mt 3:3.2.3-2 Qt GUI Library (Threaded runtime v ii libsm6 4.3.0-5 X Window System Session Management ii libstdc++5 1:3.3.3-1 The GNU Standard C++ Library v3 ii libx11-6 4.3.0-5 X Window System protocol client li ii libxext6 4.3.0-5 X Window System miscellaneous exte ii libxrender1 0.8.3-7 X Rendering Extension client libra ii xlibs 4.3.0-5 X Window System client libraries m ii zlib1g 1:1.2.1-5 compression library - runtime -- no debconf information
