Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XY Plot Dialogs repeatedly reopening after closing #239

Closed
tjpotts opened this issue Jan 5, 2020 · 1 comment
Closed

XY Plot Dialogs repeatedly reopening after closing #239

tjpotts opened this issue Jan 5, 2020 · 1 comment
Assignees
Labels

Comments

@tjpotts
Copy link

tjpotts commented Jan 5, 2020

I've run into a problem when trying to create and XY plot by right-click drag and dropping. After the "New XY Curve" dialog box pops up and I hit OK, the dialog immediately reappears. This effectively locks me out of doing anything else unless I manually kill the application. This also occurs with the warning dialogs when trying to add an XY curve to a timeseries plot and vice versa.

Given no one else has reported this, I assume there is something about my setup which is causing it. I'm using Ubuntu via WSL on a Win10 machine with Vcxsrv on the Win10 side as an X server. I'm also building on a system with ros2 (eloquent) using colcon/ament based on the work done here, The issue doesn't appear to be anything ROS-specific, but I'm not sure if there's significant differences in dependency versions.

After some investigation, it looks like what is happening is that the PlotWidget::dropEvent function is being repeatedly called. It seems that once the dialog box is closed, a new drop event is fired which calls PlotWidget::dropEvent again before the first call has a chance to complete.

I was able to fix this by setting _dragging.mode = DragInfo::NONE; before the dialog boxes are opened rather than after as seen at tjpotts/PlotJuggler@8db4fb1. I'm not familiar enough with the Qt Drag and Drop system generally, nor how it's used in PlotJuggler to know if this is the "right" fix or not, but it seems to be working for me.

@facontidavide facontidavide self-assigned this Jan 6, 2020
@facontidavide
Copy link
Owner

I am not able to reproduce your issue and I am not really sure how your change prevent it. But if it works for you, I will apply the change.

facontidavide added a commit that referenced this issue Jan 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants