Dialogs 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 userswant 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 preventative,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 tofive 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.
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. *To know more about dialogs in python,you can visit the following link:http://python-gtk-3-tutorial.readthedocs.org/en/latest/dialogs.html *The examples we study in this chapter are:pen.pywnumbers.pyw
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 userswant 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 preventative,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 tofive 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.
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.
*To know more about dialogs in python,you can visit the following link:http://python-gtk-3-tutorial.readthedocs.org/en/latest/dialogs.html
*The examples we study in this chapter are:pen.pywnumbers.pyw