[haiku-appserver] Re: Focus
- From: Adi Oanca <adioanca@xxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Thu, 17 Nov 2005 23:09:47 +0200
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:
