kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

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.
> 
> Cheers,
> Jeff.
> 
>> 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)?
>>
>> -Ian
>> _______________________________________________
>> 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
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


-- 
Jean-Pierre CHARRAS