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

Re: [XaraXtreme-dev] Keypress handling

Alex Bligh wrote:


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 the
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 window
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).

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.

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 unclaimed.

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 design.