kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

sorry, meant KEY_DOWN / KEY_UP, got them mixed up.  Translated vs.
untranslated.

On Thu, Mar 1, 2018 at 9:47 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
wrote:

> On 3/1/2018 9:28 AM, Jon Evans wrote:
> > Here's a blog post from the developers of Atom editor talking about
> > solving this problem:
> > https://blog.atom.io/2016/10/17/the-wonderful-world-of-keyboards.html
>
> I always new keyboard issues were bad but I didn't think they were this
> bad.  Someone needs to sit down with keyboard and/or os manufactures and
> start beating them about the head and shoulders with a clue bat until
> they fix this mess.  So basically we have to create key mappers to
> handle both os and keyboard layout differences to have any hope of
> providing sane hotkey behavior.
>
> >
> > I have not studied this at all yet but perhaps it is relevant (i.e.
> > maybe we should be looking at EVT_CHAR too?)
>
> These are the events from EVT_CHAR.
>
> >
> > On Thu, Mar 1, 2018 at 9:19 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx
> > <mailto:stambaughw@xxxxxxxxx>> wrote:
> >
> >     On 2/28/2018 3:46 PM, Wayne Stambaugh wrote:
> >     > On 2/28/2018 2:31 PM, jp charras wrote:
> >     >> Le 28/02/2018 à 17:45, Wayne Stambaugh a écrit :
> >     >>> In the process of attempting to fix this bug[1], I ran into an
> issue
> >     >>> with the '/' hotkey for all main frames.  For some reason, the
> >     hotkey
> >     >>> help dialog is being displayed for both '/' and '?' keys which
> >     broke the
> >     >>> track posture switching in pcbnew.  This bug only seems to affect
> >     >>> windows.  The attached patch fixes the issue but changes the
> >     menu entry
> >     >>> shortcut text from '?' to 'shift+?' which would make pcbnew
> >     different
> >     >>> from all of the other mainframe windows which is ugly but it's
> >     better
> >     >>> than a broken hotkey.
> >     >>>
> >     >>> While I was at it, I took a look at the schematic editor and
> >     sure enough
> >     >>> the same behavior exists except that the same change as the
> attached
> >     >>> patch does not fix the issue so the bus wire entry hotkey is
> broken.
> >     >>> When I set a debugger breakpoint in the
> EDA_DRAW_PANEL::OnKeyEvent()
> >     >>> function, it is not triggered for either a '/' key.  The '?' key
> >     does
> >     >>> trigger the breakpoint.  Did someone create a character hook
> >     somewhere
> >     >>> that could be preventing EDA_DRAW_PANEL from ever receiving the
> >     '/' key
> >     >>> presses and passing them directly to the SCH_EDIT_FRAME?  I
> >     cannot find
> >     >>> any reason why the EDA_DRAW_PANEL::OnKeyEvent() event handler is
> not
> >     >>> being called for this key on windows.
> >     >>>
> >     >>> Cheers,
> >     >>>
> >     >>> Wayne
> >     >>>
> >     >>> [1]: https://bugs.launchpad.net/kicad/+bug/1751812
> >     <https://bugs.launchpad.net/kicad/+bug/1751812>
> >     >>
> >     >> Wayne,
> >     >> Because the hotkeys can be redefined by user, I don't think your
> >     fix is working.
> >     >
> >     > '/' is the default hotkey for change track posture in pcbnew and
> place
> >     > bus wire entry in eeschema.  So user hotkey definitions are not
> >     relevant
> >     > since I have not changed any of my hotkey defaults.  What is odd
> >     is that
> >     > this fix works for pcbnew but not eeschema.
> >     >
> >     >>
> >     >> Moreover it happen mainly in US keyboards
> >     >> (I am guessing the chars '?' and '/' are the same keyboard key)
> >     >
> >     > They are on the same key on US keyboard.  That being said '/' is
> >     not the
> >     > same as key code as 'shift+/' or at least they shouldn't be the
> same.
> >     >
> >     >>
> >     >> On Windows, the key events are really tricky, and I never be able
> >     to fix the accelerators versus
> >     >> hotkeys issues.
> >     >>
> >     >> In this case the issue is due to the complexity of keys events:
> >     >> The simplified event list is:
> >     >>
> >     >> - first the EVT_CHAR_HOOK_EVENT is send with key code = '/'
> >     >> if not captured:
> >     >> - send EVT_CHAR_EVENT is send with key code = '?'
> >     >>
> >     >> and in fact there are more events sent, both using
> >     EVT_CHAR_HOOK_EVENT and EVT_CHAR_EVENT.
> >     >>
> >     >> This is true for each key: a event is send with code
> >     corresponding to the non shifted code, and then
> >     >> to the shifted code (if the envent is not captured)
> >     >>
> >     >
> >     > While all of this is informative it still does not answer the
> question
> >     > as to why the '/' character is never getting handled in
> >     > EDA_DRAW_PANEL::OnKeyEvent() while the '?' character is being
> handled.
> >     > I'll keep digging around because something is different between the
> >     > schematic and board editors.
> >     >
> >
> >     JP,
> >
> >     I figured out what is going on with some simple tracing.  On windows
> >     with US keyboard layouts, the '?' key is sent as a 'shift+/' which
> isn't
> >     unexpected.  What is unexpected is that we are only allowing the
> shift
> >     key to be passed when keys 'a' - 'z' and 'A' - 'Z' are pressed by
> this
> >     code and associated comment:
> >
> >         /* Disallow shift for keys that have two keycodes on them (e.g.
> >     number and
> >          * punctuation keys) leaving only the "letter keys" of A-Z.
> >          * Then, you can have, e.g. Ctrl-5 and Ctrl-% (GB layout)
> >          * and Ctrl-( and Ctrl-5 (FR layout).
> >          * Otherwise, you'd have to have to say Ctrl-Shift-5 on a FR
> layout
> >          */
> >         bool keyIsLetter = ( localkey >= 'A' && localkey <= 'Z' ) ||
> >                            ( localkey >= 'a' && localkey <= 'z' );
> >
> >         if( event.ShiftDown() && ( keyIsLetter || localkey > 256 ) )
> >             localkey |= GR_KB_SHIFT;
> >
> >     This means any keys such as ';:', ''"', ',<', '>.', '/?', etc. will
> most
> >     likely be broken when used as hotkeys.  I could easily add the '/' to
> >     the keyIsLetter text code but that is an ugly hack which will most
> >     likely break for non-us keyboard layouts.  Any ideas how to implement
> >     this cleanly or is this just an ugliness we have to live with due to
> >     keyboard layout issues?
> >
> >     Cheers,
> >
> >     Wayne
> >
> >     _______________________________________________
> >     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>
> >
> >
>