PyQt4对话框(dialog类型介绍)

大多数的GUI应用至少有一个对话框，大多数GUI应用有一个main window，而且这个窗口带有许多个dialog。
传统的对话框之一是由于它的“智能”，这里可以将它们分为：dump、standard、smart，
这依赖于能识别多少应用程序的数据。这些分类将会影响创新并初始化对话框。

除了依据智能分类外，对话框还可以依据形态(modality)分类。一个应用形态的对话框，一旦被调用，
它将作为能与用户进行交互的应用程序一部分。直到用户关闭对话框，它们在应用的其他部分将无法使用。

一个窗口(window)形态的对话框，和应用心态的对话框工作方式类似，除了它不能和它的上级窗口交互外，
这些上级窗口包括：父级窗口、父级的父级窗口、顶级父级窗口、父级的兄弟窗口。
除了应用程序只有一个顶级窗口，应用形态和窗口形态的应用没有实际的差别。
当引用一个没有指定窗口类型的模块(modal)窗口时，窗口将默认为window形态。

与模式对话框对应的是无模式(modeless)对话框。当一个无模式对话框被调用时，用户可以和对话框进行交互，
而且在应用程序的其他部分同样可以与该对话框进行交互。这对于如何设计代码是有影响的，
因为用户可能会影响程序状态在主窗口和无模式对话框中，因此这对另一方有影响。

写对话框的另一重要的方面是如何处理验证。无论在哪里，可能都要尝试去选择合适的widget并且
设置它们的属性用来避免去写任何验证代码。例如，如果需要一个整型，可以选择一个QSpinBox并用它的
setRange()方法来约束用户接受的数值范围。可以调用应用于单个widget“widget-level”的验证；
数据库程序可以调用“field-level”验证。有时候需要比widget级别更进一步的验证，特别是存在相互关联时。
例如：一个剧院的预定系统可能有两个下拉框，一个用于选择楼层、另一个用于选择作为排。
如果底楼座位排设置为A-R，第一层作为排设置为M-T，那么狠明显，只有一些楼层和座位牌组合是有效的。
由于这类事件，必须执行"form-level"的验证；数据库应用程序经常叫作"record-level"验证。

当一个验证发生时，与之相关的另一个验证也会被激发。理想情况下，一点也不想用户能够进入无效的数据，
但是有时候这种预防是相当困难的。将验证分为两大类：
post-mortem：当用户进行确认时，在这一点上发生的验证是哪一个
preventative：用户操作编辑widget时发生的验证

由于dialog有不同的”智能等级“、三种形态、多种验证类型，似乎有很多可能的组合可供选择。
事实上，使用的组合倾向于每次都使用相同的一个。例如，在大部分情况下，可能使用dump与standar对话框，
以及无模式的smart对话框。对于验证，正确的策略非常依赖于情况。