Bug 262835

Summary: 'Add Widgets' conflicts with kwin's 'Focus follows mouse'
Product: [Unmaintained] plasma4 Reporter: Elias Probst <mail>
Component: generalAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED UNMAINTAINED    
Severity: normal CC: allo, annma, aseigo, bkn, claude.xavier, eljefedelito, f.stock, hr.denzler, kde, mgraesslin, wonko
Priority: NOR    
Version: 4.8.97(RC2)   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Elias Probst 2011-01-11 10:01:43 UTC
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'.
Comment 1 Hans-Rudi Denzler 2011-01-11 11:30:00 UTC
see Bug 261877
Comment 2 Elias Probst 2011-01-11 13:17:47 UTC
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.
Comment 3 Aaron J. Seigo 2011-01-11 19:43:25 UTC
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.
Comment 4 Elias Probst 2011-01-11 23:27:25 UTC
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.
Comment 5 f.stock 2012-06-11 18:16:17 UTC
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.
Comment 6 f.stock 2012-06-11 18:19:21 UTC
(In reply to comment #5)
> The error is still occuring in 3.8.4.
Typo here, I meant 4.8.3
Comment 7 Myriam Schweingruber 2012-06-13 08:22:12 UTC
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.
Comment 8 Martin Flöser 2012-06-13 08:27:55 UTC
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.
Comment 9 f.stock 2012-06-13 16:57:48 UTC
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).
Comment 10 Myriam Schweingruber 2012-06-19 14:21:49 UTC
I guess we have a consensus from the developers, Martin, Aaron: a WONTFIX?
Comment 11 Myriam Schweingruber 2012-06-20 06:20:17 UTC
*** Bug 278710 has been marked as a duplicate of this bug. ***
Comment 12 Alex 2012-06-20 15:10:04 UTC
before you close with wontfix, please do something with the activities-bar as well, see comment #3 on bug #278710
Comment 13 Myriam Schweingruber 2012-06-21 14:42:02 UTC
(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.
Comment 14 Janek Bevendorff 2012-07-19 21:50:41 UTC
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).
Comment 15 Alex 2012-07-19 22:38:52 UTC
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.
Comment 16 Janek Bevendorff 2012-07-21 09:45:34 UTC
*** Bug 303846 has been marked as a duplicate of this bug. ***
Comment 17 Myriam Schweingruber 2012-08-06 02:26:08 UTC
*** Bug 302900 has been marked as a duplicate of this bug. ***
Comment 18 Xavier Claude 2013-04-11 09:58:12 UTC
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).
Comment 19 Nate Graham 2018-06-08 18:53:47 UTC
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