Comment 1 by jteh on 2010-02-27 10:01
Changes:
Changed title from "linking preferences with linked property sheets" to "Combine separate NVDA Preferences dialogs into a dialog with several property pages"

Comment 2 by briang1 (in reply to comment 1) on 2010-09-02 18:18
Replying to jteh:

Changes:
Milestone changed from None to 2010.3

Comment 3 by mdcurran on 2010-11-24 06:58
Changes:
Milestone changed from 2011.1 to near-term

Comment 4 by heikofolkerts on 2013-07-17 18:49
Since NVDA now supports plugins this would be a good thing for one. This way one can choose to use a combined dialog with several pages and the traditional behaviour including the shortcuts stay intact.

I think that a combined Dialog is closer to other dialogs users have to handle and it can speedup configuration significantly.

Instead of using tabs one could use a tree view like eclipse uses in its setting dialogs.

If no one wants to handle this ticket in the near future I could try a fix or plugin what ever seems to be best.

Comment 5 by heikofolkerts on 2013-07-21 18:23
After review of gui/settingsDialogs.py here is a short design how I'll try to implement this:
The base class SettingsDialog has to be modified so that creation of the OK and Cancel buttons is optional an can be controlled from instance creation. The Dialog that will contain all settings will create one of the SettingDialog subclasses for every tab page and prevent them from creating the OK and Cancel buttons. The containing dialog will provide this buttons.

When the user presses OK the container dialog will give every settingsDialog the chance to validate its data and display an error message if needed. After validation of all settings dialogs is complete all settingsdialogs are asked to save their data and expected to do so without errors (they validated OK) Finally the dialog closes and all containing windows are destroyed.

This implementation has the following goals:

• use the existing SettingDialog sub classes and prevent duplicate code.
• keep the possibility to call up specific setting dialogs - so the users don't have to change their behaviour when making settings
• implement the requested all settings dialog with minimal change to the code.

The new dialog could be added to the existing settings sub menu so users can decide wether they want a specific setting dialog or the whole settings in one.

Hints and changes to this design are wellcome to make it good and successful.

Comment 6 by jteh on 2013-07-21 23:09
This makes sense. A few thoughts:

• There shouldn't be the option of the old-style single dialogs. It makes things confusing and difficult to document. We either need to settle on the single dialog approach once and for all or forget about it.
  • That said, we don't want to make life more difficult for existing users. The single key commands to open sections should remain for now (unfortunately; I personally think they never should have been introduced) and focus should land on the section switcher when the dialog opens.
  • Even so, this kills single letter access because lists don't allow for mnemonics; e.g. c for review cursor. Not sure how to handle this nicely.
• The list of sections should probably be a list, not a tab control, as you can have more sections in a list.
• There needs to be some way for add-on settings UIs to register themselves.
• I know this makes life difficult, but the dialog shouldn't load all settings dialogs at once, nor should it apply settings for all sections when it closes. Doing so will be far too slow, since some of those dialogs take a while to load/apply; e.g. the Synthesizer dialog. I guess it can load the relevant dialog when you move to it and it should only apply settings for dialogs which have changed. This could be very tricky to implement, though.
• There are certain dialogs which depend on settings being applied in other dialogs; e.g. the Voice Settings dialog depends on the synthesizer setting. I'm not really sure how to handle this yet. There'll probably need to be an Apply button which applies pending changes and clears any cached section pages.

Comment 7 by heikofolkerts on 2013-07-22 17:58
tab controls could be generated dynamically but I agree that a list would allow for more items. The tricky part seems to be to load the aprociate settings when the user selects a item in the section list - he or she would normally want to tab to the details. There are examples for those setting dialogs e.g. Visualstudio 2008 preferences, but if the details take a while to load and we cannot speed that up, the user may be irritated.

If we nedn't keep the old style of single setting dialogs we can think of new ways of organize the settings. Maybe the control panel in windows 7 can be a good template.

Are there any setting dialogs in other application that load settings dynamically and we find them accessible enough?

Comment 8 by heikofolkerts (in reply to comment 6) on 2013-07-30 17:57
Replying to jteh:

This makes sense. A few thoughts:

• There shouldn't be the option of the old-style single dialogs. It makes things confusing and difficult to document. We either need to settle on the single dialog approach once and for all or forget about it.

That's right and KISS - Keep it simple stupid. Since the plugins should have a chance to register for a combined settings dialog they would have to provide a single settings dialog. So we really won't get rid of this aproach without changing many things.

