https://bugs.kde.org/show_bug.cgi?id=460961
--- Comment #5 from Matt Whitlock <k...@mattwhitlock.name> --- (In reply to Brent Spillner from comment #4) > Is that too general, though? In a multi-window application such as GIMP, > when a toolbar window is focused, passing a click through to the main window > may not be the intended behavior of a user who selected "Activate and > Raise." That's a fair point. I don't know if the compositor has enough information to discriminate between child windows that are interactive and those that are not, other than by examining the focusable flag. Conceptually, tooltips and other pop-over windows should not be focusable since you're never supposed to interact with them, but I suspect they were implemented as focusable so that they could detect when they lose focus and hide themselves. Of course, ideally the parent widget would hide its associated pop-over whenever the parent window loses focus, but that's harder to implement and might miss some corner cases, leading to the dreaded stuck tooltip. > Do plasmashell and other applications displaying tooltips need to be marked > focusable while doing so? Perhaps the right way to close up the state > machine is simply not to mark windows as focusable merely because they raise > a child. I don't think the panel gets made focusable merely because it has a visible child window. I think it's an intentional flag change. It might be done this way so that it's possible to navigate the panel using the keyboard. That's important for accessibility. That said, I'm not sure why opening the applications menu (or a tray pop-up) by using the mouse should make the panel focusable. If the panel remained unfocusable, then the current click-passing logic would just work. However, that wouldn't solve the issue elsewhere, such as in the Dolphin context menu, where the context menu absolutely does need to be focusable so you can navigate the menu items using the keyboard. -- You are receiving this mail because: You are watching all bug changes.
