After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 485246 - Help user learn rules (especially en passant)
Help user learn rules (especially en passant)
Status: RESOLVED FIXED
Product: gnome-chess
Classification: Applications
Component: General
git master
Other All
: Normal enhancement
: ---
Assigned To: Sahil Sareen
gnome-chess-maint
: 789241 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-10-10 01:03 UTC by Robert Ancell
Modified: 2018-04-24 18:34 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Make it really obvious when an en passant capture is performed (1.30 KB, patch)
2018-04-24 16:52 UTC, Michael Catanzaro
committed Details | Review
Show better move description for en passant captures (4.53 KB, patch)
2018-04-24 16:52 UTC, Michael Catanzaro
committed Details | Review

Description Robert Ancell 2007-10-10 01:03:41 UTC
There is a reasonable number of "illegal move" bug reports from various sources. These reports generally have the AI doing an en passant against them.

When an en passant occurs the information bar should tell the user with a link to the documentation. There should be a checkbox saying "don't tell me again".

Any other rules that are worth mentioning?
Comment 1 Mårten Woxberg 2007-11-10 11:03:53 UTC
Yes, please do this.

I was just about to report this "bug" since I didn't know about the rule.
Comment 2 Robert Ancell 2008-08-14 14:58:07 UTC
The en Passant "bug" (bug #427114) now has four duplicates...
Comment 3 Sahil Sareen 2016-05-01 05:17:12 UTC
*** Bug 765868 has been marked as a duplicate of this bug. ***
Comment 4 Sahil Sareen 2016-05-07 11:04:47 UTC
How about displaying this information as an InfoBar with a "X" button?
We need to decide if this should be shown just once "per user" or "per application run"

I'd +1 per application run as the player might forget the rule after a few months
Comment 5 Michael Catanzaro 2016-05-07 14:23:16 UTC
I kinda think it's the sort of thing a player only needs to learn once, so I'd store it in a gsetting "has-learned-en-passant" or something like that. The player might forget the exact conditions that cause en passant, but I don't see anyone reporting it as a bug after having heard of it in the past.
Comment 6 Sahil Sareen 2016-05-08 06:29:05 UTC
Okay, we can try this out for a while and if people continue to report it, maybe we could enhance with "Don't show again" option.

Do you agree on using an InfoBar?

Possible options I can think of are:

1. InfoBar at the beginning of the game giving such hints with a next button for next hint. We have just one now so Next can be added as and when we need more.

2. InfoBar "on move" giving hint about the move

3. Using dialogs instead of InfoBar(Nah :P)
Comment 7 Michael Catanzaro 2016-05-08 13:32:49 UTC
(In reply to Sahil Sareen from comment #6)
> Okay, we can try this out for a while and if people continue to report it,
> maybe we could enhance with "Don't show again" option.
> 
> Do you agree on using an InfoBar?

Yeah. It's kind of undesirable as it causes the chess board to shrink weirdly, which is why I removed our previous use of GtkInfoBar (you can check old versions of the code to see what we used to do). But if we only use it rarely, I think it's OK.

> Possible options I can think of are:
> 
> 1. InfoBar at the beginning of the game giving such hints with a next button
> for next hint. We have just one now so Next can be added as and when we need
> more.

Let's just use it the first time an en passant occurs. We don't want to show it every game.

> 2. InfoBar "on move" giving hint about the move
> 
> 3. Using dialogs instead of InfoBar(Nah :P)

Actually... using a GtkDialog for this is not such a bad idea. It avoids the problem of having the info bar shrink the board. Pop-up dialogs are usually bad, but when used sparingly, I think it's fine. Then we can add a "Don't show this again" checkbox to the dialog. I actually think this is a better approach now.
Comment 8 Sahil Sareen 2016-05-08 14:48:47 UTC
(In reply to Michael Catanzaro from comment #7)
> Actually... using a GtkDialog for this is not such a bad idea. It avoids the
> problem of having the info bar shrink the board. Pop-up dialogs are usually
> bad, but when used sparingly, I think it's fine. Then we can add a "Don't
> show this again" checkbox to the dialog. I actually think this is a better
> approach now.

Alright!

I was a bit confused on this, but I see other chess distributions do this and kind of think it blocks the UI, but it also forces the player to read some interesting information.

Hopefully players do read it as we aren't popping out dialogs every now and then.

---

Now about the dialog string, what do you think about this:

----------------------------------------------
   Special Move - En passant             | X
----------------------------------------------
[Black|White] just did an en-passant! Read more [here].

[] Don't show this again

                                      [Close]
----------------------------------------------

[here] is a link to https://en.wikipedia.org/wiki/En_passant
[Black|White] would be the current player color, something like "White just did..."
Comment 9 Michael Catanzaro 2016-05-08 17:08:45 UTC
We don't do buttons on the bottom right anymore. The close button in the header bar suffices. Like this:

----------------------------------------------------
                   En passant                   | X
----------------------------------------------------
[Black|White|You] just moved en passant! [Read more](https://en.wikipedia.org/wiki/En_passant).

[] Don't show this again
----------------------------------------------------

If we were to put a close button on the bottom, it would stretch across the length of the dialog and we would not use any header bar. That's what we do for normal message dialogs, but this one can't be a simple GtkMessageDialog because it requires a checkbox.
Comment 10 Michael Catanzaro 2017-10-20 15:52:02 UTC
*** Bug 787970 has been marked as a duplicate of this bug. ***
Comment 11 Michael Catanzaro 2017-10-20 15:52:13 UTC
*** Bug 789235 has been marked as a duplicate of this bug. ***
Comment 12 Michael Catanzaro 2017-10-20 16:01:00 UTC
*** Bug 789241 has been marked as a duplicate of this bug. ***
Comment 13 Mario Wenzel 2017-11-05 20:16:56 UTC
*** Bug 789942 has been marked as a duplicate of this bug. ***
Comment 14 Sébastien Wilmet 2017-11-06 19:10:07 UTC
In addition to the infobar, another improvement would be to mention "en passant" in the historic of moves in the combobox at the bottom.

Currently it is for example:
12b. Black pawn moves from f7 to f5
13a. White pawn at e5 takes the black pawn at f6

This could be improved to:
12b. Black pawn moves from f7 to f5
13a. White pawn at e5 takes the black pawn at f6 (en passant move)

Or something like that.
Comment 15 Michael Catanzaro 2018-04-24 16:49:48 UTC
(In reply to Sébastien Wilmet from comment #14)
> In addition to the infobar, another improvement would be to mention "en
> passant" in the historic of moves in the combobox at the bottom.

Yes. Let's do this, and also change the window title. That's quick and easy. I'm not planning to spend more time on this.
Comment 16 Michael Catanzaro 2018-04-24 16:51:57 UTC
The following fixes have been pushed:
384ebe0 Make it really obvious when an en passant capture is performed
9b41b9b Show better move description for en passant captures
Comment 17 Michael Catanzaro 2018-04-24 16:52:01 UTC
Created attachment 371329 [details] [review]
Make it really obvious when an en passant capture is performed

Let's change the window title. Should hopefully cut down on bug reports.
Comment 18 Michael Catanzaro 2018-04-24 16:52:05 UTC
Created attachment 371330 [details] [review]
Show better move description for en passant captures

The current description is wrong since it says the captured piece was at
the current location of the capturing piece, but that's not true for en
passant captures.

Also, this might possibly help users realize that en passant is not a bug.
Comment 19 Sébastien Wilmet 2018-04-24 18:34:56 UTC
Thanks!