Created attachment 280751 [details] [review]
Use handle_local_options ().

Created attachment 280752 [details] [review]
Add --mute and --unmute command-line options.

(In reply to comment #0)
> This will help to add command-line options to start in two-players /
> player-plays-first / player-plays-second mode, but that should go I think with
> another design of the Preferences dialog, so I will open after a dedicated bug.

What do you want to change? I guess it's not really clear that Dark always plays first?

Review of attachment 280752 [details] [review]:

So I'm not really sure what the benefit of adding these options is. I don't think it makes sense to add new command line options for everything that's already exposed in preferences, when it's already pretty easy to turn sound on or off.

I can kind of see the value in adding options so that board size can be used in a jumplist (I had completely forgotten we have those now), like in your Mines patchset, but it's not really clear to me what you're going for with mute/unmute?

>> This will help to add command-line options to start in two-players /
>> player-plays-first / player-plays-second mode, but that should go I think with
>> another design of the Preferences dialog, so I will open after a dedicated bug.
> 
> What do you want to change? I guess it's not really clear that Dark always
> plays first?

Having a “two-players / player plays first / player plays second” combo and a “computer’s IA” combo sometimes grayed permits exactly the same things as the actual “opponent” combo with a “choose color” combo sometimes grayed.

The main reason for changing is that having a “two-players / player plays first / player plays second” jumplist and a preferences’ “opponent”/“choose color” combos is totally insane, two logics for choosing the same thing… (for the user, and in the code); and of course, that in the jumplist, it’s far more interesting to have a way to choose if you want to play first/second, with your usual IA opponent, than to have a way to choose the opponent’s IA to… your usual IA opponent.

Said another way: the opponent’s IA is really a preference, playing first/second is not, it’s a choice for the next game. Mixing the two looks like a bad idea, in my opinion.

Here are some other reasons:
* It’s not completely evident for everyone that changing color means playing first / second, but that might be corrected by changing the combo to a “player plays first/second” combo. (And hopefully there’s not a theme that doen’t respect the light/dark opposition.)
* When you are on a two-players mode, the second combo is grayed; but, you see it. And the “choose color” combo doesn’t mean anything at all in this case; you have to think it’s an option for when you’re playing solo. The “computer’s IA” combo doesn’t have this problem, it could even not be grayed, for example if you want to implement a “suggestion” function that works in two-players mode.

> So I'm not really sure what the benefit of adding these options is. I don't
> think it makes sense to add new command line options for everything that's
> already exposed in preferences, when it's already pretty easy to turn sound on
> or off.
> 
> I can kind of see the value in adding options so that board size can be used
> in a jumplist (I had completely forgotten we have those now), like in your
> Mines patchset, but it's not really clear to me what you're going for with
> mute/unmute?

There are people who use command-line for many things that could be done another way (using yum for installing graphical programs, instead of using gnome-software…). For this people, having all the important runtime options tweakable from command-line is usually a good idea. I mean, I don’t think that changing theme is a “important runtime option”, it’s really a thing you change (or not) once and you forget it’s doable; but turning sound off (not “on/off”, “off”) is one of these “important runtime options”, there are some case where you know you don’t want unnecessary sounds. (Yeah, it’s doable with `gsettings set org.gnome.iagno sound false & iagno &`, but that needs a good knowing of the game internals.)

The patch is only for these people, who had run `iagno --help` or `man iagno` one time. Yes, the “unmute” option is quite geeky, it’s just a symmetry.

OK, mute/unmute is pretty harmless anyway.

I think you're right that the current setup of the preferences dialog would not translate well into jumplists, but I'm not really sold on changing the preferences dialog. That's probably fine: a jumplist with those three modes would still work fine even if the preferences dialog is not changed. What I would do is name the actions along the lines of "Play First (Dark)" and "Play Second (Light)" -- for the preferences dialog, we could change the labels to "Dark (Plays First)" and "Light (Plays Second)".

Attachment 280750 [details] pushed as 577adbe - Remove white spaces.
Attachment 280752 [details] pushed as 7280885 - Add --mute and --unmute command-line options.

> I'm not really sold on changing the preferences dialog.
Why??

> That's probably fine: a jumplist with those three modes would
> still work fine even if the preferences dialog is not changed.
That’s quite false, without having some weird code and to deal with bad assumptions. If you have a jumplist that permits to launch a solo game, you *have to* know what’s the prefered IA of the player. Even if in the games Preferences he said he usually prefers a two-players game.

Having this jumplist without changing the preference dialog means that you have the two-players/easy/normal/hard combo that changes both a prefered-IA setting and a how-many-players setting… and it only *assumes* that the prefered IA is the previous easy/normal/hard setting, and that’s quite a bad assumption (what if the player used the keyboard to go from hard to two-players? easy would be his default IA…).

OK, now you've convinced me!