• That said, we don't want to make life more difficult for existing users. The single key commands to open sections should remain for now (unfortunately; I personally think they never should have been introduced) and focus should land on the section switcher when the dialog opens.
• Even so, this kills single letter access because lists don't allow for mnemonics; e.g. c for review cursor. Not sure how to handle this nicely.

But since the shortcuts exist they are helpful for those who change the settings frequently.

• The list of sections should probably be a list, not a tab control, as you can have more sections in a list.
• There needs to be some way for add-on settings UIs to register themselves.
• I know this makes life difficult, but the dialog shouldn't load all settings dialogs at once, nor should it apply settings for all sections when it closes. Doing so will be far too slow, since some of those dialogs take a while to load/apply; e.g. the Synthesizer dialog. I guess it can load the relevant dialog when you move to it and it should only apply settings for dialogs which have changed. This could be very tricky to implement, though.

And this is in my opinion a reason to not implement the combined settings dialog. It would take much efford, propably breaks existing things and all this to speed up making a bunch of settings in a go. It would make life easier for a specific use case but not bring new functionality to NVDA. When I started working on this ticket I didn't know about this kind of problems in the background.

The only solution I can think of that is possible with relative efford is a dialog with a lostbox for the sections, an edit button for the selected section which would open the allready existing single settings dialog. So Instead of reentering the settings submenu again one could select another item from the listbox and edit the corresponding settings. Would this be an aceptable solution for the original requester?

Comment 9 by briang1 on 2013-07-31 06:37
Well, let me firstly state the obvious. This ticket was raised a long time ago, before many of the extra bits of nvda, like add ons and enhancements requiring extra parameters were added to the property sheets.

If an alternative had been designed then, then the system would have grown around that format. With the ingrained use of shortcuts to certain dialogues, this has more or less shot the idea in the foot, so to speak as mentioned here. However it might still be a handy thing to have a list based selection so one can get to property sheets without going back through all the menus, or perhaps allow the system to just return to the previous menu for selection of another sheet rather than the closing of the sheet putting you back completely out of the menu system entirely.

Of course the logic of what happens when you do the short cut key entry needs to be looked at, so storage of how one accessed the sheet needs to be preserved.
If the tree view selection is used, this would assuming that the sheets change as you move between items be quite sluggish due to the way some dialogues do take longer than others to populate .
So, at the moment I'd suggest merely being able to close a sheet and get back to the last menu. I assume this would work like the Windows Apply system, though there seems to be several versions of this, ie, either a close and go to last menu, or don't close and then need another action to move off to another sheet.

Just a few thoughts.

Comment 10 by heikofolkerts on 2013-12-02 19:21
After the advent of configuration profiles and some more setting dialogs I think there is no good trade-off for the work this ticket would need in contrast to the benefit. So I'll stop working on this and delete the aprociate branch.

Comment 11 by zahari_bgr on 2013-12-02 19:56
Hi,
I think implementing this feature could reduce confusion of configuring NVDA a specially after introducing user profiles.
In addition of the unified dialog, one could have a combo box, which says which profile's settings we're editing.
Something similar is already done in Orca, though it makes a difference between user profiles and application specific settings.
Add-on specific settings could be presented as different tabs/items.

I don't know how much work it could need, but I'm sure of the benefits.
So, please dont delete anything, smile.

Comment 12 by briang1 on 2013-12-03 08:22
I also feel that at least to many theprofiles will not be understood or used, so really cannot see why having such profiles makes any difference to the ease of use combined property sheets will have.

In many screenreaders the basic settings are in a tab identified property sheet system while other add in and app settings are indicated by some form of display at the top of each sheet so one knows if its global, ie default or tied to an event/application which is going to be configured.

Comment 13 by nvdakor on 2014-02-28 10:06
There is an add-on under development which sort of implements this in a treeview-like structure:
https://bitbucket.org/nvdaaddonteam/rapidsettings

Comment 14 by briang1 on 2014-03-03 09:09
You may have thought of this, but with profiles, this in effect means settings that are customised being triggered by an event of some kind. So any add on like this needs to be capable of being used for that as well as general setting up. as I said earlier, tree views do work well, but can be sluggish if one of more of the property sheets has a lag when it is selected. this does not matter with shortcut keys or the menu selection as the sheet is not being displayed live so to speak, but in a tree view situation it can mean items are skipped or it runs painfully slowly on some machines.

