Bug#214514: klipper freezes, but can be unfrozen by pressing Alt
Package: klipper
Version: 4:3.2.1-1
Severity: normal
Followup-For: Bug #214514
I can confirm the report by pen_sq@cox.net 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
Reply to: