It is very common to see people asking for advice on how to move a command-line-only application that they have already written to a graphical interface, for reasons discussed at the end of the previous chapter, such as ease of use and familiarity.
How easy this is to do is largely dependent on the choice of data structure used within the application. If the application's main logic is too intertwined with data collection and storage, then porting can become a nightmare. If you find yourself with a command-line application that you wish to convert, take the time to consider how separable these two pieces are.
If you are not using classes, could you split certain pieces out into small, reusable classes which could then be shared into a new file? Since classes are almost a necessity for building graphical applications, it's a good idea to ensure that your current application takes advantage of them before attempting to make it graphical.
If your application takes a lot of text input from the user via the input (or raw_input) function, think about what type of information you need from it. Since the input function will always return a string, consider which information you may be casting to an integer (via the int function), what is being treated as some sort of list (a big clue is if you are asking the user to comma-separate words), and what things require the user to enter a choice of predetermined responses.
Whilst numerical entries can be made using a text field (known as the Entry widget to Tkinter), there is also a numerical field known as the Spinbox widget which will ensure that the value entered is a number between a certain range.
Lists of multiple values can be collected in multiple ways depending on whether or not the options are set by the developer or the user. If the options are limited, then a Listbox widget will allow the user to select multiple options from a preset list, or the good old Checkbox widget could be used as well. If the user decides exactly what will be entered, then the GUI programmer can use dynamically created widgets to collect as many options as can fit on the screen.
When providing a single choice from a predetermined set of responses, Tkinter provides regular buttons, radio buttons, a drop-down menu, and a single-choice Listbox, depending on the designer's preference.
If your command-line application collects many different forms of input from the user, it is recommended that you take the time to decide what type of information each input statement is after and map out what widgets would do the job of collecting this information in the right way. Familiarize yourself with each widget that you intend to use and make sure it can do what you would need it to, for example, in terms of validation of data.
As well as this, make sure that your choice of widgets can be laid out in a way that will look appealing. If you have too many individual data-entry widgets, the user interface may look cluttered, so see what can be grouped in a logical way and perhaps look into using a Menu widget to hide anything non-essential away from your main window.
Applying this advice to our blackjack game, we know that we have chosen a reusable data structure in the form of our Hand, Deck, and Card classes. Whilst these depend on each other, and the Hand class knows a bit about the rules of the game of blackjack via its get_value method, the classes are not dependent on any form of data collection or display in order to function properly.
There are two main points at which user input is collected – when deciding whether to hit or stick, and when choosing whether to play another game or quit. Since both of these points in the game involve a specific choice of one of two predetermined answers, we can use two Button widgets to collect an answer from the user.
In terms of layout, we will need only three interactive widgets—a Canvas widget to display our game's graphics, and two button widgets to collect the hit or stick choices from our user. These buttons can change, based on which stage of the game we are at, since we don't need to display one set while the other set is active. This allows us to help keep the interface as uncluttered as possible and avoids confusing the users.
We have had a look at using a Button widget in Chapter 1, Meet Tkinter, but have not yet looked at the extremely powerful Canvas widget. Before we begin writing our code, let's look at an overview of this crucial part of our game.