FW: [nvda-spl] Request for comments: should standalone settings dialogs be unified under main Studio add-on settings screen?



Should you have any questions or comments about the below proposal for StationPlaylist add-on, please either write to me directly or send your reply to NVDA-SPL mailing list. Thanks.


From: nvda-spl@nvda-spl.groups.io <nvda-spl@nvda-spl.groups.io> On Behalf Of Joseph Lee via Groups.Io
Sent: Thursday, March 5, 2020 10:15 PM
To: nvda-spl@nvda-spl.groups.io
Subject: [nvda-spl] Request for comments: should standalone settings dialogs be unified under main Studio add-on settings screen?


Hi all,


After thinking about user experience surrounding configuring add-on settings, I decided to gather feedback about scrapping standalone settings dialog and unifying them under main Studio add-on settings:


Background: SPL add-on provides commands to open settings dialogs to configure add-on settings. These include:


  • Alt+NVDA+number row 0: Studio add-on settings screen
  • Alt+NVDA+Number row 1: end of track alarm
  • Alt+NVDA+number row 2: song ramp alarm
  • Alt+NvDA+number row 4: microphone alarm
  • Unassigned command: metadata streaming


Of these, end of track alarm is the oldest code (implemented in 2014), while Studio add-on settings screen is the latest (added in 2018).


When I first introduced SPL add-on in 2014, my goal was to provide equivalent experience (or close to it) for users of scripts for JAWS and Window-Eyes. As part of this, end of track and song ramp/intro alarm dialogs were introduced, as JAWS scripts had commands to configure these settings. Then in 2015, I introduced the first version of Studio add-on settings dialog, bringing together various add-on settings in one place. Three years later, with NVDA 2018.2 introducing multi-category settings screen, SPL add-on followed suit, introducing its own multi-category settings screen.


While working on current version of SPL add-on settings screen, I created a dedicated “Alarms” panel to bring together settings related to alarms. As a result, you can now configure all three alarm categories – end of track, track intro, microphone – under one roof. This means there is duplication between Studio add-on settings screen and dedicated alarm settings dialog. At the same time, settings that are part of metadata streaming dialog were also incorporated into “Metadata streaming” category under add-on settings.


Now in 2020, while thinking about streamlining user experience when it comes to dealing with attempting to open multiple add-on settings dialog at once (something you should not do), I ran into a complication: in order to really streamline the user experience, a workaround must be developed, something that may or may not survive future NVDA releases. Thus after thinking about it, I decided to go with scrapping standalone settings dialogs in favor of unifying everything under SPL add-on settings. This means instead of Alt+NVDA+number row 1 opening end of track dialog, it’ll open Alarms category in add-on settings instead. Besides, since all alarm settings are housed under one category, it would make lives of users easier by presenting all alarm settings at once. I know that some of you may not like the direction this is going, but when it comes to add-on maintenance, some things must be changed in order to make the add-on future-proof and react better to changes in NVDA itself.


Question to you all: is this the right way to go?


Related to this: I’m also thinking about removing stream label command (F12) from encoders as it duplicates encoder settings – the very first option in encoder settings is stream label. The reasoning is same as above.


If this direction is adopted, it’ll be done in stages:


  1. Version 20.04: change error messages when trying to open add-on settings dialog if another SPL add-on settings dialog is active (implemented).
  2. Sometime in summer 2020 (winter in southern hemisphere): implement necessary changes so you can open specific parts of add-on settings using commands formerly used to open dedicated settings dialogs (see the example above). You will be able to toggle between “old” and “new” behavior for a time.
  3. Later in 2020: if approved, make the new behavior the default.
  4. Old code will not be removed – just commented out, as there are places where they can be used.
  5. Sometime in the future: remove old code.


Comments are appreciated.



Join nvda@nvda.groups.io to automatically receive all group messages.