Reported by nvdakor on 2014-11-12 17:50
Hi,
Recent NVDA code added several general-purpose dialogs such as the new exit dialog and update check dialog. As opposed to specialized dialogs such as find dialog in browse mode, these dialogs have a common weakness: multiple instance possibility, mitigated with use the weakrefs and an instance variable. Another weakness is the problem of window placement: manual intervention is needed to center them and to provide needed sizers.
To provide a common base case where NvDA core or add-ons may display general-purpose dialogs that are not settings dialogs, I propose a new base dialog class in GUI subsystem as follows:

• Dialog: This new dialog class in GUI will represent a new general-purpose dialog with much needed attributes filled in, such as centering, sizers, handlers for onOK, onCancel and options sizer. It'll borrow somewhat from Settings Dialog class for now unless the devs elect to base the Settings Dialog from this new dialog class (with settings dialog inheriting from the new base dialog). The attributes for this dialog will be its title, the main box sizer, customizable OK and Cancel buttons and events for them, a general-purpose sizer, layout attributes such as centering and an instance variable to make sure this dialog (or its children) appear only once.
• Dialogs in NVDA core will be modified to base itself from the new base dialog. For example, the new ExitDialog will be written as:

class ExitDialog(gui.Dialog):
""" code """

All that'll be added will be the new options for exiting. The dialogs to be modified include exit dialog, donations, update check and alerts, cursor manager's find dialog, welcome dialog, installer and possibly others. I excluded app module and object specific dialogs such as comments dialog in Excel, as they need to be placed near the cell where the comments will appear. In the end, Settings Dialogs will also be rewritten to inherit from the new base dialog if the devs elect to do so.

• In add-ons, whenever an add-on needs to present a dialog that is not a settings dialog, have them inherit from gui.Dialog class. Even when they add settings dialogs, they are ultimately deriving from the base dialog.
  Benefits of this change include ability to change the appearance of vast majority of dialogs by modifying the new base class, as well as to prepare for future WXPython changes for dialog code. Drawbacks include implementation strategies, tuning existing dialogs to use the new scheme and overlap with settings dialog code.
  Thanks.