Keybinder v2 notes/problems

[Pecan]

I've lost all my shortcuts again. I'm on 11979.
See the config file attached.

Does the plugin logs when it fails to set a shortcut? I don't see any error/warning messages.

rev 11979 is before the keybinder fixes. Update your keybinder plugin.

[oBFusCATed]

If I see correctly

Code

    * Keybinder 2.0.11 2020/03/02 fix missing/conflicting shortcuts when using older .conf on newer build
      - Check for mismatched menu id's to global accelerators id's
        Cf.,This will allow a global to override an old menu item.This happends when a new build does not match the current .conf file
        The non-matching .conf menu item has an incorrect id anyway.
      - When a .conf menu id matches a default( current structure) menu id, also make sure the menu path (parentMenu) also matches.
        It can mismatch when using a keybinder .conf configured from a previously built version of CodeBlocks on a newer build.
      - Set the global accelerators table before calling Initilaize::Update() else globals are missed on the first invocation of KeyBinder/Configure.
    
    
    git-svn-id: https://svn.code.sf.net/p/codeblocks/code/trunk@11974 2a5c6006-c6dd-42ca-98ab-0921f2732cef

is the last commit for the keybinder and its revision is 11974... I'm talking about commits in trunk/master.

[Pecan]

I've lost all my shortcuts again. I'm on 11979.
See the config file attached.

Does the plugin logs when it fails to set a shortcut? I don't see any error/warning messages.

Fixed At revision: 11993
KeyBinder 2.0.12 2020/03/23 Match .conf to menu structure (by menu titles) to replace old menu ids with newer.

[oBFusCATed]

Should I pick this for 20.xx?

[Pecan]

Should I pick this for 20.xx?

Yes, please do. It compares by menu title as you had suggested.
It can now find the new menu id when the menu structure changes.
Thus preserving user defined accelerators even when the menu structure is radically changed by a new build.

 

[oBFusCATed]

What happens if there are duplicate menu items? How does it handle it?

I'll test it myself a day or two and then it will go to 20.xx...

[Pecan]

What happens if there are duplicate menu items? How does it handle it?

I'll test it myself a day or two and then it will go to 20.xx...

There wont be duplicates. Keybinder compares with the full menu path not just the item title.
Eg., "&Build::Run" can't match "&MyPlugin::Run" (if there was such an item title);

Thanks for testing.

[oBFusCATed]

BTW: Is this a regression relative to 17.12. I've never been able to preserve my keybinder settings for years. If this is not a regression, I'd rather prefer not to delay the release even further...

[Pecan]

BTW: Is this a regression relative to 17.12. I've never been able to preserve my keybinder settings for years. If this is not a regression, I'd rather prefer not to delay the release even further...

Sorry, I don't know what you mean by "Is this a regression..."

But this new KeyBinder version is the first time KeyBinder has attempted to save all the users bindings between re-builds that altered the menu tree ids.

[oBFusCATed]

If the problem existed in 17.12 then not fixing it in 20.xx is not a regression. If problem wasn't there and it exists now then it is a regression. The idea of this is if the software got worse and not better.

[Pecan]

If the problem existed in 17.12 then not fixing it in 20.xx is not a regression. If problem wasn't there and it exists now then it is a regression. The idea of this is if the software got worse and not better.

In my view, the software has gotten better. It saves all the users' defined key bindings, even when CB gets re-built and/or wxWidgets changes the way it assigns menu ids.

Version 17.12 bailed out when there were more than three bindings that had no matching menu ids.

[oBFusCATed]

I don't deny this. I don't know if it is worth it to do rebuilds.

[Pecan]

I don't deny this. I don't know if it is worth it to do rebuilds.

Since it was you that was annoyed about losing your bindings, it might suggest that others are as interested in saving them as you are.
I know I'd appreciate it, I'm tired of losing bindings everytime I have to do a major build.
But I understand that we all have limited contribution time.

[oBFusCATed]

Hm, now I've lost the keybindings for prev/next bookmark (alt-pgup/pgdown).
Any idea why this might have happened?
Currently using rev 12002. No idea how this has happened. I don't remember removing them manually.

Looking in the config the keys for these menu entries are empty.
Would it be possible to store only bindings different from the default? Or somehow manually set by the user?

[oBFusCATed]

I've lost my local bindings once more. Rev 12012 at the moment.

Would it be possible to implement storing only non-default bindings (the ones I've actually set (only 3 at the moment))?
It will make debugging this a bit easier.
When are keybindings applied? Can the plugin change bindings in the middle of the execution?
Would it be possible to print an error when reading the bindings fails?
My C::B is crashing a lot, so it might be corrupting the files, but I'm finding about this corrupting late.