pcb-rnd knowledge pool


New, default menu file for 2.0.0

menu2 by Tibor 'Igor2' Palinkas on 2018-03-29

Tags: announcement, menu, menufile, key, binding, mouse, button, pan, click

node source



Abstract: Describe the transition from the old menufile to the new, multi-stroke key binding menu for release 2.0.0.

  We are switching to a new default menu file with the next release, to get rid of some historical legacy and potentially ease the learning curve for new users. Changing the default certainly involves some risks , but it is inevitable by now.

1. what changes to expect

The new menu file will feature:

2. " Halp!! I do not want to change!"; "How do I stick with the old menu file?"

The menu file name (or path) is a configuration item now (unlike in previous versions where it was hardwired in HIDs). For compatibility, if the new setting is not present or is empty, the code will keep on using the old mechanism: lesstif loads the old lesstif menu, gtk loads the old gtk menu. The following table shows how to configure pcb-rnd for different menu files:

goal configuration
default: new menu file rc/menu_file should be set to {default}; this is how we ship pcb-rnd
old, per HID menu file rc/menu_file should be set to empty string: {}
custom menu file rc/menu_file should be set either the full path to the file (the string must contain at least one slash) or to a suffix, e.g. {foo} , and then the pcb-menu- foo .lht is searched in the menu search path.

The simplest way to do the override is an user config in your $HOME dir.

3. why should you switch to the new menu default file

Yes, learning new menus and new key bindings is always a PITA. It was a hard decision for me to finally go for it, but I really think it's inevitable. I hope the better organization in both the menus and the key bindings will justify for the learning curve.

4. History and trends

The original menu files were split: pcb-rnd had one for gtk and one for lesstif. The rationale was that gtk has more widgets/dialogs available, thus it needs less menus. The most prominent example on this is the layer selector.

Related to this, pcb-rnd has two important assumptions or design decisions regarding to menus. One is that all hotkeys are configured through the menu system, the other is that all GUI HIDs must provide tear-down menus (even if this requires hacking the tookit).

4.1. dialogs

The latter is a very important consideration, because this allows us to convert a submenu into a dialog box (or window) that the user can keep open, next to the drawing area. This means we don't need to implement custom dialogs just to list a few operations or checkboxes. It also means the user can easily create new such windows, as long as they are defined as submenus.

4.2. How it all evolved

The original menu of PCB was simple back in the 90s. It started out as a rather flat menu system. As more and more features got introduced, more menus appeared. In a flat menu this means a lot of settings listed in a tall menu.

Meanwhile we started to struggle with the original single-key-stroke model too: many features got mapped to single stroke key bindings, which means a base key plus modifiers. There are about 40 such base keys and 3 modifiers, plus about 20 more keys that will not combine well with modifiers. Modifiers can be combined, but it's not practical to require the user to press all three, which means there are about 7 combinations. This leads to about 300 available key combinations total. But these keys are not to be assigned randomly, because that would make remembering them impossible. Instead, there was some logic, like 's' is 'grow size' and 'shift+s" is 'shrink size'; more generally, shift was very often (but not always) used to invert the operation.

At the end, the two HIDs together used up more than 170 key combinations , which means more than 50% of all available combinations were taken. This made it harder and harder to find available keys for new functions, yet alone make their assignment meaningful and easy to remember.

In the multi-stroke system, without using modifiers , using only 2 long sequences and only the 26 letters, the number of available combinations is 676, which is already more than double of the original set. Using 3 long sequences for rarely used functionality the space of available combinations jump up to the range of 15000 available combinations. It is much simpler to find meaningful key bindings in such a large space (e.g. {a p s} for 'auto, place, selected' may be easier to remeber than ctrl+p, especially if later we also want to have vairations like {a p a} for placing 'all' instead of 'selected' (which would have been shift+ctrl+p maybe?).