Version: unspecified (using KDE 4.5.95) OS: Linux When using kwin's 'Focus follows mouse' setting, the 'Add Widgets' panel cannot be used. Reproducible: Always Steps to Reproduce: 1. Open 'kcmshell4 kwinoptions' 2. Set 'Policy' to 'Focus Follows Mouse' + apply settings 3. Click on the 'Cashew' icon of a panel 4. Click on 'Add Widgets' Actual Results: As soon as 'Add Widgets' was clicked, the panel for adding widgets appears for a moment and disappears then again instantly. Expected Results: I'd expect to be able to add widgets, also when using kwin's 'Focus follows mouse'.
see Bug 261877
Thanks for adding this reference. I just checked and this fix is already in 4.6 RC2 (4.5.95) which I'm running here, so this fix didn't solve my bug but a similar approach could be used to fix it.
use the right click menu on the cashew. there are too many edge conditions to meet for focus-follows-mouse for this to work. one thing you can do is set the timeout for focus switching to be longer as that often helps with these kinds of issues.
I don't see why this 'edge case' should be a reason not to fix this behaviour. I actually don't see any further edge cases here. Then I'd actually rather suggest disabling the functionality instead of suggesting a workaround, as this will just confuse a lot of people too. Increasing the timeout for focus switching doesn't make any sense IMHO, as the reason why I'm using "Focus follows mouse" is the increased speed of switching between windows without needed another click.
The error is still occuring in 3.8.4. Also when trying to open the activity manager from the "cashew" and when trying to open them from a control panel. The option "focus follows mouse" makes it absolutly unusable to work.
(In reply to comment #5) > The error is still occuring in 3.8.4. Typo here, I meant 4.8.3
Confirmed, I work around this by using the right click on the desktop instead of the cashew. But I agree with Aaron: this is probably not possible to fix. Subscribing Martin who might have an idea.
Not much which can be done. I'm a FFM user myself and know how difficult it is to use this dialog. But it is possible to use it. With F(S)UM it's more or less impossible to be used. We could alter the behavior of the add widget dialog by allowing Plasma to query KWin's focus policy, but I would not recommend to go that road.
I would consider it not to "good style" to let the software change the mouse position, but if you open the dialog one could place the mouse inside the new window (dont know if the kde/qt framework allows this, or if you have go down to the x-server to send the mouse move/warp event, so it maybe technical unfeasible).
I guess we have a consensus from the developers, Martin, Aaron: a WONTFIX?
*** Bug 278710 has been marked as a duplicate of this bug. ***
before you close with wontfix, please do something with the activities-bar as well, see comment #3 on bug #278710
(In reply to comment #12) > before you close with wontfix, please do something with the activities-bar > as well, see comment #3 on bug #278710 Which is a different issue, please file a separate report.
I can confirm this for 4.8.97, but only when the policy is set to "Focus _under_ mouse" or "Focus strictly under mouse" (which is a pretty nonsensical policy to my taste, but there are probably people out there who use it).
does NOT happen with the usual focus follows mouse (focus on mouse contact) with KDE 4.8.4 from Kubuntu. When using the cashew, the widget-bar is where the panel-settings bar was before, when right clicking and selecting "add widgets" from the menu, the widgetbar opens and there is no problem with a maximized windows, maybe when there are other windows between the cursor and the bar.
*** Bug 303846 has been marked as a duplicate of this bug. ***
*** Bug 302900 has been marked as a duplicate of this bug. ***
I don't understand why the "Add Widget" panel closes when it loses the focus. I think it should only closes when the user clicks on the cross (or it should exist a settings to set this behavior).
Hello! This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug is already resolved in Plasma 5. Accordingly, we hope you understand why we must close this bug report. If the issue described here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging Thanks for your understanding! Nate Graham