[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Keypress handling
- From: Phil Martin <phil@xxxxxxxx>
- Date: Mon, 08 May 2006 13:15:45 +0100
- Subject: Re: [XaraXtreme-dev] Keypress handling
Alex Bligh wrote:
In the case where a control and "the page" (the active view?) claim the
same hotkey, the control would normally expect to get the first chance
to use the keypress. 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.
Centralised key handling sounds like a potential rat's nest to me, since
it will have to know information about individual controls, views,
documents, windows, application state and focus location. URGH!
Can we not do this in what seems to me the obvious way? I.e. distributed
and object-oriented - allow the object at the sharp-end, the one with
focus, to handle its own keypresses and if not, pass them up a command
(Er, note that, that's what the Input Focus handling rules say should
happen conceptually so why not /do/ it instead of /simulating/ it...)
I am only advocating grabbing the keypresses used for the page locally.
Anything else would be passed on via the normal hierarchy (i.e. you
don't filter the event in the case you should be passing it on).
But centralising stuff that is designed for the page is exactly what you
want to do isn't it? Otherwise, potentially every control and every
needs to know to pass document keystrokes back to the document, and
sometimes NO window seems to receive keys, which is I think what Luke's
problem was (unless I've misunderstood it).
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.
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!
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
The active view would have a keypress handler that dealt with view
related things and the application would have keypress handler that
dealt with application related things. In practice, the active view
might delegate its keypress handling to the application to keep hotkey
management in one place but that's not a centralisation inherent in the