>I want to make some suggestions about AWS. The most
>part of AWS is designed to work only with mouse.
>For more games is useful to be able to navigate
>through menu and select functions with keyboard.
>Also I think that is useful mouse motion to set focus
>of control under it (i mean all kind controls
>not just the buttons).
This is personal preference, and not necessarily "good windowing
practice." Quite a number of windowing systems do not implement
focus-follows-mouse behavior. I believe that AWS has a flag which lets
you turn focus-follows-mouse. At one time it did, however if it does
not then I think it would be a nice feature to add. But you should make
sure to add it based on a flag, and not make it the only choice. =20
>I think that the following features are helpful for
>building of a game menu:
> - "OnMouseOver" trigger
This is not necessary. AWS currently has
"OnMouseEnter/OnMouseExit/OnMouseMove" These three components let you
know when the mouse is over any component, and if it's moving over it.
Simply catching the Enter/Exit messages will let you know when the mouse
is over the component, and is better than an OnMouseOver, since it also
lets you know when the mouse has STOPPED being over your component.
> - "OnKeyPress" trigger
AWS already has an OnKeypress handler. It's just that many
components don't have any default keyboard functionality. This could be
added to them.
> - Focusing controls using keyboard
There is a conceptual problem with this idea. In general, how
do you decide what the next control to be focused is? In a menu system
that might be fairly simple: up and down select the next menu items,
left and right select the next menu. But in general it's hard to say
what those keypresses should do. Additionally, AWS does not have
anything like "tab order", which lets you find which component the user
thinks should be the next one. A general attribute would have to be
added to the awsComponent base class called "TabOrder", and then methods
to find the next component in the tab order would be needed. Recall
that components may be nested, so the logic would have to start at the
beginning of the window hierarchy and search ALL components to find the
next component. Simply doing an incremental search would not work
right, since there's no guarantee that tree order and tab order are
anywhere close to similar.
> - GetFocusedChild function
This is already implemented, tho it's not easily accessible.
The window manager keeps track of which component is the focused one.
It wouldn't be overly difficult to add an accessor function to get this
> - Detecting nearby controls
This is techically already implemented as well, tho probably not
in the way you want. When the mouse is over an area, the window manager
scans the window hierarchy for component frames that contain the mouse
point. All matching frames are collected and the outermost frames are
discarded. OnMouseEnter/Exit messages are then generated. Note that
these functions are only called for mouse clicks currently, this would
be a good place to add the focus-follows-mouse flag (if it's not there
> - Focusing controls must depend on the pressed key (i
>mean if we have=20
> a control in the middle of group of controls
>and we press the "UP" arrow, then we=20
> must focus the control that is above focused
What it two components are perfectly centered above the focused
component? Which component then gets the focus? What if the component
IS the top component? Does focus clip at the top, or wrap back around
to the bottom? Same would hold true for east/west directions. =20
>I'm ready to implement all features above and I want
>to hear opinions and suggestions.
I think that would be very nice, but please make sure and implement the
changes which impact global behavior as flags. Not everyone desires
this sort of behavior. Thank you for your time and effort.