[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

Re: [XaraXtreme-dev] Keypress handling

Phil,


In the case where a control and "the page" (the active view?)


yes, sorry, sloppy terminology.


claim the
same hotkey, the control would normally expect to get the first chance to
use the keypress.


Isn't that the opposite of what we decided? For instance, a wxCheckBox
will claim a "space" keypress if given it.


If I understand you correctly you're saying that a
central keypress filter should detect that focus is not in the page but
in a control and in that case, not let the page have the keypress first.
That is where I start to have issues with the idea because it's the thin
end of the wedge. More and more of those kinds of tests will inevitably
get added to the central keypress filter and it will become a rat's nest.


No. I'm saying the application (which gets the chance to filter all
keystrokes), should determine if the focus is in a camelot window
(other than a modal dialog or a control within it), AND that the
window is not a keyboard-handling-control (wxTextControl etc.). If so
(with the exception of return, and ALT-F4 etc.) it should pass the
keystroke to the "page" (i.e. the active view) directly. If not,
it should just allow keys to follow their normal key-processing route.


Much better to let individual objects make small decisions based on local
knowledge (possibly statelessly) than have one big lump of stateful code
using information from many different sources.


But that means you will have to subclass every wx control which will be to
say the least painful. To avoid that, you end up with doing Connect() to
put an event handler on first. But that isn't very OO either, and misses
the point that the framework can eat the keypresses without them being sent
to any control.


If that's not possible because of wx problems then either:
1. That might be a good enough reason to fix wx.
2. Camelot could use the central filter simply to divert keypress events
from wx's flawed hierarchical event system into it's own internal version!


I don't think there is a problem in wx. I just think what we are
trying to do with Camelot is not in wx's normal model. BUT you can
get around it ALREADY without fixing wx.


Individual controls or windows wouldn't have to know anything about the
outside world - they would be properly OO encapsulated, using only the
keypresses they want to use and returning all others to the event system
unclaimed.


That's great in theory, but all existing wx controls claim keys that
you actually want. So unless you want to rewrite or subclass every control,
you cannot rely on these controls not claiming keypresses.

Alex