RIGHT CLICK AND DRAG
Description
Why does the latest nightly version often start right-click events as long as you right-click and drag? The earlier version did not have this problem
Steps to reproduce
1.Right_Click and Drag
2.If the drag distance is short, the right-click menu will be triggered
KiCad Version
Application: KiCad (64-bit)
Version: (5.99.0-12701-gd39127bbcb), release build
Libraries:
wxWidgets 3.1.5
libcurl/7.78.0-DEV Schannel zlib/1.2.11
Platform: Windows 10 (build 17763), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
Date: Oct 5 2021 12:01:00
wxWidgets: 3.1.5 (wchar_t,wx containers)
Boost: 1.76.0
OCC: 7.5.0
Curl: 7.78.0-DEV
ngspice: 35
Compiler: Visual C++ 1929 without C++ ABI
Build settings:
KICAD_USE_OCC=ON
KICAD_SPICE=ON
The version in which this occurs is：(5.99.0-12701-gd39127bbcb), release build
However, it did not appear in earlier versions like Version: (5.99.0-12071-g0463fc4c2b), release buildActivity
🛑 This issue is missing the required full version information.Please follow the required issue template when creating a new issue. You may re-open this issue after adding the required information.
If you have encountered a build error that prevents you from compiling KiCad please add the text
build-errorto the original issue report and re-open.added priorityundecided statusincomplete-report labels
added statusnew label and removed statusincomplete-report label
added prioritymedium ui labels and removed priorityundecided label
changed milestone to %6.0.0-rc1
Drag handling got changed recently, which I suspect is the root cause here. cc @mikebwilliams
I agree. I'm not sure it was the system drag changes specifically, or the other commit d90dc77e, or both:
Part of the problem is that the mouse warping actually makes it so you can "drag" indefinitely and still activate the menu, so that will need to be fixed. The total solution I have some questions about though:
Let's say I fix the mouse warping so normal sized canvas drags (e.g. greater than 8px or whatever the user configures) never shows the menu. What about smaller drags, do we want to drag the canvas 1px if that's what the user does or not start dragging until it hits the system drag threshold?
If we do allow 1px canvas drags, do we want to show the right click menu when the click is released? If we disable the menu for any amount of dragging, it can feel like the click is dropped, as often a user will not intend to drag the canvas just 1px, and accidentally moved the mouse slightly when clicking.
@mikebwilliams Can we assign this on to you?
-
Yes, I'll take a look (I've assigned it to myself).
It turns out this issue is also present before my changes (I have a 24 Sept. nightly installed on a Windows VM), it's just less obvious since it doesn't happen if the drag time exceeds the timer dragging previously had. I'll see if I can get this sorted out.
So, here's another question though: this right-click canvas drag seems to be a new feature. It does kind of conflict with all other UI use of right-click menus though. On both Windows and KDE right-down starts the right click menu so you can do a right-up on the selected item.
That is only one way to use a context menu, but is a reason why the right-click-drag behavior can be disabled if desired. Using right-click-drag for panning (instead of "drag and drop" context menus) is a real workflow improvement in some situations (especially on some laptop input devices). It also helps users who are using KiCad alongside or coming from other applications where right-click-pan is the norm. Context menus can still be interacted with on all platforms using right-click-and-release.
Edited by Jon Evans-
Alright, so here's my understanding (and potential fix): It turns out wx_view_controls.cpp doesn't use the TOOL_DISPATCHER logic at all, it handles adjusting the view directly based on raw mouse events. All of those mouse events do still get passed to the selection tool (in the default case) which does use the TOOL_DISPATCHER mouse drag logic.
MR: !954 (merged)
This gives us a good news / bad news situation:
Good:
- My merge request makes it Works-For-Me (TM) on my machine. It seems the mouse warping made the after-the-fact conversion of world coordinates back to screen coordinates always be less than a the drag distance, so to the TOOL_DISPATCHER it was always a click no matter how far you moved the canvas, unless you released the button before the canvas could catch up. Drags now look at screen coordinates to determine when it's a drag (but the world coordinates are still sent in the drag events).
Neutral:
- I didn't touch any timer stuff. Going this path would not have fixed the bug: short (<300ms) right-drags exhibited this issue before I removed the timer, re-adding a less-than-double-click timer (~500ms) would have actually made it worse than the 300ms timer since the user could drag up to that amount of time.
Bad:
- Can't easily change right drag threshold for the canvas since it doesn't plug into the TOOL_DISPATCHER mouse logic that figures out dragging with respect to system settings. So, if you do a 1px right-drag and it will still activate the menu, which is what we wanted. But, it still drags the canvas. It will do so up to the system drag threshold.
assigned to @mikebwilliams
mentioned in commit mikebwilliams/kicad@42248a82
mentioned in merge request !954 (merged)
mentioned in commit mikebwilliams/kicad@27765cd5
closed with merge request !954 (merged)
Hi @mikebwilliams , @sethhillbrand ,
Recently I tried upgrading kicad to 6.x which I built from source as there are no binaries for my platform (ppc64 linux). I've built kicad from source many times before. I was surprised to find that while pcbnew was fine, eeschema would segfault on startup (momentarily after displaying a blank schematic). A few different 6.x versions showed the same behavior. I think it is some kind of memory bug, I suspect a double free (delete).
Eventually, I did a git bisect (starting from HEAD, 548936bb) which reported your commit 27765cd5 (part of this issue) as the first bad commit.
I can't tell from looking at 27765cd5 what is wrong, but simply reverting 27765cd5 allows eeschema to work again.
Do you know what might be going wrong? Are you able to revert 27765cd5 or give me any instructions so that I can provide more information to help debug this?
-
@yasukumi89 please run a debug build of KiCad using gdb. When you hit the crash, type
backtraceand post the results here @sethhillbrand Sorry for the delay.
Unfortunately a debug build of current HEAD (cc165129) doesn't crash (it appears to work fine), but a release build does.
The debug build additionally produces a message:
Debug: ScreenToClient cannot work when toplevel window is not shownThe backtrace from the release build is:
(gdb) backtrace #0 __GI___libc_free (mem=0x4140287cb0118b90) at malloc.c:3281 #1 0x00003ffff48005d8 in operator delete(void*) () at /lib/powerpc64le-linux-gnu/libstdc++.so.6 #2 0x00003fffefdc0d8c in EE_SELECTION_TOOL::Main(TOOL_EVENT const&) () at /home/kumi/kicad/bin/_eeschema.kiface #3 0x00003fffefdca87c in std::_Function_handler<int (TOOL_EVENT const&), std::_Bind<int (EE_SELECTION_TOOL::*(EE_SELECTION_TOOL*, std::_Placeholder<1>))(TOOL_EVENT const&)> >::_M_invoke(std::_Any_data const&, TOOL_EVENT const&) () at /home/kumi/kicad/bin/_eeschema.kiface #4 0x00003ffff009ceec in COROUTINE<int, TOOL_EVENT const&>::callerStub(long) () at /home/kumi/kicad/bin/_eeschema.kiface #5 0x00003ffff0164dc4 in make_fcontext () at /home/kumi/kicad/bin/_eeschema.kiface (gdb)-
@yasukumi89 Unfortunately, this issue does not occur on x86 builds.
You might try building with ASAN enabled
cmake -DCMAKE_BUILD_TYPE=Debug -DKICAD_ASANand see if that turns up any issues when running. If it is a double-free issue this would expose it.We are unable to troubleshoot issues with PowerPC builds and will depend on you to suggest patches to fix the behavior.
