kicad-developers team mailing list archive
Mailing list archive
Re: Tool processing & RunHotKey return
Thanks for the extra info, Ian. I’m now convinced that the hotkey dispatcher should return an accurate “handled” rather than the current “probably handled”. Whatever bugs fall out from that we’ll just have to fix.
Just to further JP’s wxEVT_CHAR_HOOK vs wxEVT_CHAR info, I sent out another email on it a couple of days ago . If the dispatcher/tool-manager ends up skipping the wxEVT_CHAR_HOOK event, wxWidgets will generate a wxEVT_CHAR event (which is far more useful for hotkeys). So often the way to “fix” a hotkey that’s not working due to modifier keys or keyboard differences is to make sure that the wxEVT_CHAR_HOOK event ends up getting skipped. (That’s done in the dispatcher/tool-manager realm by calling evt->SetPassEvent(), which is why I added a bunch of them to the various tool event loops.)
PS: while I now know my way around it to a certain extent, I’m no expert on the event dispatching stuff. So healthy pinches of salt may be in order...
> On 28 Jul 2019, at 06:27, jp charras <jp.charras@xxxxxxxxxx> wrote:
> Le 28/07/2019 à 02:22, Jeff Young a écrit :
>> I think JP ran into this earlier, so he might know more about it.
> In fact issue I h=worked on was the fact the Char events where no
> correctly skipped.
> If I correctly understand the issue related by this mail, this is a
> dispatch issue.
> I am thinking I already saw this issue.
> The key event dispatch incorrectly try to dispatch the key events:
> For me it try to find an action that matches the corresponding hotkey in
> its lists, regardless the fact the action is attached to the active
> frame (the frame having the focus) or not.
> If this is true, this dispatch behavior is really not correct:
> Only actions depending on the active frame must be taken in account.
> This is what the wxWidgets menu accelerators work.
> Now, about wxEVT_CHAR_HOOK and wxEVT_CHAR events (and related hotkeys):
> Among differences between these events, there is one major diff:
> wxEVT_CHAR_HOOK identify the keyboard key (i.e. the not shifted key code).
> wxEVT_CHAR identify the key code (depending on the fact the shift key is
> pressed or not).
> They are very different for keys that have 2 very different key codes.
> I explain:
> On a French keyboard, all "digit" keys have 2 key code (like in many
> other keyboards), but digit keys are shifted.
> For instance the '3' key is also the '"' key.
> In other words '3' and '3' use the same key ( I will call it 3")
> '3' needs to type SHIFT + 3" key
> '"' needs to type the 3" key
> Now what about wxEVT_CHAR_HOOK:
> wxEVT_CHAR_HOOK returns the key '"' with the modifier Shift.
> wxEVT_CHAR returns the key '3' with the modifier Shift.
> As a result: to show the 3D viewer in PCBNEW:
> - on an English keyboard you use Alt+3
> - on an French keyboard you use Alt+"
> And I am not sure this is a bug in wxWidgets:
> some other applications have this annoying behavior, for instance
> Firefox and its zoom commands (but I used also a few other apps showing
> this behavior).
>> Another issue might be that at the end of the tool loop the event will get skipped which will send it to wxWidgets for processing (at which point it will probably come back as a hotkey again). We might already have logic to deal with that, but it’s something to look out for.
>> At the end of the day, though, we need to design around what is “right”. If what’s right breaks other stuff then we need to fix the other stuff.
>>> On 27 Jul 2019, at 17:48, Ian McInerney <Ian.S.McInerney@xxxxxxxx> wrote:
>>> In the tool dispatcher currently, if any action is associated with a key combination (even if the action is not handled by any active tools) then a key event with that combination will not progress further than the dispatchHotKey function in the dispatcher. For instance, this means that the letter 'B' will not make it into any of the dispatchInternal calls inside any program (e.g. eeschema, pleditor, cvpcb, etc.) because it is assigned to a pcbnew action to refill the zones, even when those other programs do not use that action at all so it goes unhandled in the dispatchHotkey function. That event therefore is inaccessible in any tool loops that may be running.
>>> Is there a reason the dispatchHotkey logic looks only at the fact an action with that hotkey exists rather than if any tool has handled the associated action? For my work in cvpcb it would be better if it were the latter, so that any key events not handled by the tools continue processing (e.g. for down/up/left/right keys, single letter keys, etc.). It should be possible to know if the action is handled by the hotkey handler, since they actions are spawned immediately and the handled return value is then available.
>>> Would a change to this system break any of the existing tool loops? e.g., are any unable to cope with receiving key pressed events (I don't think any would be problematic, since some keys such as 'C' don't have an associated action and would therefore generate key pressed events in them)?
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help : https://help.launchpad.net/ListHelp
>> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>> More help : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
> Jean-Pierre CHARRAS
> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> More help : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>