Summary: | a popup dialog should not steal window focus | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | brice rebsamen <brice.brice> |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED DOWNSTREAM | ||
Severity: | normal | CC: | postix |
Priority: | NOR | ||
Version: | 4.3.2 | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
brice rebsamen
2009-11-23 04:07:53 UTC
What is your "Focus stealing prevention level" set to in System Settings -> Window Behavior? It is set to low. I will increase it and see what happens. If the problem persists I will report again. Thanks I found a way to test: in synaptic, install package noip2: it asks for login information (popup dialog). To test again, remove package and config file (complete removal). Btw, the dialog window is called debconf. Using a focus stealing prevention level of high, that debconf dialog does not steal the focus away. I could not find any documentation about those levels. Is there any? Could I have the link? I guess some tooltips would help us make our choice. The combo box has a "what's this" tooltip that can be activated with the "what's this" button in the decoration (Which it seems that System Settings does not display so that's a problem...). Quoted for easy reference: """ This option specifies how much KWin will try to prevent unwanted focus stealing caused by unexpected activation of new windows. (Note: This feature does not work with the Focus Under Mouse or Focus Strictly Under Mouse focus policies.) None: Prevention is turned off and new windows always become activated. Low: Prevention is enabled; when some window does not have support for the underlying mechanism and KWin cannot reliably decide whether to activate the window or not, it will be activated. This setting may have both worse and better results than the medium level, depending on the applications. Medium: Prevention is enabled. High: New windows get activated only if no window is currently active or if they belong to the currently active application. This setting is probably not really usable when not using mouse focus policy. Extreme: All windows must be explicitly activated by the user. Windows that are prevented from stealing focus are marked as demanding attention, which by default means their taskbar entry will be highlighted. This can be changed in the Notifications control module. """ By the sound of it is Synaptic that's broken as it doesn't use the normal focus handling calls and instead forces the window manager to focus the window instead. I will report this bug to the synaptic people and see what they think of it. The normal focus handling calls you're talking about, are they standard calls that should be implemented by KDE and Gnome apps alike? Or is this a Gnome/KDE incompatibility that will be difficult to solve? this is actually a long standing bug in synaptic. See https://bugs.launchpad.net/synaptic/+bug/176002 Well they are not actually "calls" as such; it's more of just how the windows are handled. An application should never request focus for any of it's windows unless they were created as a _direct_ response to a user action--e.g. the user clicking a button. A window appearing after a delay is not a direct user action and therefore the window should not be forcefully focused. Details of how windows request focus can be found in the EWMH (Specifically _NET_WM_USER_TIME [1]) and KWin's activation.cpp file [2]. [1] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552314 [2] http://websvn.kde.org/trunk/KDE/kdebase/workspace/kwin/activation.cpp?revision=1049334&view=markup |