FreeLists / haiku-appserver / [haiku-appserver] Re: Focus

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

Hi Adi,

Adi Oanca <adioanca@xxxxxxxxx> wrote:
>    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.

That is supposed to happen when you call BWindow::Activate(), yes.

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

Okay, I'll write a floating window test app some day later, if you 
don't have a good one (under R5, I just used ArtPaint for this, maybe 
it works under Haiku as well).

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

Ah, I remember - I'm sorry that I couldn't help you back then, but I 
just didn't know anything about floating windows; I'm still pretty 
clueless in that area, anyway :-)

> R5 defines 3 window concepts: Active, Front and Focus.
[...]
> 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 think Active() is only important from the user side of things. Apart 
from that, I *think* it has no importance in the app_server.
At least with FFM, there can only be one active window, anyway, and it 
doesn't seem to hurt the app in question.

Now for the active window tab - I think it's a good idea to keep the 
border of a window with floating windows active at all times - because 
only then you know to which window the floating windows belong. Maybe 
we should even introduce a third color state for this case, as it 
wouldn't work to well with FFM if it would be the same.
In any case, I think floating windows should just behave like any other 
window - ie. they can be active.

I guess BWindow::IsFront() does not take B_FLOATING_ALL_WINDOW_FEEL 
windows into account?

Bye,
   Axel.