Atm, the game logic and the ui is coupled rather tightly. For example, now if you press a key to input a number, some signals, like 'changed', will be passed around, triggering some callbacks and it becomes hard to get clear where the number is shown on the ui and where it is written to the underlying grid.

Another example is the 'auto fill' (for whole board), where the numbers are filled in sudoku.py (i.e. through game logic), then they are passed back to gsudoku.py (i.e. ui), which will set the numbers again (both to ui and to underlying logic). Thus some bugs will come, https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/309968.

=====

Encapsulating the logic in a blackbox can let the code decoupled (thus fewer bugs), make it easier to locate bugs, and also easier to add new features. The problem is how should the blackbox be designed. Here is my initial thinking, any comments are more than welcomed.

1. The blackbox contains all stuff about game state. And the ui know nothing about how the game is going. That is to say, ui gets user input, sends the request (say filling a number) to the blackbox, which updates its state and instructs the ui to update the display. In the above example, the ui will show the newly filled number; and if the blackbox decides it's a conflict, the ui will be asked (say raise ConflictError) to add a red color to the number. If the blackbox decides the puzzle is solved, the ui will be asked to launch the dancer.

2. As to auto-fill-current and auto-fill, the ui asks the blackbox to fill this/these fields, which will update the underlying grid and let the ui change the display. If the ui's request can't be fulfilled, the blackbox will say so to the ui and nothing will happen.

3. As to undo/redo, it can be handled by the ui or another object. And a simple list containing (x-coordinate,y-coordinate;value) tuples can act as history-list. When undo/redo, we simply calls blackbox.add_value(x,y,value) to change the logic and ui.