cc @jcsteh, @dkager, @josephsl

Something like tab controls have also been discussed in #214 and #1885. Given the fact that the amount of options has been increased in the last few years, I think we'd best go for a tree view, which allows for categories and sub categories. I wouldn't go for something like Rapid Settings (i.e. also showing all options in a tree view)

A tab control is definitely not going to work here. While a tree seems to be the logical choice, we should still consider a list or at least consider keeping nesting to a minimum. I'm concerned that nesting things might make things hard to find. For example, it might make sense to put Voice and Synthesizer under a category called Speech. However, while Document Formatting and Object Presentation are related, many users probably won't think to look in the Presentation category for Formatting settings.

Hi, so in a way emulate JAWS Settings Center?

As I understand it, JAWS puts all individual settings in the tree view, not just categories and subcategories. I could be wrong, though, as I haven't had much experience of the JAWS settings centre. Anyway, we don't want individual settings in the tree (if we do use a tree), only categories and/or subcategories.

Anyway, we don't want individual settings in the tree (if we do use a tree), only categories and/or subcategories.

I agree here.

Here are some thoughts about implementation:

What to include?

Personally, I think we shouldn't include everything in such a dialog which now can be find under the options menu (e.g. personally I prefer speech dictionaries, Punctuation/symbol pronunciation and Input gestures to be separate dialogs). The rationale for this is that these dialogs operate apart from NVDA's configuration manager

How to implement?

I'm thinking about the following rough path:

1. Create a new MultiCategorySettingsDialog class based on SettingsDialog.
2. Create a new SettingsPanel class that holds code which is relevant for every settings category. E.g. it should have an onSave method, similar to the current onOk method on ettingsDialog
3. Convert dialogs like GeneralSettingsDialog to GeneralSettingsPanel and base them on the new SettingsPanel class
4. In the new MultiCategorySettingsDialog, add a container alongside the list of categories. A selection change in the list should populate the container with the associated settings panel. I'm not sure whether a wx.Container is strictly necessary here, I belief NVDA Remote uses a container with panels for the connection dialog.
5. For add-ons, we could add a new function to addonHandler which allows people to register a new settings category in the multi category dialog. However, I belief that a requirement should be that add-ons should utilize NVDA's configuration system for this. Add-ons which utilize their own settings files should not be allowed to integrate their settings in the new dialog

Since I and others have been crowding the braille settings dialog quite a bit I was also thinking about splitting that up. For example, Display, Translation, Cursor. Here an umbrella treeview node Braille could be handy, but not essential. You could also use names like Braille Display, Braille Translation, etc.

Curiosity: the NVDA menu item is called Preferences, but then the dialogs talk about Settings.

Some might argue that additional single keystroke bindings (like NVDA+control+g) is the solution, but this consumes a lot of keystrokes and available keystrokes are already somewhat limited.

Agreed. The NVDA+n, p, g method to open General settings is very nice though. The same goes for keystrokes that change a single setting. But keystrokes to open specific settings dialogs feel a bit out of place to me.

1. I think we're going to have to create all the panels when the settings dialog is opened. If that's true, init time might be a concern if one of the dialogs takes a while to initialise. The Synthesizer dialog is one possible example, since it has to load synth drivers. We may need to come up with some late init method for these cases which only gets run as the category is selected.

Good point, agreed here

2. This would change the existing shortcuts used to open various settings categories from the NVDA menu where the existing shortcut isn't the first letter of the category. For example, you wouldn't be able to open Braille Settings with NVDA+n, p, r. This bothers me because this kind of thing becomes very ingrained for users who want maximum efficiency and changing it could set them back quite a bit. Some might argue that additional single keystroke bindings (like NVDA+control+g) is the solution, but this consumes a lot of keystrokes and available keystrokes are already somewhat limited. I guess we could modify the keyboard behaviour of the tree so that, for example, r jumps to Braille, but then that would be non-standard for a tree, which might confuse users.

Ah, that's what I forgot to mention. My initial thought was to just keep all the menu items in place, but to let them open the same settings dialog with the right panel selected in the list. So, for example, keep the nvda menu>options>braille settings option, but make it select the braille category in the new dialog.

3. It might be possible to modify the existing SettingsDialog class so that most existing subclasses just get integrated into the new system without changes. I wonder whether it's worth doing that.

Hmm, that's an interesting thought indeed. We should consider this for sure.

On one hand, it means less code change and even some add-ons might benefit.

