Bindkey definition conflict

I've redefined some of the bindkeys / shortkeys and one of them is "-" which I want to make "zoom out" instead of its pre-assigned hierarchy-display-decrement function.

I can make the "-" definition disappear from the File>Setup>Customize Menu "Keyboard Shortcut" field for zoom_menu.dec_max_hier replacing with PgDn, and I replace zoom_menu.zoom_out with "-", but it appears the original zoom_menu.dec_max_hier = "-" definition does not really go away, I now get a conflict popup (pic):


How can I purge the "definition residue" so my redefinition is functional?

How can I export and import these keyboard shortcut settings, rather than depending on the session-to-session memory that the tool seems to exhibit? I might also like to share keymaps with others, set up a new machine the same, etc. Is there a file that holds this specifically, or a segment that could be ASCII-edited?


  • Hi,

    You can edit the key bindings in "~/.klayout/klayoutrc" - the line with "". But that's a pretty long long.

    Basically you can distribute key bindings a different ways:

    • Providing a default "klayoutrc" with the application
    • Providing a autorun script that configures the key bindings on the first run (this is a good solution to provide packages which perform some initialization)
    • Forcing a certain key binding by letting the script override these bindings

    In general there is always the conflict between user-specific adjustments and enforced global configurations.

    Replacing the "-" in klayoutrc worked for me. But I'll check whether maybe there is an issue with the user interface.


  • I found the one line in the klayoutrc. It is a bowl of noodles for sure.

    Question - can this line be broken up with extension characters (end or beginning of line) to help readability without ruining function? I'd like to make it look like more of a table, to work on.

  • Went to edit the ~/.klayout/klayoutrc file and found that it holds the modified key bindings I had set up. There is only the one '-' definition (zoom_out) there. But the conflict happens anyway. I guess there must be some other set of definitions that is not touched (maybe just papered over?) by the user key definition.

    Is there perhaps a master key bindings somewhere in the installation hierarchy?

  • Hi,

    Regaring the first question: yes it can, but it will be overwritten when you exit KLayout. I'm not sure what you're trying to achieve - maintain your setup or deploy it to others or into an origanization? If you can describe your use case, I may be able to give better suggestions.

    And there is no "-" bindkey internally and no master setup.

    I can reproduce the issue with "-" if I don't reassign "zoom_menu.dec_max_hier" to something else. Apparently it's not possible to remove a key binding in the editor (another thing I need to look into), hence you have to reassign it to something else. If "zoom_menu.dec_max_hier" isn't given in the "key-bindings" line if will be assumed to be "-". And even if you specify it as empty string like "zoom_menu.dec_max_hier:''", it's taken to be the default.


  • Hi, Matthias,

    My primary motivation is roughly 20 years of Cadence "muscle memory" that trips me up trying to use anybody else's bindkeys. If I set them to what I instinctively do, it's all good.

    Secondary motivation (esp, to get a flat file that can be loaded on command / init) is to be able to propagate this to other machines so my user environment is portable. This is something that maybe smart use of .klayoutrc suffices for (if I were enough smart).

    I did reassign the hierarchy commends to PgUp and PgDn, but still got the "collision" error popping.

    Is there perhaps an init-file command (sequence) that could load, rather than inline the bindkey definition in one line?

    Can individual bindkeys be defined later, via script rather than menu? Is the definition line in klayoutrc one that could be executed through the scripting interface directly, or "wrapped" somehow?

    Can bindkeys be defined in less-than-entire-bundle somehow? That is, maybe I -only- want to set a few keys and leave the rest alone; must I execute the whole definition string, or can I prune it to only do what I need to change?

  • Hi,

    I opened a ticket for the definition conflict: It's about allowing to disable a key binding. I don't really understand why the issue still pops up with PgDown/PgUp. I'm setting "dec_max_hier" to "PgDown" and "inc_max_hier" to "PgUp" and then I'm able to map "zoom_in" and "zoom_out" to "+" and "-" …

    As I said there are different ways to deploy a configuration, depending on your role and system you're using.

    For example, you can store a "klayoutrc" along with the binary (if you're maintaining a organization's central installation). In this case, users will receive this configuration the first time they open KLayout. But after this initialization, they will use their local copy and you cannot impose updates on their config.

    Defining bindkeys by script is possible because all bindkeys are stored in a configuration key ("key-bindings") and such values can be set by script. But only as a whole - you can basically modify it the bindkeys only by parsing the current value, substituting new bindkeys and storing the result back into the configuration. That's not impossible, just somewhat tedious.


  • Would it be possible / practical to make the bindkeys load from a file initially, and allow reload / overwrite?

    I see you closed the ticket, I guess I should pull the latest version (got to go read up on how, again, I usually just take the latest stable mainstream release) and see what's up.

  • Well, in a sense the bindkeys are loaded from a file :)

    If you mean to have an easy way to exchange bindkeys: bindkeys can also be defined by script. So essentially, a script could load the bindkeys from a file in a script-defined format. You could run the script on startup or on demand.

    However, then the bindkey editor in the Setup Dialog becomes obsolete because the changes there will be overwritten by the script.


Sign In or Register to comment.