Summary

We categorized dialogs into three "intelligences", dumb, standard, and smart, and showned that they can be used modally or modelessly. Dumb dialogs are easy to create, and are perfectly adequate for doing widget-level validation. Dumb dialogs are normally used modally, and if we are careful they can be generalized since they can be very loosely coupled to the application's logic. Nonetheless, using dumb dialogs usually ends up leading to programmer frustration and the need to rewrite in the form of a standard or smart dialog, so it is often best to avoid them except for those very simple cases where just one or two values are required and the built-in QInputDialog static dialogs are not suitable.

The most common choice is between a standard modal dialog and a smart modeless dialog, and in the latter case between the "apply" and "live" styles of updating. Modal dialogs are the easiest to program because they block any other interaction with the dialog's parent windows and their sibling windows, thereby reducing the risk that the data they are working on is changed from under them. But modeless dialogs are preferred by some users, and are particularly convenient when users want to try out various options before deciding which ones they want. Modal dialogs can also be used for this purpose if they provide some kind of preview; for example, font dialogs are often modal, and show sample text that reflects the user's font settings as they change them.

The two validation strategies that we have looked at, post-mortem and pre-ventative, can be used on their own or in combination. From a usability point of view, preventative is often considered to be superior, although it can lead to user frustration. For example, a user might complain ("I want to set this to five but it won't let me") when the setting is invalid because of another setting elsewhere on the form.

It is possible to design a dialog so that it can be used both for adding and for editing items. These add/edit dialogs are no different from other kinds of dialogs when it comes to the creation, layout, and connection of their widgets. The key difference is that they may need to behave in different ways depending on whether they are adding or editing. When editing, the widgets are populated from the item passed in, and when adding, the widgets are populated with default values. If the dialog is accepted, it may simply provide accessors through which the values set can be retrieved, leaving the work to the caller, or it may be smart, able to update edited items directly, and to create new items if the user is adding. See the AddEditMovieDlg class in chap08/additemmoviedlg.py (its user interface design is in chap08/additemmoviedlg.ui), and the TextltemDlg class in chap12/pagedesigner.pwy, for examples of add/edit item dialogs.

Another possibility is to avoid using a dialog at all and to allow the user to edit data in-placeā€”for example, in a list or table. This approach is covered in the chapters on model/view programming.

Was this article helpful?

0 0
Tuberminator

Tuberminator

The main focus of this report is to show how to get involved in video marketing on the run, how to rank quickly on YouTube and Google using FREE semi-automatic tools and services. QUICKLY AND FREE. I will show methods and techniques I use to rank my videos, as well as free resources and tools to make video clips, to get backlinks and free traffic.

Get My Free Ebook


Post a comment