[haiku-appserver] Re: Focus

Hi,

Axel Dörfler wrote: 
  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).

Oh, I have. :-) The problem is it's overly commented by the number of scenarios I tried. :-) I think it's better to write a cleaner one for yourself. It takes 5 minutes. :-)

   The only problem is: floating windows are broken since July. By you. :-)

   Will try to fix this shortly.

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. 

    Exactly!
I coded Active like this:
WinBorder *
Workspace::Active() const
{
        // in case of a normal or modal window
        if (fFrontItem && fFrontItem == fFocusItem)
                return fFrontItem->layerPtr;

        // a floating window is considered active if it has focus.
        if (fFocusItem &&  (fFocusItem->layerPtr->Level() == B_FLOATING_APP ||
                                                fFocusItem->layerPtr->Level() 
== B_FLOATING_ALL))
                return fFocusItem->layerPtr;

        return NULL;
}

   because I saw this was the behavior in R5.


At least with FFM, there can only be one active window, anyway, and it doesn't seem to hurt the app in question.

Yap, I saw. I did dozens of tests. The behavior is strange for me... 'Front' and 'Focus' are more than enough.
What feels the most strange is the fact that when the mouse comes over a window, its ::WindowActivated() hook is _not_ called! (that's how I remember). Yet somehow, the window knows it gained focus and the cursor starts blinking in a text area. Maybe a hidden/secret B_WINDOW_FOCUSED message?
Is there another way that I am not aware of to make the cursor blinking(or display focus)?

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. 

    No problem with me. I agree; that why I put that bookmark in RootLayer. 
:-)

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.

Why not? I see no problem. I won't lit down the main window's decorator until it or any of its floating windows loose focus.

In any case, I think floating windows should just behave like any other window - ie. they can be active. 

    OK, but what 'active' means?

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

It returns false. Although this kind of window is self sustained, I followed the same path as for the other kind of floating windows. I can make it different if you want - so that it can have front status.


bye,
Adi.

Other related posts: