[interfacekit] Re: Helping out
- From: Christof Lutteroth <lutteroth@xxxxxxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Wed, 08 Aug 2007 01:10:59 +1200
Hi!
First of all, thanks for your reply.
Stefano Ceccherini wrote:
Unfortunately we can't change their design, because it will break
every application which subclasses menus, or even uses them in a
slightly "special" way.
The BPopupMenu of the BMenuField indeed did not have the input focus
because the window containing it had flag B_AVOID_FOCUS set.
This is intented, because the menu windows don't have to steal the
focus from the active window, and that's the flag the menu windows
have in BeOS.
Actually, I was not thinking about changing the API but only the
implementation behind the scenes.
I think we have to add some special support for menu windows within
app server. I don't have yet a clear idea on how to handle that. But
we can't just treat menus like any other view or window.
I just saw the KeyDown handler in BMenu with the half implemented
support for keyboard navigation. That's why I assumed that keyboard
events should be dispatched there. How do they get there if the menu
does not have focus? Or is the keyboard navigation code for some other
use of BMenu? Why do you think that menus need special support from the
app server? What is bad about giving a menu the input focus while
tracking? So many questions... it will take me a while to learn the Be
API, please bear with me.
Actually, I would like to refactor the Menu-related classes a bit. I
found them hard to understand. I am not sure if this is the right thing
to do, but in the long run, I would like to replace the polling
mechanism that is used for tracking by an event-driven mechanism.
If in the long run you mean in future releases, I'm all for this, but
this will break the api, so we cannot do that before R1, at least.
Will it really break the API, or can this implementation decision be
hidden? I thought it might be possible to hide it, but there is still a
lot for me to learn.
I was wondering if you know anything in particular that I could help
with. Maybe it's better for me as a beginner to do more specific tasks
(although I enjoy trying to figure out the nebulous stuff, too).
Cheers,
Christof
- Follow-Ups:
- [interfacekit] Re: Helping out
- From: Axel Dörfler
- [interfacekit] Re: Helping out
- From: Stefano Ceccherini
- References:
- [interfacekit] Helping out
- From: Christof Lutteroth
- [interfacekit] Re: Helping out
- From: Stephan Assmus
- [interfacekit] Re: Helping out
- From: Christof Lutteroth
- [interfacekit] Re: Helping out
- From: Christof Lutteroth
- [interfacekit] Re: Helping out
- From: Stefano Ceccherini
Other related posts:
- » [interfacekit] Helping out
- » [interfacekit] Re: Helping out
- » [interfacekit] Re: Helping out
- » [interfacekit] Re: Helping out
- » [interfacekit] Re: Helping out
- » [interfacekit] Re: Helping out
- » [interfacekit] Re: Helping out
- » [interfacekit] Re: Helping out
- » [interfacekit] Re: Helping out
- » [interfacekit] Re: Helping out
- » [interfacekit] Re: Helping out
- » [interfacekit] Re: Helping out
- » [interfacekit] Re: Helping out
- » [interfacekit] Re: Helping out
Unfortunately we can't change their design, because it will break every application which subclasses menus, or even uses them in a slightly "special" way.
The BPopupMenu of the BMenuField indeed did not have the input focus because the window containing it had flag B_AVOID_FOCUS set.
This is intented, because the menu windows don't have to steal the focus from the active window, and that's the flag the menu windows have in BeOS.
I think we have to add some special support for menu windows within app server. I don't have yet a clear idea on how to handle that. But we can't just treat menus like any other view or window.
Actually, I would like to refactor the Menu-related classes a bit. I found them hard to understand. I am not sure if this is the right thing to do, but in the long run, I would like to replace the polling mechanism that is used for tracking by an event-driven mechanism.
If in the long run you mean in future releases, I'm all for this, but this will break the api, so we cannot do that before R1, at least.
- [interfacekit] Re: Helping out
- From: Axel Dörfler
- [interfacekit] Re: Helping out
- From: Stefano Ceccherini
- [interfacekit] Helping out
- From: Christof Lutteroth
- [interfacekit] Re: Helping out
- From: Stephan Assmus
- [interfacekit] Re: Helping out
- From: Christof Lutteroth
- [interfacekit] Re: Helping out
- From: Christof Lutteroth
- [interfacekit] Re: Helping out
- From: Stefano Ceccherini