Probably should be done after the game is ported to Vala (bug 664943).

Reassessing whether we really want new game screens for all of our games....

For Swell Foop, we want to remove the Board size and Number of colors preferences from the preferences dialog. However, Swell Foop is very quick to play, and a new game screen would be annoying even if it required only one click to get through.  So the app menu would probably be a better place for these two options. Changing those settings would cause the game to immediately restart, after presenting a warning dialog (if the game has already started).

If we do use a new game screen, it would need to be done the same way we handles Mines's: by default, start a new game skipping the screen, and add a Change Settings or Change Difficulty button (maybe with a different name) to take you to the new game screen. This would require a new window layout for Swell Foop, since we don't even have enough space to use a text label in the new game button, let alone add another one.

(In reply to comment #2)
> ... Swell Foop is very quick to
> play, and a new game screen would be annoying even if it required only one
> click to get through.

I'm inclined to agree.

> So the app menu would probably be a better place for
> these two options. Changing those settings would cause the game to immediately
> restart, after presenting a warning dialog (if the game has already started).

Here's an idea for how it might work - https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/games/swell-foop/swell-foop.png

Thanks!

I will have a try at implementing Allan's design.

Created attachment 286816 [details] [review]
Replace New Game button and add a Play Again button to the Game Over screen

My work so far.

Review of attachment 286816 [details] [review]:

Looks like good progress. Let me know if you have any specific questions!

::: src/game-view.vala
@@ +308,3 @@
+
+        var play_again_button = new Gtk.Button ();
+        play_again_button.label = _("Play Again");

I think you can use Gtk.Button.with_label() here instead. But it'd be awesome if mnemonics work, so give Gtk.Button.with_mnemonic() a try too. (Place an underscore in front of the P in the label, then hold Alt and see if you can activate it by pressing P.)

@@ +310,3 @@
+        play_again_button.label = _("Play Again");
+        play_again_button.action_name = "app.new-game";
+        play_again_button.tooltip_text = _("Start a new game");

I'm not sure the tooltip is a good idea.

@@ +316,3 @@
+        style.add_class ("suggested-action");
+
+        var button_actor = new GtkClutter.Actor.with_contents (play_again_button);

OK, looks like this was easier than I was expecting it to be. Great.

::: src/swell-foop.vala
@@ +107,3 @@
+
+            var settings_menu = new Gtk.Menu ();
+            settings_button.set_popup (settings_menu);

This is what's disabling the popover. You have to use set_popover() instead.

(In reply to comment #7)
> You have to use set_popover() instead.

Just kidding. That would be difficult; don't try that. Try set_menu_model(); it should just work.

Created attachment 287065 [details] [review]
Replace New Game button and add a Play Again button to the Game Over screen

Should be much better now.

Review of attachment 287065 [details] [review]:

OK, it works well and I don't see any issues with the code. But the button feels too small to me; can you make it a bit bigger, like in Allan's mockup?

Created attachment 287082 [details] [review]
Button is now same size as in Allan's mockup

Review of attachment 287082 [details] [review]:

I guess it needs to be larger than in the mockup, since it's still quite small.

Anyway, the next step is to replace the preferences dialog with this new game screen (which Allan has called "preferences" -- that's fine).  To match his mockup you'll need to remove the zealous animation preference, which was not a particularly useful preference anyway, and also the preference that allows you to use colors without shapes.  (From his mockup, he instead removes the ability to have shapes with the colors. I'm not sure if that's the desired final result or just a shortcut for the purposes of the mockup, but regardless, our colors aren't vibrant enough to use unmodified without shapes, so let's keep the shapes for the time being.)

What I see from Allan's mockup is that the middle top screen is the New Game screen (new game as in "the first time you open the game screen"), the preferences screen(the preferences dialog more exactly - middle left) and the Game Over screen displayed when finishing a game. Is this correct? Or that preferences dialog should be the screen you see when you open the game?

There's a confusing disconnect between the terminology shown in the mockup (which is what we want to implement) and the terminology I use:

* First run dialog -- explains the rules the first time the game is launched
* New game screen -- screen for changing options that can't be changed while a game is in progress and then starting a new game, labeled Preferences in the mockup; that's the subject of this bug
* Preferences dialog -- the thing we want to remove and replace with the new game screen titled Preferences in the mockup

@Iulian Radu: Do you plan to continue working on this?

(In reply to Iulian Radu from comment #14)
Ping @Iulian Radu, do you plan to work on this?

Hello,

I'm sorry for such a late answer. I won't be able to work on it anytime soon.

For now I did:
* update the appmenu as in the mockup
* moved play again button from headerbar into game area
* updated high scores dialog title
What's left to do
* update the preferences dialog
  * remove the zealous animation configuration option from the preferences, leaving default to true, dconf option should still be left there
  * remove the option to select theme, stay with colors and shapes by default
  * change the board size selector to a graphic one
  * change the colors selector to a graphic one
  * add Restart and Cancel to the preferences dialog headerbar
* add "score to reach leaderboard" to the game over screen

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/swell-foop/issues/3.