True, but I still think we should rename stuff like SettingsDialog to SettingsPanel, and than recreate SettingsDialog for backwards compatibility.

On the other hand, SettingsDialog, onOk, etc. aren't a good name in this case and there may be weird compatibility issues that aren't obvious because authors weren't forced to explicitly vet their code for the new system.

SettingsDialog, onOk can be kept for backwards compatibility and it can refer to something like SettingsPanel, onSave. As for your last point, that's probably much more difficult to check beforehand.

@leonardder commented on 15 Jun 2017, 00:15 GMT+10:

My initial thought was to just keep all the menu items in place, but to let them open the same settings dialog with the right panel selected in the list. So, for example, keep the nvda menu>options>braille settings option, but make it select the braille category in the new dialog.

That would work, but a) this is a pretty weird pattern for a GUI (a whole heap of options which end up opening the same dialog in different ways); and b) it does mean there are two paths in the GUI to get to the same thing, which creates redundancy and thus complicates the user experience. I wonder how weird it would be to have a tree with overridden keyboard behaviour? We could expose the keyboard shortcuts to accessibility using dynamic annotation, though I'm not sure how we'd do it visually; they need to be underlined somehow.

@jcsteh wrote:

We could expose the keyboard shortcuts to accessibility using dynamic annotation,

That's an interesting idea. That would be the first time we'd use dynamic annotation in NVDA"s code right, or have I missed something here? Quite offtopic, but is this also the kind of implementation you once mentioned to have in mind for lists with checkable items?

@dkager wrote:

Looking at the menu items, most have a unique first letter. Doesn't first letter navigation work out of the box in treeviews?

I belief it does

An alternative would be to have a list of group names (vertical tabs) on the left and a pane with settings on the right.

I don't quite follow this. Do you want a list kind approach (i.e. wx.ListCtrl, like Windows 10 settings) or real tab controls (i.e. task manager)?

I don't quite follow this. Do you want a list kind approach (i.e. wx.ListCtrl, like Windows 10 settings)

Yes. I guess real tabs are also possible, but lists are cool. :)

While looking at this, I got an additional nut to crack. How should we set the values of the options in a category? For example, what to do when someone opens the settings dialog with the general category selected, he changes his speech symbol level and gets to the speech category afterwards. Should the symbol level match the level at dialog or at panel activation time? If the latter, we probably also want to save the settings in a panel when it is deactivated. Personally, I think we should just go for dialog activation time here.

I started with an initial implementation in https://github.com/BabbageCom/nvda/tree/i577 . This is far from ready for a pull request.

• I didn't do anything about the look yet, so it might look very ugly. We probably need sighted assistance for this, so any thoughts from @feerrenrut are highly appreciated.
• Currently, all the configuration manager options (e.g. general settings, voice settings) activate the same dialog. This will probably go away in the future
• I would like to have a kind of heading at the top of every panel with the panel's title, but do not know yet how to accomplish this in a look friendly way. @@feerrenrut or @josephsl, ideas?
• The categories list is a list box, which can be changed into a tree view if desired. We should consider this if speech dictionaries get integrated into this dialog as well.
• The current implementation has no facilities to integrate add-ons into the system with backwards compatibility (i.e. integrating addons into the new system without any change into the add-ons code is currently not possible). Honestly, I think we should keep it that way and offer people information on how to upgrade their add-on.
• Sub dialogs and message boxes will probably break

@LeonarddeR I think it will be easier to provide feedback on feedback on your approach via a PR. Would you mind creating one?

Hi,

Returning to add-ons:

Regarding add-on GUI's, I'll take a look at it for 2018.3 (once multi-category settings lands in master). The idea for add-ons is to add a new function in add-on handler that'll add settings panels for add-ons into a list, and this list will be consulted by NVDA Settings when opening the dialog.

For add-ons that cannot integrate their GUI's into Settings panel, one way is to at least give them a chance to add "apply" button or create a portal (via a settings panel) to their own dialogs.

Thanks.

@josephsl commented on 18 Apr 2018, 11:16 CEST:

The idea for add-ons is to add a new function in add-on handler that'll add settings panels for add-ons into a list, and this list will be consulted by NVDA Settings when opening the dialog.

It would be enough to let that function call gui.settingsDialogs.NVDASettingsDialog.categoryClasses.append.

Note that the multi category settings dialog will most likely not display the correct configuration profile in the title of the dialog when editing settings for an add-on panel.