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 |
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:
- new mouse button bindings; most notably: pan on middle button (similar to gschem, gimp, inkscape) and popups on the right button (as in most other X11 apps nowdays)
- context sensitive popup (per object type under the cursor)
- a combination of gschem-like multi-stroke hotkeys
- only a very few single key hotkeys that are too common to leave out (such as ctrl+c)
- reorganized menu structure, less flat, least useful menus are in deeper submenus; as a result submenus are smaller, and with the tear-down feature it's easier to convert them into a permanently open window to keep them around
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
- the old menu files will be more or less unmaintained
- unmaintained means: new features may not be automatically added in them: we don't want to waste our time in trying to keep 3 menu files up to date
- unmaintained means: bugs are less likely to be detected, reported, debugged or fixed with the old menu files - so on the long run, they will probably have bugs
- all existing documentation will be modified to use the new menu file slang (menu names and keys and mouse buttons); all new documentation will use the new menu file slang; it will be harder to apply the docs/tutorials of new features if you are using the old menu file
- if you report a bug with a recipe and you are using the old menu file, you will need to convert the slang in your bugreport; if you forget to do that, I will not be able to reproduce the bug and will probably give it back; that would introduces delays and time wasting on both sides
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?).