Know Your Users

When designing a user interface, the most important thing to consider is your audience. Are they all experienced with the task at hand, or will some need more help than others? Can you model your user interface after one that they are already familiar with, or is this something completely new?

One of the biggest possible mistakes is to make rash generalizations about your users’ skill level. You may think that the way you lay out your application makes sense, but that is because you designed it. You should place yourself in the users’ position, understanding they will have no prior knowledge about how to use your application.

To avoid confusion, take time to study similar applications, taking note of what design decisions seem successful and which cause problems. For example, if you are creating an application to be used in the GNOME desktop environment, you should check out the GNOME Human Interface Guidelines ( http://developer.gnome.org ), which can help you lay out a design that is used for other compliant applications.

Another thing to consider when designing a user interface is accessibility. Users may have vision problems that could inhibit them from using an application. The Accessibility Toolkit provides many facilities for GTK+ applications to make them compatible with screen readers. GTK+ also relies heavily on themes, which is why you should avoid setting the font, when possible, or provide the user with a way to change it.

Your language is another consideration when designing the user interface. First, you should always use jargon that is familiar to the users. For example, you are free to use mathematical terms in an engineering application, but you should not do so in a web browser.

Many applications are translated into other languages when they become popular, which may cause problems if you use words or images that could be offensive in other cultures.

Keep the Design Simple

Once you know your audience, it becomes a lot simpler to design an effective user interface, but you can still run into problems if the interface is too difficult or cluttered. Always try to reduce the number of widgets on the screen to a reasonable number.

For example, if you need to provide many choices to the user where only one can be selected, you might be tempted to use a lot of radio buttons. However, a better solution may be to use a Gtk.ComboBox, which significantly decreases the number of required widgets.

The Gtk.Notebook container is extremely useful for grouping similar option groups that would otherwise clutter a huge page. In many applications, this widget groups widgets that relate or depend on each other into a preferences dialog.

Menu layout is also another problematic area, because it is not always done in a sensible manner. When possible, you should use standard menus, such as File, Edit, View, Help, Format, and Window. These menus are familiar to users who are experienced with computing, and users expect them. Because of this, these menus should contain standard items as well. For example, the File menu should contain items for manipulating files, printing, and exiting the application. You should investigate how other applications lay out their menu items if you are not sure where to place a particular item.

Repetitive jobs, or those that the user performs often, should always be made quick and easy. There are multiple ways to do this. The most important is to provide keyboard accelerators for many actions —pressing Ctrl+O on the keyboard is a lot faster than clicking the File menu and the Open menu item.

It may take some time for your users to become accustomed to keyboard accelerators, which is why toolbars are also extremely useful for repetitive options. You need to find a balance between placing too few and too many items on a toolbar, though. A cluttered toolbar scares and confuses the user, but a toolbar with too few items is useless. If you have a large number of items that users might want on toolbars, it would make sense to allow the users to customize the toolbars themselves.

Always Be Consistent

Consistency is important when designing a graphical user interface, and GTK+ makes this extremely easy. First, GTK+ provides many stock items that should always be used in favor of homegrown items where possible. The user will already be familiar with the icons for the stock items and will know how to use them.

Speaking of themes, you should fall back on the settings provided by a theme whenever possible. This helps you create a consistent look—not only throughout your application but across the entire desktop environment. Since themes are applied to all applications throughout a desktop, your application is consistent with most other applications that the user runs.

In those few cases where you do need to deviate from the defaults provided by the user’s theme, you should always give the user a way to change the settings or to just use the system defaults. This is especially important when dealing with fonts and colors, because your changes can render your application unusable with some themes.

Another advantage of consistency is that the user learns how to use your application much faster. The user needs to learn only one design instead of many. If you do not use a consistent layout for your application and supplemental dialogs, the user is presented with a brand-new adventure with every new window.

Keep the User in the Loop

One thing that can turn off a user of your application very quickly is if it is not responsive for a long period of time. Most computer users are accustomed to a bug or two, but if your application is processing information and remains unresponsive for quite a while, the user may give up.

To avoid this, there are two possible solutions. The first is to make your application more efficient. However, if your application is not to blame, or there is no way to make it more efficient, you should use progress bars. A progress bar tells the user that your application is still working. Just make sure to update your progress bar! If you do not know how long the process will take, another option would be to pulse the progress bar and provide messages that update the user on the process’s progress.

This loop makes sure that the user interface is updated, even when the processor is busy processing another task. If you do not update the user interface during a CPU-intensive process, the application may be unresponsive to the user until it is finished!

You should also provide your users with feedback when actions are performed. If a document is being saved, you should mark it as unmodified or display a message in the status bar. If you do not provide feedback to the user when an action is performed, it may be assumed that the action was not performed.

Message dialogs are a very useful way to provide feedback, but they should be used only when necessary. The user will become frustrated if message dialogs appear too often, which is why only critical errors and warnings should be reported this way.

We All Make Mistakes

Whether you are an expert or a novice, we all make mistakes. Because of this, you should always forgive your users. After all, everyone has at one time or another pressed an incorrect button that resulted in losing a large amount of work. In a properly designed application, this should never occur.

For basic actions that cannot be easily undone by the user, you should provide the ability to undo the action. For example, these basic actions could include deleting an item from our Grocery List application or moving text within a text view.

For actions that cannot be undone, you should always provide a confirmation dialog. It should explicitly state that this action cannot be undone and ask whether the user wants to continue. For example, you should always ask the user whether the application should be closed when there are documents with unsaved changes. People have been using software for years and have come to expect a confirmation dialog box for actions that cannot be undone.

The Glade Interface

When you launch Glade for the first time, you see a main window with three panes: the main window tree view, the widget palette, and the widget property editor. Figure 11-1 is a screenshot of the main Glade application window with a project opened from the FileBrowser.glade.

The main tree view window facilitates Glade project management. The Main Window Title Bar shows a list of the currently open projects, allowing you to switch among them. The left pane also includes the widget tree view, which shows the widget containment of the project with focus.

The widget tree view shows the parent-to-child container relationships within a project. It is possible to have multiple top-level widgets. However, in Figure 11-1 window is the only top-level widget of the FileBrowser.glade.

This pane is where you specify project options, save the project, and load existing projects. The Popup menus in this window also provide many other options that can help you when working with projects, such as undoing and redoing actions.

The middle pane shown when you launch Glade 3 has buttons for selecting widgets from a widget palette, which lists all of the widgets available to you for designing your applications. A screenshot of the one of the widget palettes is shown in Figure 11-2.

By default, there are five categories of widgets that can be displayed: top-level widgets, containers, widgets used for control, display widgets, and composite and depreciated widgets. You should not use any widgets in the GTK+ Obsolete list in new applications, because they are depreciated and may be removed in future releases.

In addition to the default categories of widgets, you may find other categories that include additional widget libraries. These include widgets added for the GNOME libraries or other custom widget libraries.

Through the View menu, you can change the layout of the widget palette. Figure 11-2 shows a widget palette that is set to show both icons and text. However, you can show only text or only icons depending on what style you are most comfortable with.

To add a new top-level widget to the widget layout pane, all you need to do is click the icon of the desired widget in the Toplevels section. A new top-level widget is then displayed and added to the widget tree in the left pane. To add non-top-level widgets, you need to first click the icon of the desired widget and then click your mouse where the widget should be placed. You must click an empty cell in a container widget for the non-top-level widget to be inserted into the user interface.

Creating the Window

In this chapter, you are going to be creating a simple file browser application with Glade and Gtk.Builder. You begin by creating a new project by clicking on the new project button at the top of the main Glade window or by using the blank project created for you when the application loads. You can open an existing project by clicking on the Open button at the top of the main Glade window if you return to this tutorial at a later time.

After you have a blank project, you can begin by creating a new top-level Gtk.Window by clicking the Window icon in the Toplevels widget palette. In the new window, you see a mesh pattern in the interior of the widget, as displayed in Figure 11-3. This pattern designates a region where a child widget can be added to a container. After selecting a non-top-level widget from the widget palette, you must click this region to add the widget to the container. Follow this method for adding all non-top-level widgets.

After you create the top-level window, you notice changes in the content of the widget Properties pane, shown in Figure 11-4. In this pane, you can customize all of the properties of each widget that is supported in Glade.

The widget Properties window displayed in Figure 11-4 has a complete list of the various options. The pane is divided into sections, which categorize the basic options that are specific to the widget type that is currently selected. For example, the Gtk.Window widget allows you to specify the window’s type, title, ability to be resized, default size, and so on.

The ID field, which is scrolled beyond the bounds of the scrolled window in Figure 11-4 gives a unique name to the widget. Glade automatically assigns a name to each widget that is unique for the current project, but these are generic names. If you plan to reference a widget from within your application, you should give it an ID that means something. It can easily become confusing when you have to load three Gtk.TreeView3 widgets named treeview1, treeview2, and treeview3!

The Packing tab provides basic information about how the widget reacts to changes in the size of its parent widget, such as expanding and filling. Common properties are those provided by Gtk.Widget and are available to all widgets. For example, you can provide a size request in this tab.

The Signals tab allows you to define signals for each widget that is connected by Gtk.Builder. Lastly, the Accessibility tab, designated by the handicapped symbol, gives options that are used for accessibility support.

As you will recall from the first example in this book, an empty Gtk.Window widget is not of any use except for illustrating how to create one. Since the file browser needs multiple widgets packed into the main window for this application, the next step is to add a vertical box container. Select the Box widget from the palette and click inside the grid pattern of window to insert a Gtk.Box widget into the window. You can then use the Properties pane to adjust the orientation of the box (vertical or horizontal) and the number of panes the Gtk.Box contains. Figure 11-5 shows the adjustments necessary for the Gtk.Box properties.

By default, three cells are created to hold child widgets, but you can change this to any number of items greater than zero. The default of three is how many child widgets we need.

By default, a Gtk.Box has a vertical orientation but you can change the orientation to horizontal if needed.

After adding the vertical box, you see three separate, empty container meshes; notice the changes in the Properties pane and the widget tree view pane. To these meshes, we will add a toolbar, an address bar, and a tree view.

Adding a Toolbar

The old handle box widget has long been deprecated since most of the widgets it was meant to contain have been enhanced to dynamically hide their content. The Gtk.Toolbar is one of the widgets that has been enhanced in this way. That means we can directly add the toolbar to the vertical Gtk.Box we added to the main window previously.

When the toolbar widget is added it only appears as a thin strip in the top pane of the vertical box. This is because it does not yet contain any buttons. And the method to add buttons to the toolbar is not immediately obvious. To add buttons to the toolbar right-click on the Gtk.Toolbar entry in the Glade tree view pane and a pop-up menu labeled Edit... appears, which then shows the dialog in Figure 11-6.

The toolbar editor allows you to add any supported type of item to a toolbar. To add a new item, you need only to click the Add button. This presents you with a pane in the editor dialog with which you can modify the new button’s properties. Be careful here as your version of Glade may present you the option of using stock buttons. Stock items have all been deprecated so you must create your own custom buttons instead.

After you add a new tool button, the next step is to choose what type of widget it should be by selecting an option from the Type combo box. The types of toolbar items included in the combo box are a generic tool button containing an image and a label, toggles, radio buttons, menu tool buttons, tool items, and separators. When you select a new type, the dialog immediately changes to allow you to edit properties for the chosen type.

For example, in Figure 11-6 the selected tool button is of the type Gtk.MenuToolButton. Every toolbar item gives you the option of whether it should be visible when the toolbar is horizontal or vertical. This allows you to hide the toolbar item when the toolbar has a vertical orientation but show it to the user when the toolbar is horizontal.

Menu tool buttons also allow you to choose a label and image to display in the tool item. An image can be a stock image, an existing image file, or an identifier of a custom icon theme depending on what option you choose.

Along the bottom of the toolbar editor, you see a tree view that allows you to connect signals to each tool button. Glade provides a number of named callback methods for you to choose from that are based on the signal name and the name you gave the toolbar item. You are also able to enter your own custom callback method name. It is possible to specify data to pass to each method function through Gtk.Builder, so you can usually leave the “User data” parameter blank. In Figure 11-6 a callback method by the name on_back_clicked() was connected to Gtk.MenuToolButton’s "clicked" signal.

When you load the user interface with Gtk.Builder, you have two choices for connecting the callback methods defined in the Glade file with those in your code. If you want to manually connect each callback method, you can name the signal handler whatever you choose, as long as the name is unique. However, Gtk.Builder provides a function that automatically connects all of the signals to the appropriate symbols in your executable or Python program. To use this feature, the callback method name you define in Glade must match the name of the function in your code!

The Packing tab includes options to determine padding around the widget, whether the packing is from the start or end of the box, and to determine the widget’s position within the container. These properties are exactly equivalent to the settings you used when adding child widgets to Gtk.Box with box.pack_start() and friends.

After completing the toolbar and fixing packing preferences, your application should look like Figure 11-7.

The toolbar shown in Figure 11-7 contains two menu tool buttons used for moving forward and backward through the user’s browsing history. There are also tool buttons for moving to the parent directory, refreshing the current view, removing a file, moving to the home directory, and viewing file information. Each of these tool buttons is connected to a callback method that you must implement in your code for the application.

Completing the File Browser

The next step in creating our file browser is to create the address bar that shows the users the current location and allow them to enter a new location. This means that we need a horizontal box with three widgets, as shown in Figure 11-8. The three widgets are a label describing the content held in the Gtk.Entry widget, the Gtk.Entry widget that holds the current location, and a button that moves to the location when pressed.

To create the button in Figure 11-8 a horizontal Gtk.Box with two child widgets was added to the button: a Gtk.Image widget set to the GTK_STOCK_JUMP_TO stock image and a Gtk.Label widget named Go.

The last step is to add a Gtk.ScrolledWindow widget to the last cell in the vertical box and a Gtk.TreeView widget to that container. The completed file browser user interface is shown in Figure 11-9. However, we are not yet finished editing the application in Glade.

Making Changes

The file browser is completely designed, but now I have decided that it should include a Gtk.StatusBar widget along the bottom of the window! Making changes to the user interface can be tricky, so this section walks you through a few challenging actions.

The first step in adding the status bar is to extend the number of child widgets contained by the main vertical Gtk.Box widget. To do this, choose the vertical box from the widget tree view. In the Properties pane, you can increase the number of children with the “Number of items” property in the General tab. This adds a new empty space at the end of the vertical box into which you can add a status bar widget.

If you need to reorder the children of a vertical or horizontal box, you first need to select the widget you want to move. Then, under the Packing tab in the Properties pane, you can choose a new position by changing the value of its spin button. You are able to see the child widget moving to its new position as you change spin button’s value. The positions of surrounding child widgets are automatically adjusted to reflect the changes.

Another problematic task can result if you decide that you need to stuff a container into a location where another widget is already added. For example, let’s assume that you have decided to place a horizontal pane in place of the scrolled window in the file browser application. You first need to select the widget from the widget tree view in the main window and remove it by pressing Ctrl+X. After this, an empty box is displayed, in which you can add the horizontal pane. Next, select the pane where the scrolled window should be placed and press Ctrl+V.

Making changes to a user interface used to be a touchy topic with Glade 2, because it did not support undo and redo actions. It used to be very easy to make a mistake and lose hours of work by accidentally deleting your top-level widget, since you could not undo any actions. Now that Glade 3 includes undo and redo support, you do not have to worry as much.

Widget Signals

The last step for this application is to set up signals for all of the widgets. Figure 11-10 shows the Signals tab of the widget properties editor for the Go button. The Gtk.Button widget is connected to the clicked signal, which calls on_button_clicked() when emitted.

In addition to the “clicked” signal, you need to connect to a few others. Each of the tool items should be connected to Gtk.ToolButton’s clicked signal with the exception of the separators. Also, you should connect the Gtk.Entry to activate, which is emitted when the user presses the Enter key when the entry has focus.

Creating a Menu

In addition to toolbars, it is possible to create menus in Glade 3. Figure 11-11 shows the menu bar editor, which is very similar to the toolbar editor. It supports normal menu items and those rendered with images, check buttons, radio buttons, and separators.

You now know of three ways to create menus; this raises the question of which one is best. Every method has its advantages and disadvantages, so let’s take a look at each method.

You first learned how to create menus manually, molding each object to your needs. This method is good to use with smaller menus, because the code will not take up a lot of space and the implementation is located entirely in one place. However, if your menu grows in size or contains more than just basic items, the code can become tedious to maintain and take up a lot of space.

Next, you learned how to use Gtk.Builder with UI definitions to dynamically create menus. This method simplified menu creation, because you could define a large number of actions in a small amount of space. Also, since menus are constructed from UI definitions, allowing the user to edit a menu is extremely simple. This is clearly the preferred method of menu creation if you are not using Glade to design your application.

Glade also presents a very attractive method of menu creation, because after its initial design, maintenance is simple. It also requires no code to create the menu, since Gtk.Builder constructs it for you. However, one problem with this method is that it is not as easy to allow the user to alter the layout of menus and toolbars as with the UI file method.

One method that can easily be employed is to pack all of your widgets with respect to the end of the vertical box or whatever container you use as the child of the main window. Then, when your application loads, you can simply pack the menu created by Gtk.Builder into the window with box.pack_start(). Nevertheless, if you do not need to allow your users to customize the menu, it makes sense to do all menu creation through Glade.

Now that you are finished creating the user interface, you can save it as a FileBrowser.glade file, where project can be replaced by a name of your choice. This file can be loaded with respect to the location of the application or from an absolute path.

Loading a User Interface

The builder.get_object() needs one parameter which is the ID you assigned to the Gtk.Window main window in your Glade project. From this Gtk.Builder can determine all the child widgets that belong to the main window from reading the XML. It can then construct the window from the XML definition.

After constructing the main window, we need to assign all the signal handlers. Gtk.Builder can do this automatically if we supply a special Python class that contains nothing but the signal handler methods. The builder.connect_signals() method does this by supplying an instance of our signal handler class to it as a parameter.

Finally, we need to add the window constructed by Gtk.Builder to our Gtk.Application. This window now becomes controlled by our Gtk.Builder instance. While it is not a full Gtk.ApplicationWindow it acts very much like one as far as controlling the new window. Note that we use the window.show_all() to show the window instead of the window.present() method because our new window has no present() method.

It really is as simple as that. The File Browser window appears immediately and you are off and running. All that is left to do is fill all the signal handler methods, create the store for the Gtk.TreeView widget, build the window initialization code, and you have a working application.

Exercise 1: Glade Text Editor

This exercise implements the text editor from the “Test Your Understanding” Exercise 1 section in Glade. The toolbar in the text editor should be implemented completely in Glade.

This exercise should not require extra coding if you still have the exercise solution from the previous chapter. You can also find the solution to “Test Your Understanding” section on the book’s web site at www.gtkbook.com . This exercise gives you a chance to learn your way around Glade 3 and test out many widget properties.

After you design an application with a toolbar, it is an easy transition to add a menu bar. In larger applications, you should provide both of these options to the user. In the following exercise, you add a menu bar to the text editor application.

Exercise 2: Glade Text Editor with Menus

You have implemented the text editor with a menu bar. In this exercise, redesign the application from that exercise using Glade and Gtk.Builder. First, you should implement the menu with Python and GTK+, which allows you to use both together. Second, you should implement the menu again in Glade.

As with the previous exercise, the solution for Exercise 2 is at www.gtkbook.com . Using the downloadable solution allows you skip coding the callback functions because you already did that in the previous chapter.