Fixed timeline mouse-click behavior and scrollbars #177
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When I launch rqt_bag, it shows up on my primary display. However, I cannot click most parts of the timeline to move the caret. There's no reaction at all. Usually, I can only click about 100 px from the left side of the bag view. Also, there is no vertical scrollbar even if it should be there.
I tried printing
mousePressEventinTimelineFrameand it is indeed not called on some parts of the bag view.Then I went down the rabbit hole trying to find out where does the event get lost. I'm pretty confident that the culprit is in wrong initialization of the internal index held by
BagTimeline(QGraphicsScene). When this index is wrong, the hit test inQGraphicsScenewill not succeed for theTimelineFrameitem and it will not receive the event. My guess is that the index is computed before the timeline object is resized.One way to reset the index is to resize the window. If I resize it (via the OS GUI buttons), the problem gets fixed and I can click anywhere (well, up to #175) and the scrollbar appears. However, this is not very convenient
Another way to reset the index is to trigger a resize event programatically. That's basically what #63 does. So I ported a similar fix into ROS 2.
First, I thought this might be an issue with my multi-monitor setup. However, now I figured it behaves the same just with the laptop on my lap, so no external displays... Anyways, if it helps, I have a multi-monitor setup where the primary screen is not the top-left-most one:
So,
DisplayPort-7is the top-left-most one, and it is rotated, so it is 1200x1920.DisplayPort-4is the primary display and its top left corner lies on coordinates1200x379of the global space.