Version: 1.1 (using KDE 3.1.93 (CVS >= 20031111), yes) Compiler: gcc version 3.3 20030226 (prerelease) (SuSE Linux) OS: Linux (i686) release 2.4.20-4GB-athlon when i try to click on the KMenu or any other Kicker applet item. Randomly mouse clicks are ignored. This applies to everything it seems but the System Tray. Also the minicli applet will ignore every few key strokes. This is new since the KWin migration. This makes KDE very hard to use because its inconsistent
*** Bug 68656 has been marked as a duplicate of this bug. ***
*** Bug 68612 has been marked as a duplicate of this bug. ***
*** Bug 69411 has been marked as a duplicate of this bug. ***
This may be caused by an interaction between MacOS-style menus and the code that passes mouse clicks on the panel borders to applets. I can reproduce it by turning on MacOS-style menus, opening the K-menu, and clicking the border of kicker just above an application menu item. Result: both K-menu and app menu open, kicker does not respond to mouse events. ESC clears things up.
i am not using MacOS menu... but i _do_ have my kicker at the top of the screen. I wonder if that is the real issue?
Subject: Re: kicker ignores key and mouse events sometimes I also don't use MacOS style menus, but the main kicker panel is on top and a child panel with the taskbar on the bottom.
Bug 69411 has been marked as a duplicate of this one, even if I guess it has few in common so please when you close this bug also check for the other one: pressing left win key sometimes the system starts acting like you were fastly pressing and releasing this key, or as if you were keeping it pressed,and it does not suffice to repress the key to stop this behaviour. Also a wish, to be able to set the "win key opens k menu" off. Even changing the modifier map does not change the behaviour, this is *very* unpolite from what is supposed to be an X client.
This still happens on 3.1.94 on Mandrake. I have the panel at the bottom and a child panel on the bottom right hand side. When this behaviour occurs during menu selection (i.e. I succeeded in clicking on the "Start" button, but mouse movement/clicking has no effect on the revealed menu) I have found that I can still use the cursor keys to move the menu selection and press "Enter" to select. Curiously, it seems that the clicks that I made (but were ignored), are queued up and sent to the window underneath when I finally press "Enter".
*** Bug 70372 has been marked as a duplicate of this bug. ***
The bug I reported is not yet solved: sometimes, using the left win key causes random lock of the same key. To unlock, either press the k menu and pray, or ctrl+alt+backspace :) I can't undestand how this happens, sorry
*** Bug 74683 has been marked as a duplicate of this bug. ***
It's the same with KDE 3.2 on FC 1. I found that killing and restarting kicker helps for some minutes before the problem starts again. Additionally it seems that the problem does only appear after a certain uptime. Regarding comment #5: I don't use Mac OS menus too but my kicker is at the bottom of the screen.
See "Bug 68477: klipper freezes on selecting an action in the popup (normal)" for similar problems with klipper - I am experiencing them in 3.2.0 final still
*** Bug 75301 has been marked as a duplicate of this bug. ***
I am Using FC2 Test 1, KDE 3.2RC1 is inside - I do have the main panel at the bottom, a child panel at the top. I can see problems with kicker through looking at knewsticker: randomly it starts to stutter and can only be corrected by restarting kicker. It often comes up when I use mozilla - their seems to be a correlation on my system between using mozilla and the total freezing of the kde-kikcer functions (than knewsticker freeezes too). Can someone affirm this correlation with mozilla?
Multiple instances of Mozilla/Firefox and Konsole definately causes this bug to be reproducable on my system(Intel P4 w/ Fedora Core1 and KDE 3.2).
I have a menu freeze situation. Sometimes (I thought there was a correlation between the menu freeze and mozilla as well) I click on the kmenu, it pops up, slide to secondary menu, it flys out, then freeze. I use a Ctrl-Esc combination to unfreeze, and then anything I've clicked while it was frozen launches.
Sometimes, when the klicked button in the kicker bar freezes, it helps to klick the right mouse button on the icon, then klick the left button and the kicker "came back". I am not sure how to reproduce te bug in any case, sometimes its there, sometimes its not. Its on KDE 3.2 on Fedora Core 1, too.
The best workaround I have found to these problems is to completely disable that "winkey" feature. I am not sure if this is your problem too, however the only way I found to disable win key is to start kde with a .xsession like this: #### #!/bin/sh xmodmap -e "keycode 115 = Hyper_L" startkde & sleep 15 xmodmap -e "keycode 115 = Super_L" wait #### This sucks but somewhat works.
Setting the group similar tasks to <never> allows the pager to be more usable. The applications buttons and "KDE Start" button are still not very responsive.
*** Bug 75705 has been marked as a duplicate of this bug. ***
*** Bug 74891 has been marked as a duplicate of this bug. ***
*** Bug 74392 has been marked as a duplicate of this bug. ***
My problems from bug #74891 how nothing to do with the windows key. My two problems are as follows: 1) Alt+Tab sometimes locks up. THe longer KDE is running the more often it happens. I need to ssh in, kill kiwn and then restart it on a text console and I can continue working. 2) I've applied the Mandrake focus patch to qt 3.2.3 (I am running Fedora Core 1) and I'm still having the taskbar issues. The issue is when I right click on a task I can't use the mouse buttons/pointed to activate or select an option. I think there is also a problem in that the taskbar sometimes doesn't work on the first click. I end up having to click twice.
Can somebody reproduce the problem without running Klipper as an applet?
Just wanted to say that I fixed the problem by doing exactly that: I got rid of the Klipper applet.
Ah, that $&%^*(%ing Klipper. Nice idea, but it's been buggy as hell since ... like, forever. Maybe this embarrassment will finally spur some much needed attention to fixing Klipper bugs.
yeah, that's right, it's the Klipper, I removed it, now it's working fine. But I really like Klipper, would be good if somebody could fix this bug soon, I hope I had time to do this.
Small note: the klipper runs fine if it's in the systray, just not as an applet.
One more question: Does the problem exist also with numlock turned on (and with klipper as applet, of course)?
I always have numlock turned on...
*** This bug has been marked as a duplicate of 74487 ***
could somone tell me how to get rid of the klipper applet? I am not stupid just new. To used to windows to totally know my way around.
I can confirm that this problem seems to still be around in Debian Testing KDE 3.2 from about yesterday. Turning off the klipper applet ( from it's own menu, "remove >" ...) appears to solve the problem. In fact, now that I'm aware of it, klipper seems to be the cause of several oddities I've experienced.
I should say that upgrading my Qt copy to the latest from the kde-cvs (I think it's the same as the official Qt 3.3.2), solved many problems that seemed to be caused by the klipper applet. Perviously I had problem with the K Menu and just noticed problems with the RMB menu in some Quanta treeviews (mouse events are ignored, keyboard works fine), the new Paste functionality (selecting an item from the clipboard history) was not working. Now I can't see any problem in Quanta, KMenu and with the Paste button. Everybody seeing such problems should try to upgrade the Qt. (BTW, I have kdelibs from CVS HEAD).