[haiku-appserver] Re: Focus

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.

Other related posts: