[haiku-development] Re: B_WILL_ACCEPT_FIRST_CLICK (updated patch)

Hello,

My updated patch is available at http://www.mos6581.org/20090531_5.diff

Axel Dörfler wrote:

Brecht Machiels <brecht@xxxxxxxxxxx> wrote:
Personally, I feel it is up to the user to decide whether a window should accept the first click or not. It should also be a global setting, and not something the application should choose. There might be exceptions to this rule, such as the Deskbar. However, I think B_AVOID_FOCUS is more appropriate in this case.
I know there is not much enthusiasm about changing the BeOS behavior or adjusting the API, but I feel this might be something that could be improved upon a lot. 

I see two solutions:
1) we introduce a wrapper for Desktop::ActivateWindow(). As far as I've experienced, this works pretty well. However, it's a bit of a hack and might cause some unexpected behavior. 2) we deprecate the use of B_WILL_ACCEPT_FIRST_CLICK and introduce the possibility to prevent windows popping to front in the normal mouse mode on drags in general.
AFAICT the status quo is only really annoying if you wanted to implement something like the "click to focus" method you're working on. But I guess you're right that it's far from perfect, too.
The status quo also results in inconsistent behaviour for the FFM mode for windows that have set B_WILL_ACCEPT_FIRST_CLICK.
I have added the 'wrapper' for ActivateWindow() again, but I have moved it to a more sensible location. Desktop::ActivateWindow() remains unchanged, but there is now a new function Desktop::SelectWindow() that gets called when Window::Activate() is called.
While this seems to work pretty well, I think we should clean up the API a bit, so we can remove the code in Desktop::SelectWindow() that tries to guess what is the intended behaviour.
Can we introduce Window::Select() that focusses/activates the window depending on the mouse mode? Window::Activate() will then raise the window in all mouse modes, just like it did before. This will ensure backwards compatibility while providing a more sensible API for new applications.
I think that 2) would have the problem that an application would then still need to decide on its on when to put the window to front, which is not really a big deviation from what it does now, only the logic would be reverted.
True. A choice between Window::Select() and Window::Activate() would be helpful here.
I know, this is not really helpful. From an application developer's POV, I think giving a window focus, and bring it to front should be two different actions. Maybe we could have a window action class/method/ whatever that you can just tell your intentions, and it will then do whatever fits the current mouse mode best to achieve this. Like with HTML where you can, say, ask specifically for a bold font (ie. Activate()), or just use <strong> when this is all you want to achieve.
I suppose Window::Select() would do exactly this. Should we also provide a Window::BringToFront() (no focus)?
I have also changed the Deskbar window to use B_AVOID_FOCUS, as I feel this results in much less annoying behaviour in all mouse modes. Perhaps I've overlooked something, however.
Last but not least, can we deprecate B_WILL_ACCEPT_FIRST_CLICK, now that the user can set globally? IMHO, it should not be up the the application to choose this. 

Kind regards,
Brecht

Other related posts: