GUI: A base dialog for general-purpose dialogs with multiple settings

[nvaccessAuto]

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.

[nvaccessAuto]

Comment 1 by jteh on 2014-11-12 22:13 The problem with this is that aside from centering and multiple instance prevention, most code isn't common to all dialogs that aren't settings dialogs. For example, the update check dialogs don't have OK and Cancel buttons. Some dialogs need to show themselves in their constructors and others don't, which is a problem for centering in a base class. Some dialogs don't even need multiple instance prevention because they will never be launched twice; e.g. the update installation dialog. The point is that if we give it a generic name like Dialog, it will seem as if authors have to use it for all non-settings dialogs, but this isn't true in reality.

In short, I agree we need a common base class for preventing multiple instances, but I don't think we can abstract the rest.

[feerrenrut]

A common base class could perhaps override the Show and ShowModal methods in order to ensure that prePopup / postPopup happen, see comment on "Introduce the ability to postpone a downloaded update" #6355

As discussed in the linked comment, it's not certain that newer operating systems or versions of wx require this. Linking / suggesting for completeness sake.

[josephsl]

Hi,

2024 update: I think there is an issue in 2025.1 milestone to do something about dialogs. We could combine this issue with that one or leave the issues separate.

Thanks.