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

List:       kde-bugs-dist
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.2621C43605 () 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 watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic