--- Begin Message ---
Package: kde-core
Version: 5:48
Severity: important
After testing upgraded a number of KDE packages for me
last night, I having major problems with window behavior
under KDE.
o When I click on the menu bar in a KDE application,
such as in the Control Center, nothing happens. If I then
move the mouse to a different menu item (without clicking),
that other menu item drops down. I can then open any menu
item by moving the mouse.
o In KDE applications, such as in the Control Center, clicking
on a drop-down list only selects the control but the list does
not open. The only way to browse the items in the drop-down
list or change the selected item is to use the keyboard.
o In Iceweasel, clicking on the menu bar does nothing at all.
The only way to access menu items in Iceweasel is to use
the keyboard.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages kde-core depends on:
ii arts 1.5.9-2 sound system from the official KDE
ii kdebase 4:3.5.9.dfsg.1-2 base components from the official
ii kdelibs 4:3.5.9.dfsg.1-4 core libraries from the official K
kde-core recommends no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
First of all, I now know that this was not a KDE bug,
but a general X problem.
The problem was that for mouse clicks, I was
getting xev | grep -i button output like
ButtonPress event, serial 22, synthetic NO, window 0x1000001,
state 0x0, button 1, same_screen YES
ButtonRelease event, serial 22, synthetic NO, window 0x1000001,
state 0x100, button 1, same_screen YES
ButtonRelease event, serial 22, synthetic NO, window 0x1000001,
state 0x100, button 1, same_screen YES
ButtonPress event, serial 22, synthetic NO, window 0x1000001,
state 0x0, button 1, same_screen YES
instead of
ButtonPress event, serial 22, synthetic NO, window 0x1000001,
state 0x0, button 1, same_screen YES
ButtonRelease event, serial 22, synthetic NO, window 0x1000001,
state 0x100, button 1, same_screen YES
i.e., like a double-click, but with the up and down events in
reverse order for the second click. Weird. No wonder things
were getting confused.
Well, now the problem has disappeared, as mysteriously
as it appeared. Maybe it was a hardware problem, who knows.
--- End Message ---