Version: (using KDE KDE 3.5.0) Installed from: Compiled From Sources Up to and including KDE 3.4, switching between two windows by keyboard (Alt+Tab) was lightning fast. Since KDE 3.5, I've got nearly a *one* second delay. This is extremely annoing as all further input after issuing Alt+Tab and before the other window is shown, is directed to the first window. This behaviour severely cripples workflow as one cannot immediately type commands directed at the target window, like compile and edit sessions: Steps to reproduce (0) Have a Konsole and a Kate window open, with Konsole being at the front, and Kate in the background (target for Alt+Tab) (1) On Konsole: let's assume you compile stuff, get error in line 353 (2) Press as fast as possible: Alt+Tab, Strg+G, 353, Enter Expected results: Alt+Tab switches, Strg+G opens Goto Line, 353, Enter bring one to line 353. Actual results: Alt+Tab does nothing, Strg+G does something on Konsole, 353 writes 353 to the Konsole, Enter executes it on Konsole. *Then* Kate get focus.
Works fine for me here.
Works fine for me too. Is there anything special about your setup, can you reproduce with a fresh user account, etc?
This happens to me as well. Tried restarting kwin, but didn't help. Really annoys me, I think it happens after running kde for a while...
I tried restarting kde, and it went back to normal. Then alt+tab actually got gradually slower, starting out with a short delay but getting worse and worse.
Harald: For me it's slow as soon as I've started up KDE. I can't tell whether switching performance degrades even more over time. Lubos: I'm using quite a slow HW. Maybe you could reproduce it on a computer < 1GHz? To investigate it, which part of kwin does the switching?
Leo: How about posting process-lists? Here is my output from ps aux, maybe we can find the source by comparing these: http://www.pvv.org/~haraldhv/proc My line of thought was that since it doesn't seem like an obscene amount of people has already complained about this, it might be some other thing than kwin causing it.
I have done some more research. When I press alt+tab, the cpu-usage for the X process goes to 100% for a (gradually increasing) time, until the window is displayed and it goes back down. By changing control panel -> window behavior -> "show window list while switching windows", I was able to switch without the delay. However, this problem still persists when I change desktop (which I have bound to win+tab), so it's still annoying. Maybe someone could check the kwin source code for what has changed in kwin since 3.4.1 (my last version where I did not have this problem). It shouldn't be too hard as we know what causes the delay (displaying the window-switching dialog). And finally, to those who also experience this, how did you transition from 3.4.x to 3.5? Did you start over with fresh settings, or did you use the samme .kde settings folder as before (like I did)?
I can confirm the observations you made. CPU spikes at 100% for a noticeable time interval, only to switch the window afterwards. I have never started with a fresh profile since KDE 2.0 (yes, *2*.0), and up to and including KDE 3.4.2, window switching was a very fast operation (not graphically, but as far as focus transfer was concerned). Switching off "show window lists" indeed makes switching fast again. But that feature is severely broken, so it cannot serve as a subsitute (see bug 118042).
Comment #5: kdebase/kwin/tabbox.cpp . I can't reproduce even with slower machine.
How did you try to reproduce it? On my computer, it works at expected in the beginning, only to get slower after kde has been running for about a day. My current session is about two days old, and the alt+tab process has added up to about one second now.
Somehow this bug seems to be related to Kate. I started Kate 24 hours ago and had about 20 files open in it. After six hours there was a small but noticeable slowdown with Alt-Tab. Later the lag had increased to two seconds. Then I closed Kate, and five minutes *later* this slow Alt-Tabbing was gone. My computer has mobile Athlon XP2400+ so a slow CPU shouldn't be needed to reproduce this issue.
Am Donnerstag, 15. Dezember 2005 00:12 schrieb Lasse Collin: > Somehow this bug seems to be related to Kate. I started Kate 24 hours ago > and had about 20 files open in it. After six hours there was a small but > noticeable slowdown with Alt-Tab. Hmm, that maybe a valuable hint. I've got kate running for about three days with 40+ files open. I've closed it now and will check whether task switching improves.
Unfortunately it wasn't that simple. I haven't had Kate running today and Alt-Tab is slow again. However, something resets the "counter" to zero making Alt-Tab fast again; maybe it was just a coincidence that it happened soon after I had closed Kate at midnight. Alt-Tab was still fast in the morning and afternoon, but now in the evening it takes two seconds again.
Well, I can rule out kate as a potential offender. It's been down for 4 hours, and Alt+Tab is still as sluggish as before. Also note that I continuously perceive the same amount of sluggishness regardless of the age of the session. The delay is just long enough so that the focus has not yet been transferred to the target window when I'm already typing the first characters.
*** This bug has been confirmed by popular vote. ***
I upgraded from KDE 3.4 to KDE 3.5 today and I have the same exact annoying delay :( I was using kate too. My CPU speeds up too. Delay is about 1-2 seconds.
Hmm. Could you find somehow where the time is spent? E.g. adding QTime debug statements to kwin/tabbox.cpp, or running sysprof (http://www.daimi.au.dk/~sandmann/sysprof/), starting profiling, doing a couple of those slow switches, and then profile, save the output and attach it here?
I'm runnig fedora core 3 with oprofile installed and I'm using a vanilla kernel. I'll recompile my kernel with profiling support, then I'll read the docs of Oprofile and I'll append the eventual output here. Just wait a little, I'll do it asap.
Additional info: kicker crashed 3 times in 4 days of uptime. In the first 2 it respawned itself, but the 3rd time it didn't respawn at all (so I restarted it manually from a console). ------ I recompiled the kernel with profiling support and rebooted my pc, now I'm going to read the Oprofile documentation. Note: After rebooting the Alt+Tab delay has vanished! I'll wait some time and see if it will reappear.
I just upgraded KDE to 3.5.0-1.2, rebooted my pc, and apparently the Alt+Tab delay is no more. I'll wait some time and see if it will reappear.
Created attachment 14169 [details] Oprofile data + some reports
Hello everyone, the alt+tab delay has returned, so I started oprofile and I did some alt+tab. Attached you will find the data directory "current", and some output files from the report programs. If you need other details, please mail me what I have to do. I hope these files may helps. Alberto
Weeell, not really, sorry, I can't make out any useful information out of the oprofile data. Can you find out yourself the kwin backtrace showing where the time is spent? Otherwise it'd be probably better if you could use sysprof.
Status update. I now perceive the same degradation in Alt+Tab performance like in Harald in comment 4. The box is now up for three days, and Alt+Tab needs several seconds to take effect. This makes me believe we're all experiencing the same bug.
Created attachment 14295 [details] callgrind profile dump Fwiw, this is the dump from a callgrind run on kwin. It only covers the task of switching from one window to the other. Hopefully you can interpret it better than me.
No, nothing obvious visible from it. The only place where it could possibly point to is areModKeysDepressed() (in tabbox.cpp). Could you add something like QTime t; t.start() ... ; kdDebug() << t.elapsed() << endl; there to confirm that's the place where a long time is spent?
Instrumented the code as suggested: --- tabbox.cpp (Revision 469588) +++ tabbox.cpp (Arbeitskopie) @@ -675,6 +675,9 @@ int nKeySyms = 0; if( seq.isNull()) return false; + kdDebug() << "**********" << k_funcinfo << " start measuring" << endl; + QTime t; + t.start(); int mod = seq.key(seq.count()-1).modFlags(); if ( mod & KKey::SHIFT ) @@ -702,7 +705,9 @@ rgKeySyms[nKeySyms++] = win_keysyms[ i ]; } - return areKeySymXsDepressed( false, rgKeySyms, nKeySyms ); + bool x = areKeySymXsDepressed( false, rgKeySyms, nKeySyms ); + kdDebug() << "**********" << k_funcinfo << " end measuring" << t.elapsed() + return x; } The results are like this: kwin: **********[bool KWinInternal::areModKeysDepressed(const KKeySequence &)] start measuring kwin: **********[bool KWinInternal::areModKeysDepressed(const KKeySequence &)] end measuring4 kwin: **********[bool KWinInternal::areModKeysDepressed(const KKeySequence &)] start measuring kwin: **********[bool KWinInternal::areModKeysDepressed(const KKeySequence &)] end measuring3 kwin: **********[bool KWinInternal::areModKeysDepressed(const KKeySequence &)] start measuring kwin: **********[bool KWinInternal::areModKeysDepressed(const KKeySequence &)] end measuring3 kwin: **********[bool KWinInternal::areModKeysDepressed(const KKeySequence &)] start measuring kwin: **********[bool KWinInternal::areModKeysDepressed(const KKeySequence &)] end measuring4 So no, that's not the reason. I've observed that the switch itself takes a long time, i. e. after having released all keys, it takes several seconds to bring the other window to the front.
I've got some idea for a quickfix. Lubos, which parts of kwin would I have to comment out to not have the tabwindow appear, but still retain normal tab-order?
All the tabbox code is in kdebase/kwin/tabbox.* . I guess just commenting out all the show() calls there should do what you want.
Leo Savernik, Did the quickfix work?
Am Samstag, 4. Februar 2006 17:02 schrieb Harald Hvaal: > Did the quickfix work? Sorry, haven't tried yet (sheer lack of time). Will post a patch when I have.
If this is going to help, I'll describe how I can reproduce the bug and when this bug is occuring to my system. It happens only after I quit VMWare workstation (5.5.1). The procedure is: a) Load vmware modules b) Launch/use vmware workstation c) quit vmware workstation d) Unload vmware modules The delay starts appearing after step d. While VMware is running, the delay is not present. The delay of course goes away when I relogin. I haven't found another way to reproduce this bug. I'm running kde for days (without logging out) using both qt/kde gtk/gnome applications. It's happening to me only after Vmware. I hope this helps.
I'm using VMWare 5.0.0 and i have the same result, but the delay randomly appear even without starting it.
Ok, I've just run into this problem too, no idea what had triggered it. KWin restarts didn't help, according to sysprof the CPU time was spent in X. I tracked it down to X(un)grabKey() calls in KGlobalAccel, no idea what the real problem was, but I'd expect this to be X bug. However then I ran Metacity and after starting KWin again the problem was suddenly gone :-/. Not sure what to do.
Am Dienstag, 14. Februar 2006 18:57 schrieb Lubos Lunak: > Ok, I've just run into this problem too I should add that I've even downgraded kwin on my devel-account to 3.4-branch, but to no avail. I haven't yet performed sufficient testing whether it was really not kwin or just some sort of downgrading error, so I haven't reported back earlier. However, I still suspect KDE of triggering the bug. I've been using XFree 4.4.0 for many years and I have never experienced anything remotely like this one. Could it be dcop or some other daemon which drains cycles at the wrong moment. Maybe klipper? KDE 3.5 also feels more sluggish than 3.4 or 3.3, but this experience is subjective and I have no numbers to back it.
Created attachment 14999 [details] ugly hack which fixes the issue for me ==== !DANGER! HAZARDOUS PATCH! APPLY AT YOUR OWN RISK !DANGER! ==== With invaluable hints from Lubos I've come up with a workaround that fixes the fixes all slowness and makes keyboard task switching as fast as it was in KDE 1.x. Note that this patch is merely suited to relieve big pain -- it will *never* hit svn. Up to now I haven't noticed any ill-effects but this *does not mean there are none*! Hence, some disclaimers: - By applying this patch you can consider your KDE installation to be broken. - By applying this patch you refrain from complaining about negative side effects within this bug, to me, to Lubos, or any other KDE-developer. - Having a working patch for me does *not* imply that it works for you. - This patch comes without any warranties, neither expressed nor implied bla bla you get it. Still not scared? The unwary may apply now ;-) ==== !DANGER! HAZARDOUS PATCH! APPLY AT YOUR OWN RISK !DANGER! ====
[VMware fix] for those who can reproduce the problem with VMware ---------------------------------------------------------------- Just go to the VMware preferences (Ctrl+P) and unset these: - Input -> Grab when cursor enters window - Input -> Ungrab when cursor leaves window Select this instead: - Input -> Grab keyb and mouse input on mouse click ----------------------------------------------------------------
*BIG* thank you to Leo Savernik for the patch (and sorry for slow reply)! My KDE is usable again. :-) I haven't noticed any side-effects after patching. I have never had VMware. The slowness appeared in a few hours and all the X apps that I have had running are shipped with KDE. Maybe someone else has something similar to mine: - Konqueror web browser with 5-30 tabs - Konsole with 2-8 tabs - Akregator with 2-5 tabs - KMail - kicker with three panels, all with autohide - In panel / systray: KLaptop, Klipper, KGet, Clock, Evaluate - X.org 6.8.2, unpatched Qt 3.3.5 - glibc 2.3.5 or 2.3.6, Linux 2.6.14 - Almost everything is compiled with GCC 3.4.4 or 3.4.5; KDE and Qt optimized for size (-Os makes KDE notably faster than -O2) When I had KDE running for a few days, my record was a 15-20-second delay with Alt-Tab. During that time no panels can be (un)hidden and you cannot change the active window by moving mouse (I'm using sloppy focus). During the delay, I can continue using the application that was active, but `top' shows that X is eating all the otherwise unused CPU time.
OK, so what happened to this bug? Did people apply the patch or just endure living with it? A few days ago I converted to Debian with a fresh install of KDE with no KDE config files from my old Gentoo installation. I am now running KDE 3.5.3. At first I thought I had gotten rid of the bug, but now it seems it has shown up once again. The delay is only 250 ms for now, but I'm sure it'll get worse as it always does. The interesting thing is what this tells us: 1. The bug does not come from upgrading from an earlier version of KDE 2. The bug does not come from a specific distribution (already settled I guess) 3. The bug might be hardware dependent Regarding #3, I'm curious if there might be a common denominator in our choice of hardware. The most obvious to compare would be the graphics adapter. I have an ATI radeon, does many of you also have this? I really want to fix this/get this fixed!
I applied the patch and even dared to distribute packages having the patch applied. I made it clear that kwin was patched and included an URL to this bug. I have a laptop with Athlon XP2400+ and Ati IGP320M. The delay appears with both X.org 6.8.2 and X.org 7.1. I don't have any proprietary drivers installed. My xorg.conf doesn't have anything special. DRI is disabled. The delay is one to two seconds after 7-12 hours. It can get suddenly better for a few moments, but will appear again a little later. I really would like to get this fixed too. I don't have skills to debug this myself, but I want to help if I can.
I am using a desktop computer, which is a Pentium 4 2.4 Ghz w/ HT and Nvidia 5600 graphics card with the binary drivers. But I'm using hibernate that's why I have long uptimes. Concerning the bug, for me it happens only when using VMWare workstation and when the lag grows big I just relogin (restart X.org).
I think this bug is unacceptable for any high profile project. I'm really concerned with the fact that it has existed for over half a year and no official fix has been released. In my opinion the KDE team should have fixed this long time ago. Also I miss an official statement about the status of this bug. I'm still using KDE and have a good feeling about the KDE developers. However, this bug makes me wonder if the developers care at all about their user base. That's sad....
Accusing developers doesn't help fixing the problem. Seems that only very few users are affected by this issue. None of the people I have talked with on IRC have experienced this bug, nor even know anyone suffering from this problem. Alt-Tab (or to whatever key combination it is bound) works fine for them. Harald Hvaal: Since you started with clean config, I wonder if you have changed some settings after the first start of KDE, that trigger this bug. Maybe comparing the config files (which?) with others could reveal something. Thanos Kyritsis: According to comment #32 the delay appears *after* you have unloaded VMware modules (kernel modules, I suppose). If you quit VMware workstation but keep kernel modules loaded, the delay does not appear? VMware probably does grab the keyboard. A few of the comments here make me feel, that this issue has something to do with grabbing the keyboard. Yes, I'm getting desperate with this.
I am aware of the fact that this bug is of a particular tricky breed as it occurs seldom and only after a rather long period of time. However, I maintain that it is a very unfortunate bug to have in a high profile project like KDE. I might have been too harsh, but the fact stands that this bug has been outstanding for half a year and is very frustrating to run into. I know that the KDE people are doing their best -- which is a hell of a good job -- but I'm sorry to say, that this this bug is a real showstopper when it occurs. Has anyone tried minimizing the patch by Leo Savernik? If it solves the symptoms, we might be able to use it to track down the place where the real problem is.
I have a Sapphire Ati Radeon 9250 video card.
I think SVN commit 439969 is related to this bug. It uncomments one line, which is commented in KDE 3.4.3, but no longer in KDE 3.5.0. I have no idea what breaks by reverting it, but it seems to help with our bug. http://websvn.kde.org/branches/KDE/3.5/kdelibs/kdecore/kglobalaccel_x11.cpp?rev=439969&view=rev This gives an impression, that something bad happens in KAccelBase::updateConnections (kdelibs/kdecore/kaccelbase.cpp) or in something that gets called by that function.
The bug DOES occur on my desktop system: CPU: Intel 686/32 Video: ATI Radeon 9600, running the ATI OSS driver no VMware, plain Debian/Linux (testing) The bug DOES NOT occur on an old Compaq Presario 1200-XL laptop CPU: Intel Celeron Video: Trident Cyberblade, running the Trident OSS driver
I run some more thorough tests with VMWare and noticed that I don't have to close VMWare or unload the VMWare kernel modules for the lag to increase. It gets increased even when the VMWare application is running. But I agree it has something to do with grabbing the mouse/keyboard. If I just launch VMWare and exit/unload the modules, nothing changes. No lag. If I use it, and by use it I mean switching between VMWare and KDE desktop, mouse/keyb grabbing/ungrabbing lots of times, it's then that the lag increases. And I noticed that the amount of the lag depends on how many times I have switched. If I switch one time and close VMWare, the lag is very small, if I run VMWare for half a day working in and out of it, the lag will increase dramatically. Also Alberto in comment #37 suggests some specific settings in VMWare. They didn't help me. They only change the way that VMWare understands it should grab the mouse/keyb. Even with Alberto's settings, if I let VMWare grab/ungrab many times, the resulted huge lag is the same as before.
Yes, my suggestion only helps to lessen the amout of grabbing/ungrabbing times, but it doesn't remove the kde alt+tab delay problem :( So I also think that the problem has something to do with grabbing the mouse/keyboard.
Re comment #42: this bug has got more attention than most bugs in the KDE database. To say that we're paying enough attention is not only misleading, it's plainly lying. This is also hardly a showstopper. Not to mention, of course, that this happens only in specific circumstances (I, for instance, have never been able to reproduce this bug). And there are many, many more important bugs than this one that should have been fixed. They haven't, because we don't have the resources: there are simply not enough people working on KDE for the amount of exposure and code we have. If you want to do something about that, start coding. Sending bug reports and pinging the developers to make sure that they haven't forgotten is very welcome. Whining isn't.
I agree with Thiago Macieira, except that this bug is a major showstopper *if* the user uses Alt-Tab a lot and this bug hits him/her. For me it takes an 1-3 hours to gain an easily noticeable delay. Before Leo Savernik's patch KDE 3.5.x was unusable to me (I don't want to relogin in every three hours). I have now replaced that patch by commenting out one line in kdelibs (see the comment #46) and everything works fine. I haven't been able to debug the problem further. This was the first time I looked into KDE's sources, and shortcut key handling doesn't look the easiest place to begin. ;-)
I do appologise for my harsh comments regarding the handling of this bug. I wrote that comment without understanding the situation completely. As comment #51 says it is a major showstopper when it shows up, but it is very difficult to reproduce, I realise now. Due to a problem with my nVidia graphics card, I have been forced to use an old TSENG ET6000 card, and I have not been able to reproduce the problem. Not even after running the same KDE session for 5 days. I'm currently very busy, but when I get more time on my hands, I'll try to reproduce the problem. Do please accept my appology for the harsh comments against the KDE developers.
This problem has become increasingly bothersome for me over the past several months. I'm not sure at what version it became noticeable -- maybe a year or so ago. I run Debian (unstable branch) with only a few extras. I'll describe my system first, for comparative purposes. Athlon 3000+, 1GB RAM, Nvidia 6600 (256MB) -- not a torpid box. KDE 3.5.3-1 and XOrg 6.9.0 (Debian unstable packages). I've compiled the NVidia binary driver from nvidia.com, manually. I've been doing that for half a decade, though. Screen resolution 1600x1200, 24bpp. I've compiled in a Wacom tablet module to X, too, but that's been present for >1 year. I also use VMware Workstation (5.0.x) with the 'grab and release when mouse moves on/off' settings enabled. I also have the KDE Keyboard tool, Amarok, KOrganizer reminder, kteatime, kmix, klipper, checkgmail, kdewallet - all as systray icons (but most of those I've been using since last century). I typically have many apps running across my 6 desktops - I've got 27 on this one, for example, and 3 on another. Both *feel* like identical delays when ALT-TAB is used, though. Running top indicates that Xorg is using just shy of 500MB - no, I don't know why (is this a normal amount? it seems excessive). I'm using some SWAP space, but I suspect I echo other people's experiences when I observe that *the rest of the system feels responsive*, it's just when using ALT-TAB. Things I've toyed with: o disabling mouse-move activation in VMware - no effect o restarting KDE - it's still pretty woeful after a restart, and hard to say whether it's a genuine improvement - I need to experiment more, o having VMware running, and having it not running, and having the modules loaded, and having them unloaded (they appear to mostly be virtual network device modules anyway) - no effect, o using the mouse to toggle between two windows is *fast*, even if one of those is picked up from the task bar (ie, if it's currently minimized) but ALT-TAB on the same two windows is slow -- this leads me to conclude ... It's probably related to the window-list that gets popped up, as has been observed by others here - disabling this list (control panel | window behaviour | ...) resolves this bug, albeit at the expense of having a usable alt-tab feature (though just why that then changes the priority of windows eludes me). This insight brought to you by Duh Magazine, so moving along .. If you do ALT-TAB and hold the ALT key down, the delay it takes to show the window list *feels* to be about the same delay as the time it takes to do 'ALT-TAB, release the ALT key, and wait bring the next window to foreground and give it focus'. I speculate (I like speculating - you can probably tell) that the system may not have an exit clause in there early enough, so continues to get ready to paint that window list on screen, even if ALT's been released - and consequently you have to wait for KDE to 'nearly' draw the list. Forgive that description, but I can't work out how to describe it better. Sometime ago, very possibly around the time that the delay started occurring, the alt-tab pop-up window-list thing became a vertical list, and included all the icons for each of the apps it was showing. I think that previously it only showed each icon if you tab'ed through the horizontal list - but don't quote me on that. I'd imagine this data is cached though, so there should be a delay the first time you do it, but if you immediately swing back it should be near-instantaneous. I contemplated if it was perhaps relating to kompose -- I'm not sure where that puts its triggers into the desktop in order to track window changes -- however I only used kompose briefly, for a few months, and stopped a couple of months ago -- so have since ruled that out. I know that intermittent bugs, and bugs that take a while to manifest on a given desktop, and worse - bugs that only affect some people - are a right royal pain, and I have the greatest sympathy for whoever's looking into this. I hope the above information helps a tad.
Created attachment 16816 [details] kdelibs patch
Created attachment 16817 [details] kdebase patch Can somebody test these patches?
Am Mittwoch, 28. Juni 2006 14:56 schrieb Lubos Lunak: > Can somebody test these patches? Applied to my devel tree, and I'm experiencing absolutely no delay there. I haven't yet applied it to my stable tree, because this needs more work which I lack time for. Therefore, I can't tell for sure it's gone. Somebody else should test it, too.
Works for me too. Thank you. :-)
Works here too! thanks a lot.
When I have time I will try to apply this bug to my debian source. But what kind of fix is it? Is it a permanent one or a quick hack? Do you lose any functionality because of it?
Am Sonntag, 16. Juli 2006 19:04 schrieb Harald Hvaal: > But what kind of fix is it? Is it a permanent one or a quick hack? To me it looks very permanent. I virtually crave for it going into 3.5.4
> To me it looks very permanent. I virtually crave for it going into 3.5.4 D'oh! It missed 3.5.4. Hoping for 3.5.5.
SVN commit 568154 by lunakl: The workaround for #117169 (probably X bug, see comment #34). Not committing to trunk in hope that the problem will be gone by the time of KDE4 and also because KGlobalAccel is different, in the worst case if the problem persists it will have to be ported. BUG: 117169 M +15 -15 kdebase/kwin/tabbox.cpp M +6 -6 kdebase/kwin/useractions.cpp M +3 -0 kdelibs/kdecore/kglobalaccel.cpp M +6 -0 kdelibs/kdecore/kglobalaccel.h M +10 -1 kdelibs/kdecore/kglobalaccel_x11.cpp M +2 -0 kdelibs/kdecore/kglobalaccel_x11.h --- branches/KDE/3.5/kdebase/kwin/tabbox.cpp #568153:568154 @@ -881,9 +881,9 @@ if( !establishTabBoxGrab()) return false; tab_grab = TRUE; - keys->setEnabled( false ); - disable_shortcuts_keys->setEnabled( false ); - client_keys->setEnabled( false ); + keys->suspend( true ); + disable_shortcuts_keys->suspend( true ); + client_keys->suspend( true ); tab_box->setMode( TabBox::WindowsMode ); tab_box->reset(); return TRUE; @@ -894,9 +894,9 @@ if( !establishTabBoxGrab()) return false; control_grab = TRUE; - keys->setEnabled( false ); - disable_shortcuts_keys->setEnabled( false ); - client_keys->setEnabled( false ); + keys->suspend( true ); + disable_shortcuts_keys->suspend( true ); + client_keys->suspend( true ); tab_box->setMode( (TabBox::Mode) mode ); tab_box->reset(); return TRUE; @@ -1064,9 +1064,9 @@ { removeTabBoxGrab(); tab_box->hide(); - keys->setEnabled( true ); - disable_shortcuts_keys->setEnabled( true ); - client_keys->setEnabled( true ); + keys->suspend( false ); + disable_shortcuts_keys->suspend( false ); + client_keys->suspend( false ); tab_grab = FALSE; control_grab = FALSE; } @@ -1113,9 +1113,9 @@ { removeTabBoxGrab(); tab_box->hide(); - keys->setEnabled( true ); - disable_shortcuts_keys->setEnabled( true ); - client_keys->setEnabled( true ); + keys->suspend( false ); + disable_shortcuts_keys->suspend( false ); + client_keys->suspend( false ); tab_grab = false; if( Client* c = tab_box->currentClient()) { @@ -1128,9 +1128,9 @@ { removeTabBoxGrab(); tab_box->hide(); - keys->setEnabled( true ); - disable_shortcuts_keys->setEnabled( true ); - client_keys->setEnabled( true ); + keys->suspend( false ); + disable_shortcuts_keys->suspend( false ); + client_keys->suspend( false ); control_grab = False; if ( tab_box->currentDesktop() != -1 ) { --- branches/KDE/3.5/kdebase/kwin/useractions.cpp #568153:568154 @@ -281,9 +281,9 @@ void Workspace::setupWindowShortcut( Client* c ) { assert( client_keys_dialog == NULL ); - keys->setEnabled( false ); - disable_shortcuts_keys->setEnabled( false ); - client_keys->setEnabled( false ); + keys->suspend( true ); + disable_shortcuts_keys->suspend( true ); + client_keys->suspend( true ); client_keys_dialog = new ShortcutDialog( c->shortcut()); client_keys_client = c; connect( client_keys_dialog, SIGNAL( dialogDone( bool )), SLOT( setupWindowShortcutDone( bool ))); @@ -302,9 +302,9 @@ void Workspace::setupWindowShortcutDone( bool ok ) { - keys->setEnabled( true ); - disable_shortcuts_keys->setEnabled( true ); - client_keys->setEnabled( true ); + keys->suspend( false ); + disable_shortcuts_keys->suspend( false ); + client_keys->suspend( false ); if( ok ) { client_keys_client->setShortcut( KShortcut( client_keys_dialog->shortcut()).toString()); --- branches/KDE/3.5/kdelibs/kdecore/kglobalaccel.cpp #568153:568154 @@ -65,6 +65,9 @@ void KGlobalAccel::setEnabled( bool bEnabled ) { d->setEnabled( bEnabled ); } +void KGlobalAccel::suspend( bool s ) + { d->suspend( s ); } + void KGlobalAccel::blockShortcuts( bool block ) { KGlobalAccelPrivate::blockShortcuts( block ); } --- branches/KDE/3.5/kdelibs/kdecore/kglobalaccel.h #568153:568154 @@ -215,6 +215,12 @@ * @internal */ void disableBlocking( bool disable ); + + /** + * @internal + */ + // like setEnabled(), but doesn't ungrab (see in KGlobalAccelPrivate) + void suspend( bool s ); private: --- branches/KDE/3.5/kdelibs/kdecore/kglobalaccel_x11.cpp #568153:568154 @@ -82,6 +82,7 @@ : KAccelBase( KAccelBase::NATIVE_KEYS ) , m_blocked( false ) , m_blockingDisabled( false ) +, m_suspended( false ) { if( all_accels == NULL ) all_accels = new QValueList< KGlobalAccelPrivate* >; @@ -133,6 +134,13 @@ return KAccelBase::isEnabled() && !m_blocked; } +// see #117169 - the bug is hard to reproduce, probably somewhere in X, testcase would be probably +// difficult to make, and so on - just don't release the grabs and only ignore the events instead +void KGlobalAccelPrivate::suspend( bool s ) +{ + m_suspended = s; +} + bool KGlobalAccelPrivate::emitSignal( Signal ) { return false; @@ -267,7 +275,7 @@ XFlush( qt_xdisplay()); // avoid X(?) bug } - if( !isEnabledInternal()) + if( !isEnabledInternal() || m_suspended ) return false; CodeMod codemod; @@ -317,6 +325,7 @@ #endif return false; } + KAccelAction* pAction = m_rgCodeModToAction[codemod]; if( !pAction ) { --- branches/KDE/3.5/kdelibs/kdecore/kglobalaccel_x11.h #568153:568154 @@ -96,12 +96,14 @@ virtual bool isEnabledInternal() const; static void blockShortcuts( bool block ); void disableBlocking( bool disable ); + void suspend( bool s ); protected slots: void slotActivated( int iAction ); private: bool m_blocked; bool m_blockingDisabled; + bool m_suspended; }; #endif // _KGLOBALACCEL_X11_H
Hmm, so if I understand it correctly there is a problem that forces me to relogin every two days and even though there is a fix, this is not included in the next bugfix release but we are told to wait for KDE 4.0 which is not due for another few months (best case)? Come on :-(
Am Dienstag, 12. September 2006 07:37 schrieb Daniel Seifert: > this is not included in the next bugfix release but we are told to wait for > KDE 4.0 which is not due for another few months (best case)? If you had looked at comment 62 before you wouldn't have had to write that.
Actually my comment is directed entirely on comment 62 (which I hoped would have been obvious). It seems 62 is a fix for the problem (good) but it isn't going to make it in any relase (bad) "in hope that the problem will be gone by the time of KDE4" (mildly put, a strange argument). And yes, maybe it will be gone in KDE4, but that is a long time away. And yes, I know I can patch it myself (which I am currently doing), but there are a lot of people who are not able to do that. Or who simply may not be aware what this problem is all about - for example it took me three weeks to find this bug report because I was looking at the problem elsewhere.
> Actually my comment is directed entirely on comment 62 (which I hoped would > have been obvious). It seems 62 is a fix for the problem (good) but it > isn't going to make it in any relase (bad) This is the key: "branches/KDE/3.5" > "in hope that the problem will > be gone by the time of KDE4" (mildly put, a strange argument). Misunderstanding. The fix is *not* forward ported to trunk as Lubos hopes that it will be fixed implicitly in KDE4. To make it clear: KDE 3.5.5 will ship the patch. Definitely.
Alright :-) It was a misunderstanding (blush), I (incorrectly) assumed the trunk would be the current release. Sorry for the mixup, I am happy now :-)
Could those, who were affected by this bug, look at #144993, please. I believe that it introduced the (now successfully worked around) Alt-Tab slowness.
Some (all?) of the symptoms fit. I used to have to wait some minutes in order to log out from KDE when it was in use for a longer time (I attributed this to some other issue), also I (very rarely) have very slow key repeat rates.
Please write comments about #144993 to that bug report, thanks. :-)