Bug 7868 – De-select a piece when clicking a second time

Bug 7868 - De-select a piece when clicking a second time


Summary:	De-select a piece when clicking a second time

Status:	CLOSED WORKSFORME

Product:	Miniature
Component:	UI
Version:	0.1.x
Platform:	All Maemo

Importance:	Low enhancement with 1 vote (vote)
Target Milestone:	---
Assigned To:	Uwe Kaminski
QA Contact:	general

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree

Reported:	2010-01-13 00:01 UTC by Quim Gil
Modified:	2011-10-12 01:14 UTC (History)
CC List:	2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description Quim Gil (reporter) 2010-01-13 00:01:49 UTC

SOFTWARE VERSION:
0.1.6-1

EXACT STEPS LEADING TO PROBLEM: 
1. Select a piece by accident. Cell turns green.
2. Click on it again.

EXPECTED OUTCOME:
The piece is de-selected.

ACTUAL OUTCOME:
Green stays.

REPRODUCIBILITY:
always

OTHER COMMENTS:
After looking Iván in our real game, he automatically clicked the piece again
every time he was not happy about the selection. Even after knowing that it was
just enough to select another piece. It was like a natural action for him.

"I guess it's because in Mahong works that way", he said. Anyway, I wouldn't be
surprised if other users had the same expectations. And I guess it's easy to
implement without affecting the current ability of just selecting another
piece.

Comment 1 Quim Gil (reporter) 2010-01-13 00:10:15 UTC

*** Bug 7869 has been marked as a duplicate of this bug. ***

Comment 2 Quim Gil (reporter) 2010-01-13 00:10:45 UTC

*** Bug 7870 has been marked as a duplicate of this bug. ***

Comment 3 Quim Gil (reporter) 2010-01-13 00:11:11 UTC

*** Bug 7871 has been marked as a duplicate of this bug. ***

Comment 4 Quim Gil (reporter) 2010-01-13 00:11:31 UTC

*** Bug 7872 has been marked as a duplicate of this bug. ***

Comment 5 Quim Gil (reporter) 2010-01-13 00:11:55 UTC

*** Bug 7873 has been marked as a duplicate of this bug. ***

Comment 6 Quim Gil (reporter) 2010-01-13 00:12:21 UTC

*** Bug 7874 has been marked as a duplicate of this bug. ***

Comment 7 Quim Gil (reporter) 2010-01-13 00:13:04 UTC

Sorry, duplicates created as a side effect of a bugzilla bug.

Comment 8 Michael Hasselmann 2010-01-13 04:14:27 UTC

Well, only that I dont get a mousePressEvent() for the MGraphicsBoardItem when
the same contained QGraphicsItem was already clicked. QGraphicsScene's event
propagation is seriously borken.

Comment 9 Michael Hasselmann 2010-01-13 04:46:21 UTC

Fixed in master (commit 7207bd3c). Remind me that I need to isolate the borken
Qt behaviour in a consumable testcase ...

Please check with next release.

Comment 10 Uwe Kaminski 2011-09-04 16:34:24 UTC

The behaviour in the initial report of this bug is the same in 0.3 and the
master branch.

EXACT STEPS LEADING TO PROBLEM: 
1. Select a piece by accident. Cell turns light blue.
2. Click on it again.

EXPECTED OUTCOME:
The piece is de-selected.

ACTUAL OUTCOME:
light blue stays.

We should decide if a de-selection should be possible from a usability point of
view. I vote for "should be possible" and would try to implement this.

Of you agree leave this open. If not write a comment why. :)

Comment 11 Michael Hasselmann 2011-09-06 01:14:08 UTC

(In reply to comment #10)
> The behaviour in the initial report of this bug is the same in 0.3 and the
> master branch.
> 
> EXACT STEPS LEADING TO PROBLEM: 
> 1. Select a piece by accident. Cell turns light blue.
> 2. Click on it again.
> 
> EXPECTED OUTCOME:
> The piece is de-selected.
> 
> ACTUAL OUTCOME:
> light blue stays.
> 
> We should decide if a de-selection should be possible from a usability point of
> view. I vote for "should be possible" and would try to implement this.
> 
> Of you agree leave this open. If not write a comment why. :)

Why do we need a deselect? Seems inefficient to me. You can select other pieces
than the original one (if of same color) just fine, even without deselect.

Comment 12 Michael Hasselmann 2011-09-06 01:16:53 UTC

(In reply to comment #11)
> (In reply to comment #10)
> > The behaviour in the initial report of this bug is the same in 0.3 and the
> > master branch.
> > 
> > EXACT STEPS LEADING TO PROBLEM: 
> > 1. Select a piece by accident. Cell turns light blue.
> > 2. Click on it again.
> > 
> > EXPECTED OUTCOME:
> > The piece is de-selected.
> > 
> > ACTUAL OUTCOME:
> > light blue stays.
> > 
> > We should decide if a de-selection should be possible from a usability point of
> > view. I vote for "should be possible" and would try to implement this.
> > 
> > Of you agree leave this open. If not write a comment why. :)
> 
> Why do we need a deselect? Seems inefficient to me. You can select other pieces
> than the original one (if of same color) just fine, even without deselect.

Also, deselect would need to implement in C++ backend ;-) UI has no idea about
pieces or what selected means: It gets all that from the chessboard model. The
only thing the UI does is to say "User touched (and selected) on what I think
is a square, here is the index of that square", then the backend takes over,
updates the chessboard model and notifies the UI about the changes in the
model. Sounds complex but it is trivial to write new UI's for that whilst
reusing the very same backend.

Comment 13 Quim Gil (reporter) 2011-09-06 01:21:13 UTC

(In reply to comment #11)
> Why do we need a deselect? Seems inefficient to me. You can select other pieces
> than the original one (if of same color) just fine, even without deselect.

I agree. In that situation the user needs to select a piece, so it makes sense
that one you get the blue it doesn't go out.

Also, the de-select with double tap might accidentally lead to false
de-selections.

I was the original submitter of this bug and now I see that the current
behavior is right.  :)  Resolving accordingly.

Comment 14 Uwe Kaminski 2011-09-06 09:24:23 UTC

(In reply to comment #12)
> Also, deselect would need to implement in C++ backend ;-) UI has no idea about
> pieces or what selected means: It gets all that from the chessboard model. The
> only thing the UI does is to say "User touched (and selected) on what I think
> is a square, here is the index of that square", then the backend takes over,
> updates the chessboard model and notifies the UI about the changes in the
> model. Sounds complex but it is trivial to write new UI's for that whilst
> reusing the very same backend.

Oh yes... I spent the whole evening yesterday to understand what is going on in
ChessBoard.cc but Bug 12373 prevents me from debugging. :D However I now know a
little bit better how the chess board model works.

Regarding this bug this convinces me:

(In reply to comment #13)
> Also, the de-select with double tap might accidentally lead to false
> de-selections.