The accel key for the settings menu clashes with the accel to increase drill size

[KaiMartin]

Current git head defines the accel to open the settings menu as [alt-S]. This collides with the accel to increase the drill size of the via or pin under the mouse cursor. Apparently, the menu takes catches the event first. This renders holes impossible to increase via the keyboard.

The drill accel is part of a whole group of related actions. The accels [s], [shift-s], [alt-s], [shift-alt-s] all affect vias and pins. So it's better to not change these in order to resolve the collision.

Proposal: change the accel for the settings menu to [alt-t]. This combo does not seem to be used anywhere.

I attached a rather trivial patch to gpcb-menu.res.in which does just this.

---<)kaimartin(>---

[KaiMartin (kmk-familieknaak)]

The menu accel keys have been added to pcb fairly recently. Since then the accel to increase hole size is broken. I for one use this feature with almost every layout.
How come. this regression is considered "low" importance? I'd have expected a 'medium'.

---<)kaimartin(>---

[Bert Timmerman (bert-timmerman)]

Alt+V for the "View" pull down menu is affecting the "Via Tool drill + 5 mil" too.

Maybe better to drop the whole accel key for pull down menus functionality.

Kind regards,

Bert Timmeman.

[Chad Parker (parker-charles)]

All keystrokes involving the "alt" key should be remapped.

[Chad Parker (parker-charles)]

The following are the shortcuts involving the alt key:

<alt-a> Select all
<alt-shift-a> Unselect all (is this really needed?)
<alt-r> Auto route selected rats
<alt-s> Change drill size +5 mils
<alt-shift-s> Change drill size -5 mils
<alt-v> SetValue(ViaDrillingHole, +5, mil)
<alt-shift-v> SetValue(ViaDrillingHole, -5, mil)

These all work fine in the lesstif HID, but alt-s and alt-v are used to access the settings menu and view menu. In order to create the minimum disruption, I'm only going to update the gtk hid for now.

We should consider overhauling the key bindings for the next major release to make them consistent. Like, <key> and shift-<key> be used to interact with objects in the layout (shift making them larger since shift produces capital letters). ctrl-<key> and ctrl-shift-<key> be used to interact with the software for the purposes of things like saving, changing the view, updating route styles, highlighting connections, and such.

For this fix I am going to implement the following mappings:
alt-a --> ctrl-a
alt-shift-a --> ctrl-shift-a
alt-s --> ctrl-d
alt-shift-s --> ctrl-shift-d
alt-v --> ctrl-l
alt-shift-v --> ctrl-shift-l

alt-r will stay alt-r since there isn't presently a conflict, and there isn't really a better combination available.

[Chad Parker (parker-charles)]

I've pushed a branch to git that implements these changes in the gtk HID: LP1496603.

[Bert Timmerman (bert-timmerman)]

Hi Chad,

I reviewed, cherry-picked and pushed your commit to master.

I think we should keep the lesstif ky-bindings as close to the gtk key-bindings as possible, I will create an additional commit on the topic branch for review (second pair of eyes).

Kind regards,

Bert Timmerman.

[Bert Timmerman (bert-timmerman)]

Hi Chad,

Technically the bug filed by KaiMartin is resolved.

While I'm looking at menu files I found a couple of diffences between the between the gtk and the lesstif menus.

I pushed another commit to decrease the differences a bit.

Another observation is that decreasing/increasing values are hard coded in the menu, for example:

    {"Vias -10 mil" ChangeSize(SelectedVias,-10,mil)}
or

    {"Via Tool size +5 mil" a={"Shift-V" "Shift<Key>v"} SetValue(ViaSize,+5,mil)}

What about metric values ?

Maybe we should review the whole menu system to get rid of hard coded values and units.

I will start a new bug report for this one.

Kind regards,

Bert Timmerman.