Add-on store discussion

[seanbudd]

Now that #13985 has been merged, please open new issues for add-on store issues, as you would for any other issue on alpha.

Discussion of the PR #13985

Discussion is limited to here to make working on the PR easier.
Please use the threaded replies to respond to comments and avoid email based replies.

Emoji reactions have been used to mark threads.

• ☹️ means the remaining issues in the discussion are out of scope for the first alpha release of the add-on store.
• 👀 means the issue is being investigated

[Adriani90]

It would also be good to have a column called "date of last published stable release" containing a date when the last stable release has been published by the add-on author. In that case the user would know if an add-on is outdated or poorly maintained even before installing it. Or even better, provide a version history overview like in usual app stores where you can see the dates of all stable releases published so far.

[seanbudd]

I am going to consider this out of scope for now - this is not easily possible with the current schema.
Could you also explain a bit more why this is necessary? Add-ons currently list which version of NVDA they were last tested with, which is fairly accurate to the year, since 2019. We would rather users rely on NVDA versions than dates for gauging if an add-on is outdated.

[XLTechie]

@Adriani90 I can see dates perhaps being useful in the case of incompatible add-ons. However any stable add-on has to have been updated after the most recent .1 version of NVDA, so can really never be more than, perhaps, 15 months old at the most.

That said, because it could be useful IMO for incompatible add-ons:
Would including the updated date at the end of the "other details" box be reasonable @seanbudd? At the moment I'm not sure where you would get it from, since this isn't backed by a real database with easy record dates, but perhaps in a future version we could auto-generate that and include it in the JSON on submission? Previous ones could be obtained and integrated with a script looking at file or GitHub release dates. I would probably be willing to come up with something in bash to do that if you were on board.

But I wouldn't suggest this for the first release of the store, as it's more tricky than it looks on the surface, given the current implementation.

[wmhn1872265132]

I think the more meaningful effect of this option is that Add-ons can be sorted by release date, which is helpful for users to understand which Add-ons have been added to the store recently. At the moment, it is more difficult to know which Add-ons have been added since the last time I checked the store.

[CyrilleB79]

Hi @seanbudd

Following the list of issues reported in #13985 (comment) and #13985 (comment) and your answer in #13985 (comment):

First of all, thanks for all the modifications after my comments. Could you please provide a new try build? This way I can check various points that you have fixed or on which you have commented. Thanks.

Here are points where I can already answer:

13. When add-on store dialog is open in the background with last focus not in the list, e.g. on the "Filter by status" combobox, if you alt+tab back to it:
    Actual: you can hear that the foreground window, the selected add-on and the focused control are reported, e.g.:
    "Add-on Store dialog Add-ons documentation Filter by status: combo box Available add-ons collapsed Alt+f"
    Expected: you should hear that the foreground window and the focused control are reported, not the currently selected add-on, e.g.:
    "Add-on Store dialog Filter by status: combo box Available add-ons collapsed Alt+f"

Not sure how to fix this - seems like a wx bug. Is this a serious and misleading problem? Or a nice to have?

Of course it's not a critical bug. But it would help the overall understanding of the add-on store GUI by users. Keeping this bug would be one more case when NVDA is over verbose where other screen readers are not.
If you choose to merge add-on store in alpha with this bug, I would recommend:

• To open a ticket on NVDA side to track this issue
• To open a ticket against wx if it's confirmed that it's a wx bug, or to indicate the wx version where this bug is fixed if it already exists.

20. The checkbox to include outdated incompatible add-on is alone in its settings panel. Is there a project to have other controls in this panel?
    IMO, it would make sense to have it directly in the add-on store dialog where we have all the other controls used to determine which add-ons are shown in the list or not.

I think the typical UX pattern in NVDA is to have settings in the NVDA preferences. I don't think we should start leaking settings out of the settings dialog at this stage.
We plan into include settings for auto updating and there's a few other flagged items.

There are already settings set out of NVDA settings dialog in NVDA, e.g. speech viewer position and "show at startup" config. But I agree that the typical UX is the settings dialog.
If you choose to keep this checkbox in the settings dialog, I have two concerns:
20.1. The settings panel should be global and not profile-dependant (title of the panel) and the configuration should be saved only globally, not in profiles
20.2. Look at following use case (I still have to test it on a try build however):

• the user opens add-on store and looks for his favorite add-on
• He cannot find it because there is not yet a compatible version
• He opens settings to allow incompatible version and validate

In the add-on store (still opened), the add-on list is not updated with incompatible add-ons.

An alternative implementation would be to set the checkbox in the add-on store anyway, but not to save the config at all. That is the checkbox would unblock the incompatible add-on installation only for the current session. This has the addvantage that the user will not forget that he has bypassed the manifest security once. Personnally, I prefer this last approach.

[seanbudd]

