[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    [Bug 187718] Focus screwed up after closing emacsclient window (with
From:       Thomas Lübking  <thomas.luebking () web ! de>
Date:       2010-06-02 16:44:48
Message-ID: 20100602164448.CA211435F4 () immanuel ! kde ! org
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=187718





--- Comment #10 from Thomas Lübking <thomas luebking web de>  2010-06-02 18:44:42 ---
on the NETWM level there's actually just this one client message to claim
*activation* _explicitly_
the source parameter ("what requests this activation") then causes the force
vs. not force handling.*

the focus protection does not affect the messages indicating a WM Tool source.
nothing (NOTHING) but such tools should this forcefully take the focus.

there's however a difference between claiming active state and input focus,
latter is done via XSetInputFocus and implicitly requires activation - this is
what applications are usually supposed to do as it is what they actually want.

(aside this there's implicit actiavtion by mapping, ie. showing windows and oc.
the user input way, like clicking or pointing a window)

there's a pretty extensive explanation in kdebase/workspace/kwin/activation.cpp
plase notice that the various attempts to prevent applications from stealing
the focus are WM internal "features"

*the various toolkits oc abstract this message and for KDE you differ between
activateWindow() and forceActiveWindow()

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin

[prev in list] [next in list] [prev in thread] [next in thread]