Re: [XaraXtreme-dev] Keypress handling

[Phil Martin <phil@xxxxxxxx>]

Alex Bligh wrote:

> Phil,
>
> > 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
> > chain?
> >
> > (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.

Phil