The checkbox has been move to the add-on store dialog, away from settings. It now works like the other filter controls, only for the session.

[seanbudd]

With (13) can you explain why you expect the selected add-on to not be reported? Isn't it useful information, e.g. for performing actions on the add-on.

[seanbudd]

Here is another try build: https://ci.appveyor.com/api/buildjobs/bknb6jej5ct3lk70/artifacts/output%2Fnvda_snapshot_try-addonStore-base-28263%2Cf75845d8.exe

Please note that the branch is still incomplete and issues with it may have already been resolved.

[CyrilleB79]

With (13) can you explain why you expect the selected add-on to not be reported? Isn't it useful information, e.g. for performing actions on the add-on.

If "Action" button is selected, it's useful to know on which add-on the action applies.
But if almost all of the other controls are selected (e.g. search field, tabs, channel filter, enabled/disabledclose button, etc.), this has no sense, is oververbose and is confusing. When the list is selected, we also can here two times the name of the add-on which is oververbose.
Generally, when alt+tabbing to an application, we can hear the title of the application window (forground window), and then the focused control. Having the extra info of the add-on name, we may think it's part of the window name or of the control, which is not the case.

Note that in the old add-on manager when the "Help" or the "Enalbe"/"Disable" button was selected and you alt+tab back to add-on manager, the add-on's name was not reported. There does not seem to have been any complain for this.

IMO, if you really wish to have the add-on information when the "Action" button is focused, you should, if possible, associate the add-on's name only when the "Action" button is focused. E.g. putting it in an associated description or in a dedicated mini-panel.

[seanbudd]

This issue should now be fixed via 9e4152b.

When removing an add-on, the add-on store JSON cache is now removed, which should fix these problems.

[seanbudd]

updateChannel is not a valid or supported key in the current NVDA add-on manifest schema. I'm not sure why this is expected to be supported.

[seanbudd]

"External" has been added as a channel of add-ons, for add-ons from external sources.

[seanbudd]

can you confirm which commit you are using?

[nvdaes]

9110c92

[seanbudd]

thanks, this should be fixed as of 0b8f8e3

[XLTechie]

@seanbudd wrote (sorry, it won't let me comment in thread, probably because it's hidden):

You can update from an incompatible version to another incompatible version, it's an edge case but needs to be supported I believe.

I agree with this, but I don't think we are talking about the same thing.

What I am saying, is that check for updates should always check for updates to incompatible add-ons, not only when the checkbox is checked, so the box shouldn't be there on updates. Either that, or the box should be checked by default on the updates page.

• Either a compatible version has been released, and most users will want to know about that, so incompatibles should be checked for updates; or
• As you say in your reply, there might be an update from one incompatible version to another (rare), in which case the user will want to know but probably doesn't expect it, so won't think to check the box.
  In either case, the user shouldn't have to check the box for those results to be shown.

TL;DR: IMO, the incompatible checkbox should only appear on the "available add-ons" tab.

[seanbudd]

To be clear, the situation described here is not entirely relevant to the setting. Incompatible add-ons that have updates available will always be shown. The filter is whether or not fetch incompatible add-ons to include as an update source.

However, as you mention, this is so rare that we should instead always include incompatible add-ons in the update page.

I'm going to leave this as a nice to have once this is on alpha

[seanbudd]

I've opened this PR to improve the disk management: #14955

[seanbudd]

this should be resolved now, correct?

[XLTechie]

@seanbudd As of pr13985-28342,00544926:

• When starting a portable copy, %appdata%\nvda\addonStore is not created.
• However, when running a temporary copy, it is.

So I would say that this is still not resolved.

[seanbudd]

Portable copies use a different folder for the userConfig.

The installer may create these directories, but no files are written to.

[seanbudd]

resolved via #14968

[XLTechie]

When focus is on the list, and the tab is changed with Ctrl+Tab, "Available add-ons" is not announced. When that tab is reached, there is a pause, and then the first available list item is spoken.

I wouldn't suggest delaying alpha merge for this, but I would suggest fixing it before release if possible.

[nvdaes]

I think that the id of the add-on selected on the add-ons list should be shown in the panel of other details, to avoid ambiguities if two display names are equal.

[nvdaes]

STR:

1. Open the store.
2. Request to remove an add-on.
3. Close the store.
4. When NVDA request to be restarted, say No.
5. Open the store.

Actual: ERROR - gui.settingsDialogs.new (05:46:03.883) - MainThread (2352):
Opening new settings dialog while instance still exists: <gui._addonStoreGui.controls.storeDialog.AddonStoreDialog object at 0x0C8B7440>

[nvdaes]

No. I commented here thinking that maybe two related issues, not sure.

STR:

1. Open the store and don't close it.
2. Open the store again.

[seanbudd]

huh that must be a recent regression. Thanks.

