Hi Axel, On 11/17/05, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote: > Hi, > > this goes mostly to Adi, but maybe someone else has an idea, too (at > least I think Adi wrote that comment). > > In RootLayer::RevealNewWMState() there is a comment that two windows > could have focus at once. Yes, I put it there because in R5, when selecting a floating window it's tab is also highlighted, which I'm OK with. The problem is that, they both (main and floating window) are activate(d), which means by the BeBook that: active window is made frontmost, its title tab is highlighted, and it becomes the target of keyboard events. I put that bookmark there to remind me that I haven't tested the new code inside this method with floating windows. I think there is a problem in that a floating window decorator needs to be invalidated sometimes to give of to take the highlighted state. > While I see that behaviour when opening a floating window in BeOS (two > window titles can be activated at that time), I can only reproduce it > when working with floating windows when there are text controls in both > windows (so that they have focus) - this results in two blinking > cursors which I find rather confusing. > I would consider this behaviour a bug in BeOS, and not something we > should reproduce. Am I missing something? No you're not missing anything. When testing the R5's behavior I found several defects in this area, and I remember writing about those in emails and IRC, but nobody helped me, so I went and implemented in R5's way. R5 defines 3 window concepts: Active, Front and Focus. 1. Focus - it's clear for everyone. It's the window that accepts keyboard events. And it be can only one at a given time. At least from app_server's PoV. The blinking cursor in both main and floating window is based (I think) on ::IsActive(), IsFocus(). Any kind of window can have focus - be it normal, modal or floating one. 2. Active - By the BeBook this means: active window is made frontmost, its title tab is highlighted, and it becomes the target of keyboard events. If I'm not mistaken floating windows _can_ have active state (::IsActive() returns true), and I find it good and confusing at the same time! A floating window _can't_ be "made frontmost", it can't have front state! At the same time, I find it normal that, when I have the floating window selected and it has focus, it be the active window. IMO, a window is active if the user _works_ with it. By "works" I understand it has Focus. That's what I get. 3. Front - As you know floating windows cannot have front state. This is because front state means: "the first self sustained window". To know what is the front-most window, the window manager could take the first window in its list, but note that the last one may be a floating one. So the term "Front" means: "the first window in the list excepting floating ones", the first self sustained window. While I understand the need for Focus to get the window which accepts KB events and Front to know the first/most-visible important window, I don't understand the need for the term "Active"! I really would like to hear your opinions. bye, Adi. bye, Adi.