So it is more structured.

Line

Granted that deserialization is done with SEPARATOR, serialization can be done with SEPARATOR as well.

Rationale: avoid the use of the heavy and design-flawed java.util.Stack class.

Adapt the style file to the latest version of Checkstyle and add new rules as appropriate.

Allow user to start a new game once the deck is empty.

Add module-info.java class and update the build path.

The GameModel is currently a Singleton. This hinders the use of dependency injection with this instance, and makes testing more complex. Instead, we can still have just one instance of this object, without it being globally available by only initializing it in the application's start method.

For consistency, shouldn't all of these be marked as final?

https://github.com/prmr/Solitaire/blob/v0.4/src/ca/mcgill/cs/stg/solitaire/model/GameModel.java#L97

https://github.com/prmr/Solitaire/blob/v0.4/src/ca/mcgill/cs/stg/solitaire/model/GameModel.java#L416

Version string and deck randomization.

This will facilitate implementing the command design pattern, undo, and automove.

Set up the project classpath, tools, configuration, with a first cut at the code.

This class relates to the GUI and belongs in the GUI package. Some cleanup is also possible.

<module name="JavadocMethod">
  <property name="scope" value="protected"/>
</module>

under the TreeWalker module, due to a breaking change in checkstyle 8.42 (8.44 is latest) this should now be

<module name="JavadocMethod">
  <property name="accessModifiers" value="public, protected"/>
</module>

• Link to JRE 8
• Remove the JavaFX path, since it's now include in the Java 8 JRE

Rationale: lighten up class Card.

Update the build configuration and, as applicable, leverage new language features.

Add JavaFX-based GUI

Create a singleton class in charge of tracking and managing game state.

@prmr
Why are the JUnit libraries required in the application's module-info.java file? They should not be there in the main application's module.

I've got some changes to the .classpath file to remove them and still make Eclipse happy. Are you interested? Or should they be left as an exercise for your students?

Similar to #13

https://github.com/prmr/Solitaire/blob/v0.4/src/ca/mcgill/cs/stg/solitaire/gui/CardStack.java#L114

Clipboard can be at least limited to one creation per handler in case of concurrency.

Pressing backspace should undo the last move.

For consistency:

Missing @Override

https://github.com/prmr/Solitaire/blob/v0.4/src/ca/mcgill/cs/stg/solitaire/gui/CardStack.java#L126

https://github.com/prmr/Solitaire/blob/v0.4/src/ca/mcgill/cs/stg/solitaire/gui/CardStack.java#L145

https://github.com/prmr/Solitaire/blob/v0.4/src/ca/mcgill/cs/stg/solitaire/gui/CardStack.java#L161

https://github.com/prmr/Solitaire/blob/v0.4/src/ca/mcgill/cs/stg/solitaire/gui/CardStack.java#L173

It should be possible for the user to position the suit stacks anyways in the four possible slots by moving an ace on an empty slot.

This line: ClipboardContent content = new ClipboardContent();

I think it would be okay to have this as a private final global variable and reuse it with each motion event

putString calls

public final boolean putString(String s) {
	if (s == null) {
		remove(DataFormat.PLAIN_TEXT);
	} else {
		put(DataFormat.PLAIN_TEXT, s);
	}
	return true;
}

so the old content will be removed anyways

So that it can be run directly using JavaFX

Use classic Solitaire-Patience terminology of FoundationPiles and Tableaux instead of "StackManager". Move index enums to top level types.

Rationale: Clarify the design to align it with domain concepts.

Additional design improvements.

Whenever the state of the game reaches a point where the discard pile is empty, a new card should automatically be drawn from the deck. This will save one automatic move from the human player.