[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-03 5:01:40
Message-ID: 20100603050140.3647E43606 () immanuel ! kde ! org
[Download RAW message or body]
https://bugs.kde.org/show_bug.cgi?id=187718
--- Comment #13 from Alain Knaff <kde kde lka org lu> 2010-06-03 07:01:36 ---
>> If there is only one client message to claim activation, why are there so many
>> different levels of focus prevention ("low", "medium", "high")?
>heuristics dealing with related windows, window types, time stamps...
I see. So which level will completely block this one client message, under any
(timing, window relationship, etc.) circumstances?
>> And why would a (non WM) application ever explicitly ask for focus (rather than
>> wait until it is given focus)
> client internal logics.
I see. But wouldn't it more logical, for that case, to do just the opposite:
the window which *has* the focus instead yields (gives) it to the one who
should have it? Or have a different call, which would only work if the window
currently having focus does indeed belong to the same app...
> think of a pointerless terminal
In that case, wouldn't there still be one application which would play the role
of a window manager?
--
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic