[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-03 0:09:37
Message-ID: 20100603000937.9315443624 () immanuel ! kde ! org
[Download RAW message or body]

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





--- Comment #12 from Thomas Lübking <thomas luebking web de>  2010-06-03 02:08:59 ---
(In reply to comment #11)
> 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... 

> What is the difference in purpose between asking for activation and asking for
> focus?
a window can be active (iff even only as placeholder) but not interested in the
input focus (which is then nowhere and thus does not have to be "stolen" but is
free for another window to safely request focus and activation...)

> And why would a (non WM) application ever explicitly ask for focus (rather than
> wait until it is given focus)
client internal logics.
you could eg. pick a tool in a toolwindow activating some texediting in the
mainwindow.
so while you clicked the toolwindow the doc window shall get the input focus.

also X11 itself does not include the concept of a window manager. there could
be setups where only one application runs that handles input focus of multiple
windows by a client internal concept. (think of a pointerless terminal)

X11 was surprisingly not (exclusively) designed to run windows-a-like homeuser
desktop environments :-P

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