Version: unspecified (using Devel) OS: Linux When entering text in the search field of the App launcher, the window thumbnail from the Task Switcher overlaps the virtual keyboard. Reproducible: Always Steps to Reproduce: 1. Pull the top bar down 2. Tap the search field above the App Launcher 3. Look at the virtual keyboard Actual Results: Thumbnail overlaps the keyboard Expected Results: Keyboard should be on top Happened with 2012-01-31-15-30-basyskom-plasma-active-devel-meego-usb-live.iso plus updates from 02-01.
This also happens on 2012-02-22-20-00-basyskom-plasma-active-testing-mer-usb-live.iso
This bug is still valid and imo rather serious as it makes entering search terms in the launch area basically impossible (as the thumbnails not only overlap the keys visually but prevent tapping them as well) as soon as an application is open (if I move the keyboard up, it covers the search field itself).
just guessing*: the thumbnail will be in a popup '(ie. unmanaged window) and the keyboard ideally as well (if it is not, it cannot go above the popup) in this case the keyboard could occasionally just raise itself - another solution would be to have the thumbnail in a managed window and tag the keyboard to keep above * "xprop > keyboard.txt; xprop > thumbnail.txt" will tell, but in case it's a popup, xprop will unlikely work this way, because the pointer is grabbed
This bug definitely has to be fixed before the release of PA3. It not only looks absolutely ugly but also stops the virtual keyboard from working while the Task Switcher is moved down, unless the keyboard is moved to the top. If it is not possible to fix it before release, the search filed in the Launcher should be temporarily removed, since it's pretty much useless right now: When the keyboard is moved to the top of the screen, it works but it covers the search field.
at least from KWin side I will not be able to work on it before the release. Also I don't think there is anything KWin could do. I think the solution would be to disable the thumbnails as soon as the search is started, that is when the keyboard pops up
Does the task switcher overlay the keyboard or some preview popups? The latter case is not resolvable but by not showing the previews (actually: any popup) while the VK is used, but the former one would be resolved if the VK had keepAbove set and the taskswitcher panel explicitly had not (while autohiding panels actually should) - or explicitly raises whenever a window is mapped. Also: where are the sources for that taskswitcher? (VK was easy to find but that taskswitcher probably does not even exist at all ;-)
> Also: where are the sources for that taskswitcher? > (VK was easy to find but that taskswitcher probably does not even exist at > all ;-) It's the normal TabBox with layout window_strip controlled through the D-Bus interface
Ahhhh .... ok. -> kwin client -> unmanaged -> no chance to get sth. above it and obviously that would not make the least sense either. => The only sane solution is to configure the VK to be where the strip is not as pointed: > unless the keyboard is moved to the top. Could also be read as "window strip to the top"
To clarify: By "to the top" I referred to the Y axis, not the Z axis.
Yes, one _has_ to separate them in 2D Leaving aside that this is actually unlikely wanted in this case, a Dock (actually any managed window) will not go above an unmanaged window and KWin cannot manage its own window (the tabbox) However, due to the special nature of the keyboard i wonder whether it should not rather be unmanaged and raise itself everytime a(n unmanaged) window is mapped.
it seems to works well now with maliit. still have to do a couple of test with different maliit keyboard plugins (that may create different kinds of windows)
After the last update, the keyboard was correctly placed above the task switcher and responded to taps. However it then didn't appear in the kwallet password dialog anymore. After a reboot, it works in the dialog again but the task switcher bug is there again as well :( This looks pretty strange...
It seems to work consistently now, but I'll watch this a bit more to see if it suddenly stops working again after a few reboots.
I haven't had the problem ever since, so I'm marking it as fixed.