is there any way to disable alt-letter hotkey for top-level menus?

[gar]

I'd love to use those hotkeys as commands shortcut but they are busy with some never-used functions like menu actions.

How can I reassign them to something i really need?

[Edward K. Ream]

On Fri, Sep 20, 2019 at 9:47 AM gar <gar...@gmail.com> wrote:

I'd love to use those hotkeys as commands shortcut but they are busy with some never-used functions like menu actions.

How can I reassign them to something i really need?

The never-used functions are placeholders.  This is an operating system "feature".

--trace=keys shows that Leo never receives Alt keys related to menus.  Depending on your OS it may be possible to override this behavior.

This behavior is similar to Shift-Ctrl-0.  There are, supposedly, ways to override such keys on Windows, but I have never found a workaround that survives a reboot.

Edward

[gar]

AFAIK when using Qt you need to specify those shortcuts by hand with
'&' char - pass addMenu("&File") to make a menu item with F as
shortcut.
Maybe you do quite the same in your code when create top-level menu?

> --
> 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+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/CAMF8tS3i3LV2eiQETsrc1Wc5Fq8R_T4%3DEBkBxoULCwa%3DtbknrQ%40mail.gmail.com.
>

[Chris George]

You can try a custom menu.

Open leoSettings.leo and navigate to the main @menu node.

Copy this node and paste it into your myLeoSettings.leo under the @settings node.

Change the top level headlines to lose the hotkey markers.

The downside is remembering to update your @menu node every now and then so you don't miss out on new features. :-)

HTH,

Chris

On Friday, September 20, 2019 at 8:42:52 AM UTC-7, gar wrote:

AFAIK when using Qt you need to specify those shortcuts by hand with
'&' char - pass addMenu("&File") to make a menu item with F as
shortcut.
Maybe you do quite the same in your code when create top-level menu?

2019-09-20 17:59 GMT+03:00, Edward K. Ream <edre...@gmail.com>:
> On Fri, Sep 20, 2019 at 9:47 AM gar <gar...@gmail.com> wrote:
>
>> I'd love to use those hotkeys as commands shortcut but they are busy with
>> some never-used functions like menu actions.
>> How can I reassign them to something i really need?
>>
>
> The never-used functions are placeholders.  This is an operating system
> "feature".
>
> --trace=keys shows that Leo never receives Alt keys related to menus.
> Depending on your OS it may be possible to override this behavior.
>
> This behavior is similar to Shift-Ctrl-0.  There are, supposedly, ways to
> override such keys on Windows, but I have never found a workaround that
> survives a reboot.
>
> Edward
>
> --
> 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-e...@googlegroups.com.

[gar]

That's great advise, and it works fine.

Bad thing is necessity to keep eyes on updates.

Can leo make clones of nodes in the external files? As I understand, pyLeo.leo is always present, so we can easily make clones.

пятница, 20 сентября 2019 г., 19:26:23 UTC+3 пользователь Chris George написал:

[gar]

Not all of leo's top level menu items have access accelerator (Settings and Run dont).

I would suggest to get rid of those accelerators for the future versions since seems like they are not actually useful.

