Steps to reproduce: 1. restart kwin 2. press alt+tab 3. exit alt+tab mode 4. press alt+tab again Expected result: window switcher shown in step 2 and 4. Actual result No window switcher shown in step 2, but in 4
Hi Martin, I am debuging the delayedShow in tabbox.cpp https://projects.kde.org/projects/kde/workspace/kwin/repository/revisions/master/entry/tabbox/tabbox.cpp#L833 it might be m_delayedShowTimer`s logical issue ;)
*** Bug 341009 has been marked as a duplicate of this bug. ***
I'm no longer able to reproduce the problem with KWin 5.2 and Qt 5.4
FWIW I'm still having this with Kwin 5.2 and Qt 5.3.x, let's hope an update to Qt 5.4 fixes it :)
yes, I'm also able to reproduce it on my system with Qt 5.3.
*** Bug 348643 has been marked as a duplicate of this bug. ***
*** Bug 366603 has been marked as a duplicate of this bug. ***
Are there any pointers where to start looking for this bug? It's not just alt+tab. The tooltips for the taskbar behave the same. The very first time you over over an application the tooltip shows and hides again (without moving the mouse). Alt+tab is completely ignored at first, but works just fine with any subsequent alt+tab presses. Earlier there was something about m_delayedShowTimer for the tabbox being at fault. I don't think that is the case with this bug. But i don't seem to be getting this weird behavior on for instance the calendar. It opens just fine when clicking it first. What i do notice is that events triggered from KWin seem to suffer from this. The tooltip for an application is - at some point - done via KWin, right? Alt+tab most certainly is. If my assumption from above is correct, than i'm guessing the issue is something as follows. KWin probably does something (trigger a popup dialog, trigger alt+tab, etc..) where it checks for the QmlEngine object. If it doesn't exist it is probably being created on the spot, but the event at that point is not being send again.. Or that's what i think happens.
Am 2016-12-27 15:49, schrieb Mark: > But i don't seem to be getting this weird behavior on for instance the > calendar. It opens just fine when clicking it first. What i do notice > is that > events triggered from KWin seem to suffer from this. The tooltip for > an > application is - at some point - done via KWin, right? Alt+tab most > certainly > is. No, the tooltip is not controlled by KWin. Which means that the behavior of Alt+Tab and taskbar tooltip are quite certainly different and unrelated issues.
If you change the tabbox theme in the KCM to themes, which haven't been used before in the current session the steps 1-4 happen again in the sense of: On 2. it shows the overlay, but doesn't change to the next item. Therefore could it be the QML file not being parsed fast enough?
> Therefore could it be the QML file not being parsed fast enough? unlikely as we block during parsing. But I'm sure the two issues are related.
Git commit e019c9f61edf20c433ac4bf2e3546ce9b5c1104a by Roman Gilg. Committed on 16/01/2017 at 18:11. Pushed by romangilg into branch 'Plasma/5.8'. [TabBox] Remember current model index on SwitcherItem model set In case we need to set the SwitcherItem model in `TabBoxHandlerPrivate::show()`, remember the current index row, otherwise it gets reset to the first item. Reviewers: #kwin, graesslin Tags: #kwin Differential Revision: https://phabricator.kde.org/D4162 M +4 -1 tabbox/tabboxhandler.cpp https://commits.kde.org/kwin/e019c9f61edf20c433ac4bf2e3546ce9b5c1104a