Excuse me, you all went into deep tech details and I lost the clue. What does that mean from the user side? For now, I created a copy of main @menu and removed all accelerators from top-level items. None of them work except 'Plugins' one, both on Windows and on Linux. I can live with it, but still want my alt-p back actually :-) So as I see the problem - there is a solution, but seems like a single menu item is hardcoded. Again, I see the same picture on both systems, and it's the same - how does that concerns complex Qt events?
воскресенье, 22 сентября 2019 г., 21:45:44 UTC+3 пользователь Edward K. Ream написал: > > On Sun, Sep 22, 2019 at 8:37 AM jkn <jkn...@nicorp.f9.co.uk <javascript:>> > wrote: > > >> The problem was in the traces. I'll see what I can do with the > bindings. > The --trace=keys traces are now much more informative. > > Cool - thank you! > > Alas, there seems to be an intractable Qt problem, explained in #1344 > <https://github.com/leo-editor/leo-editor/issues/1344>. Alt-keys > generate *only* shortcut-override events, and Qt generates *duplicate* > events. Handling them duplicates almost all key presses. > > Googling this problem indicates that no easy solution is likely. The > shortcut-override events come from child widgets, and focus issues are > involved. > > I could try ignoring duplicate events, but adding state/history to already > very complex event filters is asking for trouble. In short, I know of no > reasonable way forward. > > Edward > > P.S. There is no problem with making bindings to Alt keys. The dummy > bindings in leoSettings.leo are never used. The problem is capturing the > incoming key events. > > EKR > > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/f7fddb07-c302-4948-b905-97319b05df33%40googlegroups.com.