(Why I do advocate this? I am now trying to make leo's editing powerful enough to compete with vim. This requires me more new commands and more shortcuts to bind them to. And some of very perspective keys are busy with almost nothing.)

[gar]

пятница, 20 сентября 2019 г., 19:26:23 UTC+3 пользователь Chris George написал:

You can try a custom menu.

Well it almost worked.. But 'Plugins' item still have accelerator.

I suspect it is hard coded somewhere in the leo's core.

 

[jkn]

That's an interesting idea - but it doesn't work for me (on Linux)

myLeoSettings.leo is clearly being read, since I can add a 'stuff' top level menu from there

But if I remove the '&' from '&Window', save and restart ... Alt-W still brings it up.

(I want this to use some CRiSP bindings, which are heavily weighted towards ALT-keys)

[jkn]

PS: looks like there is some automagic to use the first letter, regardless of any '&' in the headline. If I change the entry to '@menu Iwndow',

then ALT-I brings focus to the menu.

And I now remind myself that if I hold the ALT-key only down, each top-level menu entry has a little underscore under it's first character (including 'Run', which like 'Window' doesn't have an '&'.

{{{

Leo 6.0-devel, dock branch, build 18af67e858
2019-05-28 23:56:38 -0500
Python 3.6.8, PyQt version 5.9.5
linux

}}}

Jon N

[Edward K. Ream]

On Fri, Sep 20, 2019 at 2:58 PM jkn <jkn...@nicorp.f9.co.uk> wrote:

But if I remove the '&' from '&Window', save and restart ... Alt-W still brings it up.

The & is an accelerator, not a binding.

Edward

[jkn]

Hi Edward

    y-e-s ... but then how is what Chris George suggesting supposed to work?

I do have Alt-W bound to save-file BTW.

    J^n

[Edward K. Ream]

On Friday, September 20, 2019 at 5:02:59 PM UTC-5, jkn wrote:

The & is an accelerator, not a binding.

    y-e-s ... but then how is what Chris George suggesting supposed to work?

I don't think Chris's suggestion will work. The problem is that Windows grabs alt keys.

Edward

[jkn]

I thought 'gar' was saying that it mostly - worked. Maybe not.

In any case, is this:

    https://stackoverflow.com/questions/37020992/qt-prevent-menubar-from-grabbing-focus-after-alt-pressed-on-windows

of any use/relevance? (C++ not Python,, but you get the drift)

    J^n

[Chris George]

I haven't spent a lot of time with Leo's keyhandling.

My laptop keyboard is setup as a standard 105 key us in X11. xev reports no less than seven individual modifier keys that are available, not counting the Caps Lock key as I have already remapped that s l-ctrl long ago.

The keys are l-shift, l-ctrl, windows or super, l-alt, r-alt, r-ctrl, r-shift. They all report individual keycodes to Linux and there is an absolute ton of information out there about apping, remapping etc.

It seems to me that the ability to address a few more modifier keys would solve a lot of problems.

Now I know that cross platform will definitely be a problem. I don't know if these keys can be addressed individually on a Mac or in Windows.

Food for thought anyway.

Chris

[Edward K. Ream]

On Sat, Sep 21, 2019 at 3:49 PM jkn <jkn...@nicorp.f9.co.uk> wrote:

> In any case, is this:

    https://stackoverflow.com/questions/37020992/qt-prevent-menubar-from-grabbing-focus-after-alt-pressed-on-windows

of any use/relevance?

I doubt it.  This is not a qt issue, it is an OS issue.  I wouldn't spend much time on this.

Edward

[Edward K. Ream]

On Sat, Sep 21, 2019 at 4:44 PM Chris George <techn...@gmail.com> wrote:

It seems to me that the ability to address a few more modifier keys would solve a lot of problems.

Now I know that cross platform will definitely be a problem.

True, but having more modifiers on particular platforms could be useful.

There was a recent PR that added support for two modifiers.  Don't remember which.

Edward

[jkn]

Hi Edward

    Except, I can run the CRiSP editor under exactly the same OSes (Win7, Linux of various flavours) as I run Leo, and its ALT-x orientation for commands runs perfectly.

So I don't really understand why you think this.

    Regards

    Jon N

[Edward K. Ream]

On Sun, Sep 22, 2019 at 7:05 AM jkn <jkn...@nicorp.f9.co.uk> wrote:

    Except, I can run the CRiSP editor under exactly the same OSes (Win7, Linux of various flavours) as I run Leo, and it's ALT-x orientation for commands runs perfectly.

So I don't really understand why you think this.

I think it because --trace=keys doesn't show the required Alt keys.

But perhaps this trace doesn't tell the whole story.  I'll investigate.

Edward

[Edward K. Ream]

On Sunday, September 22, 2019 at 7:51:09 AM UTC-5, Edward K. Ream wrote:

> --trace=keys doesn't show the required Alt keys. But perhaps this trace doesn't tell the whole story.

The problem was in the traces.  I'll see what I can do with the bindings.

Edward

[jkn]

Cool - thank you!

[Edward K. Ream]

On Sun, Sep 22, 2019 at 8:37 AM jkn <jkn...@nicorp.f9.co.uk> 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.  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

[gar]

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 написал:

[Edward K. Ream]

On Mon, Sep 23, 2019 at 1:43 AM gar <gar...@gmail.com> wrote:

Excuse me, you all went into deep tech details and I lost the clue.

What does that mean from the user side?

It means that Qt prevents users from binding Alt-keys that are bound to menus.  I know of no reasonable workaround.  Don't bother messing with settings. That can't possibly work.

Edward

[Chris George]

I have been investigating using --trace=keys.

Using chords, like Ctrl+Shift and using Meta as well, I tried the following
key binding in Leo.

Ctrl+Meta+Shift+a = spell-find

Leo responds in the terminal at startup: Warning: bad shortcut specifier:
'Ctrl+Meta+Shift+a = spell-find' and the chord does not work.

Examining the key trace information, Leo correctly identifies Ctrl, Shift,
Meta, and a and treats it as a chord. The same holds true for simpler
modifications like Meta+a and Shift+Meta+a etc.

show-bindings has evidence of "Meta" being a thing in the past. I read
through the google groups and didn't discover anything directly related to
eliminating "Meta" as a modifier.

The following do not work. All cause Leo to spit out the warning to the
terminal at startup.

Meta+a
Ctrl+Meta+a
Ctrl+Shift+Meta+a
Alt+Meta+a

etc.

All are identified correctly according to --trace=keys.

Am I missing something?

Leo 6.1-devel, devel branch, build 53cf6d1bb1
2019-09-23 10:35:13 -0500
Python 3.6.8, PyQt version 5.12.3
linux

Chris

On Monday, September 23, 2019 at 8:49:53 AM UTC-7, Edward K. Ream wrote:
>
> On Mon, Sep 23, 2019 at 1:43 AM gar <gar...@gmail.com <javascript:>>

> wrote:
>
> Excuse me, you all went into deep tech details and I lost the clue.
>> What does that mean from the user side?
>>
>
> It means that Qt prevents users from binding Alt-keys that are bound to

> menus. I know of no *reasonable *workaround. Don't bother messing with

[Edward K. Ream]

On Mon, Sep 23, 2019 at 11:38 AM Chris George <techn...@gmail.com> wrote:

I have been investigating using --trace=keys.

Using chords, like Ctrl+Shift and using Meta as well, I tried the following key binding in Leo.

Ctrl+Meta+Shift+a = spell-find

Leo responds in the terminal at startup: Warning: bad shortcut specifier: 'Ctrl+Meta+Shift+a = spell-find' and the chord does not work.

It's the other way around:

spell-find = Ctrl+Meta+Shift+a

Edward

[Chris George]

Hah. That explains a lot. :-)