[XLTechie]

@seanbudd here's a log, with add-ons disabled, showing what @nvdaes described.

It also shows various other recurring errors, tracebacks, and odd behaviors.

[XLTechie]

@seanbudd do you want a separate issue for this?

[seanbudd]

@XLTechie - either way is fine, we plan on resolving bugs that were reported in this discussion where possible

[seanbudd]

@Qchristensen what do you think about moving the add-ons store to its own section? We can link to it from the current tools header.

[seanbudd]

After discussions, we support moving it out to it's own section. I would encourage keeping the tools submenu header and linking to the new section from it.

[XLTechie]

Merged in #14971.

[seanbudd]

We can add a new block action context for add-ons being disabled

[XLTechie]

That would be un-ideal.

STR:

1. Install an add-on which has a bug.
2. NVDA fails to start, crashes after start, or otherwise blows up.
3. Start with add-ons disabled in order to differentially disable each add-on to find the broken one, or to just remove the broken one because we know what it is.
4. Store is disabled, add-on functions are missing, catch-22 ensues.

I think the store, while add-ons are globally disabled:

1. Needs to show what is installed.
2. Minimally, needs to allow removal.
3. Preferably, should allow manual enable/disable that will be effective on the next normal restart. I believe the Add-on Manager did that. It allows global disable to fix problems via the bludgeon approach, then disable all, restart, then selectively enable one by one, to determine which is causing strange behavior.

Without (3), most of the usual approaches for debugging add-on related conflicts or bad interactions, or straight up bugs, will be invalidated.
Without (2), all of them will be.

[seanbudd]

This has been addressed in #14967

[seanbudd]

These have been removed, instead a combo box for sorting should be created

[XLTechie]

@seanbudd I have run into a situation that I can't replicate, but in which no add-on data was fetched, or so the log claims.

I was playing with version pr13985-28305,cdb226f8, having restarted with add-ons disabled for my earlier test.

When I restarted normally, I could see the installed add-ons, but when I tried to list available add-ons, I got an empty list, and this in the log:

Exception in thread getAddonData:
Traceback (most recent call last):
  File "threading.pyc", line 926, in _bootstrap_inner
  File "threading.pyc", line 870, in run
  File "gui\_addonStoreGui\viewModels\store.pyc", line 389, in _getAvailableAddonsInBG
  File "gui\_addonStoreGui\viewModels\addonList.pyc", line 198, in resetListItems
  File "gui\_addonStoreGui\viewModels\addonList.pyc", line 353, in _updateAddonListing
  File "gui\_addonStoreGui\viewModels\addonList.pyc", line 306, in _getFilteredSortedIds
  File "gui\_addonStoreGui\viewModels\addonList.pyc", line 290, in _getSortFieldData
  File "gui\_addonStoreGui\viewModels\addonList.pyc", line 229, in _getAddonFieldText
AttributeError: 'NoneType' object has no attribute 'version'

Here's the full log. I was unable to replicate this, but I didn't go through and try keystroke for keystroke, to attempt the various sort changes I did in both store windows.

[cary-rowen]

We may have to disable or enable certain add-ons one by one when troubleshooting issues caused by add-ons.
So, can we support multiple selection or inverse selection in the list of the add-on store?
There is also a specific use case that is common: when the add-on store has been integrated into NVDA core, a user installing NVDA for the first time may choose to install multiple add-ons from the add-on store. It would also be nice to support batch operations.

[wmhn1872265132]

In some cases, multiple Add-ons may be updated at the same time. At this time, if you can select and update in batches, many repeated operations will be reduced.

[seanbudd]

Duplicate of #14912 (comment)

[Adriani90]

@seanbudd it seems the lists in the addon store do not support scroling with ctrl+home or ctrl+end to reach the beginning or the end of the list. I was browsing through the available addons, 96 addons as of now, and was wondering how to reach the beginning of the list again with the keyboard.

Also it might make sense to introduce a category label in the addons manifest and a category filter in the addon store and match the category chosen by the author with the filter, or even group addons by category in the addon store (i.e. entertainment, translation, text recognition, productivity, audio management etc.). Otherwise we will end up with a really huge list in the future and grouping them at a later stage might become very difficult.
I think ideally we could move with ctrl+left or right arrow between addon categories while focusing the list of addons, similar to how the group of settings in ribbons work in Microsoft office.

Thank you for the huge work implementing the addon store, this is really amazing.

[XLTechie]

While I think @seanbudd wants regular issues for store ideas/bugs now, I must say I fully agree with everything @Adriani90 says in this comment.

[cary-rowen]

@Adriani90 wrote:

I was browsing through the available addons, 96 addons as of now, and was wondering how to reach the beginning of the list again with the keyboard.

For me, all you need is pressing Home/End on your keyboard.