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.