[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:       Alain Knaff <kde () kde ! lka ! org ! lu>
Date:       2010-06-02 15:47:57
Message-ID: 20100602154757.F419D4357A () immanuel ! kde ! org
[Download RAW message or body]

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





--- Comment #9 from Alain Knaff <kde kde lka org lu>  2010-06-02 17:47:53 ---
> there's _one_ way to activate  a client bypassing all WM checks.

Good. And how many ways are there in total to claim focus (including those that
*don't* bypass WM checks), and what is their intended use?

> I hope, this was clear enough.

No, unfortunately, it isn't. I'm still trying to understand which ways are
supposed to be caught by focus stealing prevention, and what their intended use
case is.

For the moment, the only example of intended use I got is WM tools (pagers,
taskbars etc), but their calls aren't affected by focus stealing at all.
Thunderbird's call (fortunately) is being affected by focus stealing, so it
must be a different call. What is it (or what could it be, if there are several
ways matching the observations), and what would its legitimate purpose be?

> As likely as passing the wrong parameter to a ClientMessage event.

Oops, that sounds bad. So it's really like there is a claimFocus(int level)
call, where confusing 2 levels with each other would result in bad behaviour.
And not something like completely completely different apis (like
app_getFocus() versus
getMagicLowLevelHandle().getObscureHandle().getFocusRaw())

-- 
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]