Version: unspecified (using Devel) OS: Linux Version: 4.7.95-0ubuntu1 (for kdebase-runtime package) - this is Kubuntu Precise updated a day or two ago. I have a 3x3 virtual desktop setup, with task manager settings of 'Only show tasks from the current screen, Only show tasks from the current desktop, only show tasks from the current activity' ticked. Yet the task manager is now showing me a set of windows from a 'random' virtual desktop - it doesn't seem to be consistent as to which one is shown and I'm not even sure it's all the tasks from one desktop or another, but it's definitely not (just) the set from the current one (and doesn't necessarily include all those from the current one). This used to work and has broken somewhere pretty recently. (I had Grouping on by name, but it doesn't seem to make any difference if I use Do Not Group). Reproducible: Always Steps to Reproduce: Login, watch all my terminals get restored from the session. Move between virtual desktops Actual Results: Terminals shown on task manager don't match the ones currently visible Expected Results: Since I ticked the only show on current desktop/screen/etc it should be showing the ones on my current virtual desktop.
Some additional info after chatting with sreich on IRC, who could confirm the bug : * The bug can be reproduced when : - user has several activities - options "Show tasks from current desktop" and "Show tasks from current activity" are selected * sreich infers that the bug lies in the applet, not in the dataengine as he first thought * I could reproduce the bug also with "Icons-Only Tasks" applet, so maybe some common code is involved Should this be a showstopper for the 4.8.0 release, as it totally messes up the taskbar under some conditions ?
Did some git-bisect on this bug : ce97e4fd586ff225f2b2e8c5042baf6821bc52c0 is the first bad commit commit ce97e4fd586ff225f2b2e8c5042baf6821bc52c0 Author: Thomas Lübking <removed.email@address.com> Date: Mon Dec 5 18:13:19 2011 +0100 skip double focus taking createwindow -> manage does so anyway REVIEW: 103337 :040000 040000 59ec86ed81e9f077ef8eed6b33f546cf504c0354 0573d1e49f175729403009415c12f6e07c83e346 M kwin Thomas, what do you think : does this make any sense to have this bug triggered by this commit ? Thanks in advance !
"remotely" The patch itself is rather harmless (avoiding a second update of internal focus chain lists), but alongside activities (or the activity manager, at least i could reproduce it by just showing that cashew popup) there's also another (weird) bug reported. Activating a window trigger a wm_take_focus event, ie. whenever a windows becomes active in whatever way there's like a "fake" click on the taskbar item (but that doesn't require a real taskbar) Here's a workaround for that, you might wanna try whether it fixes this one as well https://git.reviewboard.kde.org/r/103700/ I'm gonna check whether the two commits are related later this week...
Thanks for coming back to me Thomas :) However, the patch in this review has no effect on this bug. I see it has been merged in master already, and the bug is still present in master today. Just to make sure I checked out this specific commit (in case some other commit had reintroduced the bug), compiled and tested, but no change. I'll be happy to provide any kind of help on this issue :) Guillaume
*** Bug 292819 has been marked as a duplicate of this bug. ***
I reverted (locally, of course) the commit ce97e4f, compiled, and the bug is gone. So I can confirm it is indeed the culprit :) However, I don't have enough knowledge to understand how to fix it without reintroducing the bug you fixed...
If you wait a little time, i'll check what's happening on X there and why the second focus is taking place and why it's relevant for the multi activities case and whether this is related to the bug worked around by RR 103700 - but right now, i won't drop out of the tabbing fix branch ;-)
Sure no problem :) I'm not being impatient, just trying to understand what's going on with this bug.
- Does it only affect windows from a session restart? - Does it happen with any decoration that is NOT oygen or tabstrip? (in other words: could not reproduce)
yes it happens only when logging in : my settings are set to "restore previous session", so KDE will restart a bunch of windows that are on different desktops & activities. Did not try with other window decoration, will keep you updated.
ok, makes some sense. will break my dektop then (i don't believe in taskbars ;-)
Guillaume, is https://bugs.kde.org/show_bug.cgi?id=284442 a duplicate?
Anne Marie, no, it looks like a different issue... don't know if it's related since the reporter says it appeared in 4.7.2.
I confirm this on 4.8.0. When logging in and restoring the session the task manager shows items from all the virtual desktops even if told to only show those from the current desktop. When you have some 4 windows open per desktop and 4 desktops, this makes an ugly mess. Clicking on the entries on the task manager takes to the correct desktop, though and once this is done. Furthermore doing so and switching desktops makes the task manager progressively fix its behavior. I understand that this may be a trivial bug, but please in future do not ship new versions of KDE when they are known to include regressions.
Can reproduce. The issue is partially in the taskmanager* and partially because that commit it completely bogus (it's not the actual fixing one but sth. i did on the pass) I immediately spotted that after reverting the commit (since just adding a focuschain update didn't help ;-) If you take a sharp look, you'll notice that the code is not equivalent but the windowEvent() call wasn't present on the original path when creating the client. The result is that the window gets a takeActivity (it gets "urgent" ie. the flashing thing in the taskbar - would have been a helpful comment, btw ;-) what brings us to the taskbar isue: No idea whether this is intended, but the urgency makes the task sticky on the taskbar despite it's the wrong desktop/activity (all properties are set correctly on the window w/or or w/o the bogus commit and the taskitem "knows" -in the tooltip- that this window is on a different desktop) I'm gonna fix that code (ie. make the reverted variant a bit more readable and less a trap) what fixes this one and maybe the issue from comment #3 as well. Sorry for the trouble.
Git commit f34b72593cdfeb012119ea646d4af616083d7387 by Thomas Lübking. Committed on 03/02/2012 at 23:31. Pushed by luebking into branch 'KDE/4.8'. Revert "skip double focus taking" The commit actually introduced an windowEvent processing for new created clients and caused FIXED-IN: 4.8.1 This makes the original code a bit more straight and less confusing and effectively reverts commit ce97e4fd586ff225f2b2e8c5042baf6821bc52c0. M +14 -20 kwin/events.cpp http://commits.kde.org/kde-workspace/f34b72593cdfeb012119ea646d4af616083d7387
Thanks a lot Thomas ! I hadn't noticed the urgency indicator, sorry for that :p Anyway, eagerly waiting for 4.8.1, now !
*** Bug 293567 has been marked as a duplicate of this bug. ***
*** Bug 293518 has been marked as a duplicate of this bug. ***
*** Bug 294837 has been marked as a duplicate of this bug. ***
*** Bug 292785 has been marked as a duplicate of this bug. ***