Jax says (5:43 PM):
In some cases it seems to consume when it shouldn't. Like dialogs shouldn't so that the cursor keys and shortcuts can still be used. I'll look at that soon.
Παυλος says (5:44 PM):
Ah, that is different
Dialogs are not a child of any widget - they are windows, which are children directly of the container [DesktopWindow]. Key events go to whichever widget has the focus, then up the parent tree as far as the containing window.
Παυλος says (5:45 PM):
So, if you really want them to bubble up to the top-level, you need to tweak the key-event routing in DesktopWindow to feed key events to basewindow if they haven't been consumed by the currently focussed floating window
Jax says (5:48 PM):
So we have this:
void DesktopWindow: ropogateKeyEvent(Widget *target, Event &evt)
{
// send the relevant keyboard event to the given widget, recursing to its parents if the event is not consumed
if (evt.Type == Event::KeyDown)
target->OnKeyDown(evt);
else if (evt.Type == Event::KeyUp)
target->OnKeyUp(evt);
if (evt.IsConsumed())
return;
Widget *parent = target->GetParentWidget();
if (parent)
Propogat
amd we should change it so that if:
if (evt.IsConsumed())
return;
we should send it to basewindow?
instead of the return;
Παυλος says (5:50 PM):
Yes, either that, or tweak the function that calls it [DesktopWindow.DispatchEvents]. It's not entirely obvious where you want the event to go, though - sending it to the base window proper -rather than its focussed widget - is questionable, but in the general case, sending it to the focussed widget may lead to unintuitive behaviour.
Παυλος says (5:51 PM):
It might instead be cleaner to provide a 'default key handler' on the DesktopWindow, to which all unhandled key events are sent. But it might not.
Jax says (5:51 PM):
And handle cursor keys and such there instead of in BaseWindow?
Παυλος says (5:52 PM):
Possibly. The handler would have to be set up in MainWindow [as that is what subclasses desktopwindow], but could refer to a bound method on BaseWindow
Jax says (5:53 PM):
Hum
Παυλος says (5:54 PM):
[this would also provide a way to cleanly separate keypresses that should be handled when in placement mode, and those which should not]
[there is a related question of what the 'correct' behaviour is when a modal dialog is visible - bearing in mind that in instances where you're placing objects, this isn't the case]
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jax says (5:43 PM):
In some cases it seems to consume when it shouldn't. Like dialogs shouldn't so that the cursor keys and shortcuts can still be used. I'll look at that soon.
Παυλος says (5:44 PM):
Ah, that is different
Dialogs are not a child of any widget - they are windows, which are children directly of the container [DesktopWindow]. Key events go to whichever widget has the focus, then up the parent tree as far as the containing window.
Παυλος says (5:45 PM):
So, if you really want them to bubble up to the top-level, you need to tweak the key-event routing in DesktopWindow to feed key events to basewindow if they haven't been consumed by the currently focussed floating window
Jax says (5:48 PM):
So we have this:
void DesktopWindow: ropogateKeyEvent(Widget *target, Event &evt)
{
// send the relevant keyboard event to the given widget, recursing to its parents if the event is not consumed
if (evt.Type == Event::KeyDown)
target->OnKeyDown(evt);
else if (evt.Type == Event::KeyUp)
target->OnKeyUp(evt);
if (evt.IsConsumed())
return;
Widget *parent = target->GetParentWidget();
if (parent)
Propogat
amd we should change it so that if:
if (evt.IsConsumed())
return;
we should send it to basewindow?
instead of the return;
Παυλος says (5:50 PM):
Yes, either that, or tweak the function that calls it [DesktopWindow.DispatchEvents]. It's not entirely obvious where you want the event to go, though - sending it to the base window proper -rather than its focussed widget - is questionable, but in the general case, sending it to the focussed widget may lead to unintuitive behaviour.
Παυλος says (5:51 PM):
It might instead be cleaner to provide a 'default key handler' on the DesktopWindow, to which all unhandled key events are sent. But it might not.
Jax says (5:51 PM):
And handle cursor keys and such there instead of in BaseWindow?
Παυλος says (5:52 PM):
Possibly. The handler would have to be set up in MainWindow [as that is what subclasses desktopwindow], but could refer to a bound method on BaseWindow
Jax says (5:53 PM):
Hum
Παυλος says (5:54 PM):
[this would also provide a way to cleanly separate keypresses that should be handled when in placement mode, and those which should not]
[there is a related question of what the 'correct' behaviour is when a modal dialog is visible - bearing in mind that in instances where you're placing objects, this isn't the case]