[gar]

Does that mean that if one remove accelerators from menu item's string - Qt wouldn't be interested?

So the approach with overriding menus is quite fine?

And if so - then the only obstacle is the ugly "Plugins" item which accelerator is hardcoded somewhere?

пн, 23 сент. 2019 г. в 18:49, Edward K. Ream <edre...@gmail.com>:

--

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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS3BFqPPrFeFAN2ONKrXOFpO82A%3Dt%3D8cYXvg0mUKLBCQEA%40mail.gmail.com.

[vitalije]

On Tuesday, September 24, 2019 at 6:14:49 AM UTC+2, gar wrote:

Does that mean that if one remove accelerators from menu item's string - Qt wouldn't be interested?

So the approach with overriding menus is quite fine?

And if so - then the only obstacle is the ugly "Plugins" item which accelerator is hardcoded somewhere?

Indeed you were right, it was hardcoded. The revision e74419f3  fixes this. If you update to latest revision in devel branch, and remove '&' from plugins menu in your settings, it won't be bound to Alt-p.

Vitalije

[gar]

Vitalije, thanks a lot!  

I encountered another interesting and odd behavior.

When language different from english is enabled - all <alt>-based shortcuts dont work while <ctrl>-ones do.

This behaves the same both on win and lin.

Why can this be so?

[Edward K. Ream]

On Mon, Sep 23, 2019 at 11:14 PM gar <gar...@gmail.com> wrote:

Does that mean that if one remove accelerators from menu item's string - Qt wouldn't be interested?

No. It means no such thing.

Accelerators and bindings are completely different.

Afaik, you can't bind Alt-P to anything, because Alt-P will bring up a menu that starts with P.  This has nothing to do with accelerators.

Edward

[Edward K. Ream]

Great!  It looks like what I just wrote was totally wrong.

Edward

[vitalije]

On Tuesday, September 24, 2019 at 11:12:52 AM UTC+2, gar wrote:

Vitalije, thanks a lot!  

I encountered another interesting and odd behavior.

When language different from english is enabled - all <alt>-based shortcuts dont work while <ctrl>-ones do.

This behaves the same both on win and lin.

Why can this be so?

This is most likely Qt issue. While searching for hard-coded Plugins menu, I found that Ctrl-<key> are passed as accelerator argument to Qt, while others are passed just as '&' character inside label. Not sure, but it might be that '&' makes accelerator only the following byte in name, which won't work for non-ascii letters. 

