Nux

Merge lp:~nick-dedekind/nux/lp1057995.mouse-drag-delta into lp:nux

Proposed by Nick Dedekind
Status: Merged
Approved by: Daniel van Vugt
Approved revision: 674
Merged at revision: 680
Proposed branch: lp:~nick-dedekind/nux/lp1057995.mouse-drag-delta
Merge into: lp:nux
Diff against target: 19 lines (+2/-0)
1 file modified
Nux/WindowCompositor.cpp (+2/-0)
To merge this branch: bzr merge lp:~nick-dedekind/nux/lp1057995.mouse-drag-delta
Reviewer Review Type Date Requested Status
Daniel d'Andrada (community) Needs Fixing
Daniel van Vugt Approve
Review via email: mp+127220@code.launchpad.net

Commit message

Fixed drag delta processing in mouse event cycle.
(LP: #1057995)

Description of the change

Fixed drag delta processing in mouse event cycle.

Added:
Mouse position in parent reset when mouse is clicked.

To post a comment you must log in.
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Verified, bug fixed.

review: Approve
Revision history for this message
Daniel d'Andrada (dandrader) wrote :

Why are we fixing bugs without providing unit tests? I bet it shouldn't be hard to come up with a test for this.

Revision history for this message
Daniel d'Andrada (dandrader) wrote :

About the lack of test:
* This is nux trunk, targeted only for 13.04. Therefore the "I'm in a hurry" argument doesn't hold.
* Input event handling is virtually always testable (unlike graphics rendering for instance).
* If we had such a test in place this refactoring regression wouldn't have come up. That's the perfect opportunity to improve the maintainability of the code.

Revision history for this message
Daniel d'Andrada (dandrader) wrote :

And it's always a good idea to ask the author or the last person that worked on the code you're changing (me! :) ) for a review, when viable. They usually have a good understanding of that code and therefore might come up with good suggestions and approaches.

In this case, for instance:

* mouse_position_on_owner_ is used only to come up with the delta for the mouse drag signal in line 358. There's no point in filling it up as you did on line 601 as there can't be an upcoming drag if the mouse is not pressed (and therefore there's no owner).

* mouse_position_on_owner_ should be updated and used only inside WindowCompositor::TrackMouseMovement() (check commments in MouseEventCycle). In the refactoring I tried to split responsibilities between methods to keeps things more manageable. Here you're starting to mix them again.

* This bug has show that line 310 is likely never called (the cause of the bug). A proper fix would have taken care of that. This is one just turned it into dead code, making the logic misleading.

Revision history for this message
Daniel d'Andrada (dandrader) :
review: Needs Fixing
Revision history for this message
Nick Dedekind (nick-dedekind) wrote :

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'Nux/WindowCompositor.cpp'
2--- Nux/WindowCompositor.cpp 2012-09-28 15:20:39 +0000
3+++ Nux/WindowCompositor.cpp 2012-10-01 10:16:12 +0000
4@@ -537,6 +537,7 @@
5
6 UpdateKeyNavFocusOnMouseDown();
7
8+ _mouse_position_on_owner = Point(hit_view_x, hit_view_y);
9 if (event.type == NUX_MOUSE_DOUBLECLICK
10 && mouse_over_area_->DoubleClickEnabled()
11 && !area_under_mouse_changed)
12@@ -597,6 +598,7 @@
13
14 if (mouse_owner_area_.IsValid() && mouse_over_area_ == mouse_owner_area_)
15 {
16+ _mouse_position_on_owner = Point(mouse_owner_x, mouse_owner_y);
17 mouse_owner_area_->EmitMouseClickSignal(mouse_owner_x, mouse_owner_y,
18 event.GetMouseState(),
19 event.GetKeyState());

Subscribers

People subscribed via source and target branches