input for radius/diameter dialog is not recorded on the first keypress when using the "r" keyboard shortcut

[kevenwyld]

Steps to reproduce:

1. Create a sketch on the XY plane
2. draw a circle anywhere
3. select the circle geometry and press the "r" keyboard shortcut.
4. attempt to type a single number like "1" into the input box.

Expected behavior: A "1" replaces the currently selected portion of the current radius/diameter

What actually happens: The dialog does not respond on the first try. Pressing "1" again will replace the current number.

This does not happen when clicking the radius/diameter button from the toolbar. It is only an issue when using the keyboard shortcut.

I attempted to make a video of the issue however since my keyboard is not visible in the video it's not very helpful.

I'm on the latest (as of today anyway) nightly snap.

OS: Ubuntu Core 20 (i3/i3)
Word size of FreeCAD: 64-bit
Version: 2022.1021.14555 (Git shallow)
Build type: Release
Branch: (HEAD detached at 2022.10.21-2-edge)
Hash: d307b5c936403e8dca3f24b5c1e64bd16c88b28d
Python version: 3.8.10
Qt version: 5.15.5
Coin version: 4.0.1
OCC version: 7.6.3
Locale: English/United States (en_US)

OS: Arch Linux x86_64
Kernel: 6.0.2-arch1-1
WM: i3
Theme: Adwaita-dark [GTK2/3]
Icons: Adwaita [GTK2/3]
Terminal: alacritty
Terminal Font: Source Code Pro
CPU: AMD Ryzen 5 4500 (12) @ 3.600GHz
GPU: AMD ATI Radeon PRO W6800
Memory: 11624MiB / 64102MiB

Name                 Version               Rev  Tracking     Publisher    Notes
freecad-realthunder  2022-10-21-gd307b5c9  85   latest/edge  realthunder  -

[BloodyRain2k]

I've noticed the same problem but with the normal distance constraint, for example when selecting an edge and pressing "d" to add the contraint. For whatever reason, /any/ first key press will be discarded, or land whereever... Doesn't matter if it's an actual number or just ESC, the first key pressed does nothing.

However, when /not/ being openend with the associated key but instead just clicking the toolbar, this does /not/ happen. Further more: when using the distance constraint on a circle, it will throw an error (as intended), BUT when the key was used to do so, the first key pressed will /still/ be discarded as well, so I have to press ESC twice to get rid of the error vs only once when caused by clicking the toolbar.

So it seems to be related to something with the keybind. Especially because I for example do not have the issue with the radius, likely due to different key binds, mine's "shift+r".

Another weird thing is that when I use the key to create the constraint, there's like half of a second delay between pressing and the console saying that it's gonna do the constraint and the dialog / error actually appearing. But it's instantanious when clicking the toolbar button for the constraint.

Thinking it might be just waiting for a 2nd key of a combination (even though I explicity checked that the "d" key is only bound to a single command in all of FreeCAD) like "r r" for rectangle, I found out that the symmetry contraint bound to "s" behaves in the same way. The arc constraint "a" however does not for whatever reason...

Edit: also the tangent constraint "t" behaves the same like distance and symmetry. Rebinding distance to "alt+d" also removes the first key being discarded, and binding it back to just "d" reintroduces it. So it seems definitely related to the keybind somehow.

Anyways, this is the version I am running:

OS: Windows 7 Version 6.1 (Build 7601: SP 1)
Word size of FreeCAD: 64-bit
Version: 2022.1128.26244 +5318 (Git)
Build type: Release
Branch: LinkDaily
Hash: d45d221edcc7a757eb4e4eb638da0db5ed2759aa
Python version: 3.8.10
Qt version: 5.15.2
Coin version: 4.0.1
OCC version: 7.6.2
Locale: English/United States (en_US)

[realthunder]

There is a delay introduced by design to resolve key shortcut binding ambiguity. As long as there are shortcuts with common prefix, there will be delay to wait for more (or none) key press. You can use the Tools -> Customize...->Keyboard dialog to find out all commands with common prefix. Select All category, and sort the shortcut as shown below. If you are really bothered by the delay, try to set it to zero, although this may make it difficult to trigger some key combinations with common prefix.

[BloodyRain2k]

I did figure that much out by testing too, and the delay alone isn't the issue, just something I never paid attention to before. You're mistaken about the "common prefix" part though, because the delay stayed even when I only had a single bind for the entire "d" key in all of FreeCAD.

But the delay isn't the actual problem. It seems that for some actions the "waiting for key" does not get canceled when the timer expired. Like in the example of Keven's "r" key opening the radius dialog and still wait for a 2nd key and in my case the "d" key for the distance dialog, "s" for the symmetry constraint (which only has a "dialog" when it throws an error) and "t" for the tangent constraint (same as symmetry).

Another thing that has been confusing me, but never bothered in practice before, is that it seems that the delay doesn't actually work in the first place. I can press "f" in the sketcher, wait several seconds, press "f" again and it will still run the command associated with "f, f". Not sure if that's intentional for the cases where no associated command is found for the key sequence up to that point, or if this could be part of the problem.

Although now I'm wondering if the problem with the distance dialog goes away if I remove the delay.

Edit: surprisingly indeed, with 0 delay the first key pressed in the dialog is no longer discarded. But even a delay of 2 brings it back, which breaks my theory that the setting might be misinterpreted as seconds instead of milliseconds...

It seems like as long as the delay is above 0, it will wait indefinitely for a 2nd key until it can complete a sequence. Might be intentional, but feels unintuitive to me. Visual Studio has sequences too, but it stops waiting after a few seconds and resets. Which FreeCAD doesn't seem to do. Now I'll have to check if it's just Link that does this or FreeCAD in general.

Edit 2: ok, this is confusing and weird. Normal FreeCAD shares the same behavior when it comes to sequences as in that it never seems to stop waiting for the next key in a sequence until it finally gets one assembled.

BUT it does not have the issue with the dialogs for some reason. I can just press "d" for the distance constraint and it will not discard the first key. So that issue is limited to Link.

[kevenwyld]

@realthunder unfortunately my findings align with what @BloodyRain2k has reported. Setting Multi-key sequence delay to anything other than 0 causes the first input to be ignored (or rather, the first input to be interpreted as the second part of a chord) regardless of the value. That value appears to be treated as a boolean in this fork, but works as expected in upstream.

I've waited for 10 minutes and the first keystroke in any popup dialog is still ignored.

[kevenwyld]

I tested this on the latest release and it still seems to be an issue. No matter what the delay is set to as long as it's >0 the first keypress in the input dialog is ignored.

OS: Ubuntu Core 20 (sway/sway)
Word size of FreeCAD: 64-bit
Version: 2023.1102.0.38887 (Git) Snap 121
Build type: Release
Branch: tag: 20231102tip
Hash: 53783b6707f2fd2d561a02b5542f4fbe3c1eda4a
Python 3.8.10, Qt 5.15.7, Coin 4.0.1, Vtk 7.1.1, OCC 7.6.3
Locale: English/United States (en_US)
Installed mods: 
  * Assembly3 0.12.0
  * Curves 0.6.14
  * fasteners 0.4.70

[kevenwyld]

I think this may have been fixed in #909 maybe by one of the commits referenced there. I'm no longer experiencing this issue after the latest release.