Vitalije

[gar]

Oh, that means that Qt is cooked in a wrong way.

I believe that if alt modifiers were passed as accel arg - they would have been working ok

вт, 24 сент. 2019 г. в 12:26, vitalije <vita...@gmail.com>:

--

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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/abce7794-dbb3-4169-abb8-2065f88521de%40googlegroups.com.

[gar]

Returning back to this issue....

Now to get rid of top-level menus accelerators I have to keep a complete menu tree in myLeoSettings.

Recently Edward wrote that it is possible to amend menus w/o duplicaing the whole tree, but I cannot find this message.

Can you please remind me what the advice was? Can I use it to remove accelerator from top-level menu items of Leo and so remove (maybe outdated) menu tree from myLeoSettings?

вт, 24 сент. 2019 г. в 17:08, gar <gar...@gmail.com>:

[Edward K. Ream]

On Fri, Dec 25, 2020 at 3:10 PM gar <gar...@gmail.com> wrote:

Can you please remind me what the advice was? Can I use it to remove accelerator from top-level menu items of Leo and so remove (maybe outdated) menu tree from myLeoSettings?

The alt[+-]s\b regex search in leoSettings.leo quickly found the binding to Alt-s:

# These commands do nothing except serve as placeholders for the show-bindings command.
menu-shortcut = Alt-C # Cmds menu.
menu-shortcut = Alt-E # Edit menu.
menu-shortcut = Alt-F # File menu.
menu-shortcut = Alt-H # Help menu.
menu-shortcut = Alt-O # Outline menu.
menu-shortcut = Alt-P # Plugins menu.
menu-shortcut = Alt-S # Search and Settings menus.
menu-shortcut = Alt-W # Window menu.

The comment indicates that disabling these bindings is unlikely to help. Indeed, Alt bindings are likely system bindings.

I don't remember anything about our previous conversation, but now perhaps I have a half memory about system bindings :-)

Let's look at Leo's core to see if there is anything else that can be done. Searching for 'menu-shortcut' finds only this:

@g.command('menu-shortcut')
def menuShortcutPlaceHolder(self, event=None):
    """
    This will never be called.
    A placeholder for the show-bindings command.
    """

So it looks like Leo isn't even trying to do anything with system bindings.

Edward

[gar]

A year ago we all have discovered that Qt handles '&' as a mark of placeholder in the item title. And the only way to get rid of placeholders - is to get rid of &s.

Then you advised me to create a copy of the main menu tree in the myLeoSettings outline.

Recently I saw a discussion that you have implemented a feature to overwrite single items in menu tree w/o copying everything. But now cannot find this original message.

I hoped that this could help me to remove this ugly @menu tree in my settings. But looks like you dont remember this post too :-)

[gar]

Here what I did to solve the problem programmatically.

In leoPyRef, in node `pbc.doMenus & helper` to line 11 `name = h[len('@menu') :].strip()` added `.replace('&', '')`, so that the resulting line became `name = h[len('@menu') :].strip().replace('&', '')`

The problem with accelerator gone. But this is not what everyone wants, it is just the proof of the concept.

How I do see the fix. There should be a setting in myLeoSettings, say `@bool menu-show-accels` by default set to True. If it is equal to False then accelerators are ignored.

I am actually not sure that this controller has  and should have access to c.config at this point. So the quick fix seems impossible to me - it must be moved to some upper-level.

Edward and devs, can you please advise where to search for the right place? And maybe the setting must be more versatile - say to specify to remove accels only for top-level menus and leave unchanged all the rest or something.

[gar]

Good candidate is `@menuat` directive. Now there's a few actions it supports, but it looks a good place to add another like `noaccel`

Will try this idea later.

[gar]

What am I going to do with @menuat.

Reminder. `@menuat` directive has the following format: `*<nodepath>* *<action>* *[clipboard]*`, where action is one of: before, after, append, cut, copy

Proposal. add another action `amend` which has parameter s/what-re/with-re (which is similar to :s vim's command). When leoConfig meets this directive it takes node's header and substitutes it applying given rule. Profit.

Edward, do you want such an enhancement in leo's core?

[Edward K. Ream]

On Sun, Dec 27, 2020 at 3:50 AM gar <gar...@gmail.com> wrote:

> Edward, do you want [the @menuat] enhancement in leo's core?

Seems reasonable. Please create a Leo issue for this. When you are ready, please reference the issue from the PR and vice versal.

Thanks.

Edward