[General Responsiveness]: some clicks are eaten=not executed

[star-buck]

1. MENU-SWITCH:
   switch to alternative menu (kickoff to kicker or viceversa)
   first click on startbutton doesnt do anything (kubuntu-plasma5-201412051356-amd64.iso )
2. TASKS:
   right click on task-manager in panel area to bring up dialog, click on desktop to close it:
   next mouse click eaten, like clicking on menu button does nothing.
3. ICON in panel:
   right click on any icon in panel
   left-click somewhere on the desktop to close popup from right-click
   click on "Panel Edit" mode icon does nothing, only second click activates "edit mode"
4. WINDOW DRAG:
   click on top window bar to focus window: you can right-click on desktop
   click and hold to drag window to move around: you can not right-click on desktop after that (was possible under kde4.x)
5. KMIX (FIXED WITH NEW APPLET):
   left-click on kmix icon in systray
   while kmix dialog is open, try to grab and move a window from window titlebar

[mgraesslin]

1. MENU-SWITCH

I just tried that and can confirm.

[mgraesslin]

Any mouse event on the panel is lost when switching the menu. In fact any mouse event on the panel is eaten while the switch menu is open. This is different to other similar dialogs: systray and menu do not eat the event.

[mgraesslin]

5 KMIX is a bad example: it's using a QMenu and a QMenu grabs the mouse. If a widget grabs the mouse it's expected that no other elements can receive mouse events. That's the basic contract of a context menu and absolutely the expected behavior.

[star-buck]

well, in kde4.x you could have kmix open and still grab and move a window...just saying that this should be normal, expected behaviour.

[mgraesslin]

by that I'm not saying that I think it should work like that from a user perspective. But technically it has to work like that. It's opening a (context) menu and if that doesn't grab the mouse it becomes problematic.

The new Plasmoid is not showing that interaction as it's no longer a QMenu.

The same is the case for other similar menus. E.g. the old Klipper would have prevented mouse interaction, while the new doesn't.

[eikehein]

Just two notes:

a) The KMix popup is a QWidget, not a QMenu, and just from a casual glance I don't see it set a window type
b) Clicking outside with the KMix popup open works fine here

[mgraesslin]

concerning a) not much difference. It's grabbing the mouse, I just verified by:

1. sleep 5 && xwininfo
2. open kmix
3. hover mouse over it
4. got:
   xwininfo: Please select the window about which you
   would like information by clicking the
   mouse in that window.
   xwininfo: error: Can't grab the mouse.

[eikehein]

There's not a single call to grabMouse() in the code tho and xwininfo works fine for me:

xwininfo: Please select the window about which you
would like information by clicking the
mouse in that window.

xwininfo: Window id: 0x380000f "kmix"

Absolute upper-left X: 1426
Absolute upper-left Y: 846
Relative upper-left X: 1426
Relative upper-left Y: 846
Width: 493
Height: 321
Depth: 32
Visual: 0xbe
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x380000e (not installed)
Bit Gravity State: ForgetGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: yes
Map State: IsViewable
Override Redirect State: yes
Corners: +1426+846 -1+846 -1-33 +1426-33
-geometry 493x321-1-33

--- snip ---

What's your kmix version? I have 4.6RC1 using KF5.5.

[mgraesslin]

Eike, might it be that you are running the Qt with the broken mouse grabbing?

[eikehein]

I'm on the 5.4 branch without the patch (unless it got in by now), sure.

[mgraesslin]

I'm on the 5.4 branch without the patch (unless it got in by now), sure.

so you are able to click outside and get xwininfo due to a Qt bug :-P

[mgraesslin]

can you test some more things: please try clicking on the task manager to close it. For me, the next event is not eaten in that case. If you can confirm that I have a theory to create a bug report against Qt.