Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add-on store #13985

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
Open

Add-on store #13985

wants to merge 8 commits into from

Conversation

feerrenrut
Copy link
Member

@feerrenrut feerrenrut commented Aug 4, 2022

This is intended to act as a base for "stacked pull requests" to build up this feature until it is considered ready to merge into NVDA.

Link to issue number:

#3208

Summary of the issue:

Historically, NVDA users have had to browse websites or use add-ons, not directly run/developed by NV Access, in order to learn about, download, and install add-ons. For a long time, easier manual updates for add-ons, and automatic updates for add-ons has been desired by NVDA users. Additionally, with the more common and structured approach to add-on API compatibility breaks, lowering the friction for delivery of updated (and compatible) add-ons is more important than ever.

User stories enabled by this work:

  • As an NVDA user, I want to easily browse add-ons which are compatible with my version of NVDA, to learn if they may fulfill an unmeet user need.
  • As an NVDA user, I want to be able to install compatible NVDA add-ons that I have determined will fulfill an unmet user need.

Additionally, this work unblocks the following user stories which may yet be incorporated into this PR:

  • As an NVDA user, I want to be able to browse the add-on catalog while offline, I understand I will not be able to install add-ons.
  • As an NVDA user, I want to be able to manually check if there are any updates available for add-ons I have installed, so that I know if there are newer versions available.
  • As an NVDA user, I want to be notified when there are updates to add-ons I have installed, so that I can manually update the add-ons when I am ready to do so.
  • As an NVDA user, I want NVDA to automatically keep add-ons up to date with the latest version available.
  • When NVDA notifies of an update (to NVDA), I want to be able to check the compatibility status of the add-ons I have installed, so that I can determine whether the NVDA update will break my core requirements.

Description of how this pull request fixes the issue:

A new dialog is introduced (NVDA menu, tools, addon store) which shows the latest compatible versions of add-ons (submitted to the add-on store).

  • Filter by text field, allowing filtering Add-ons by phrases that appear in any field.
  • List of "available add-ons" with columns:
    • Name, Version, Publisher, Status
    • Status indicates: available, downloading, downloaded etc.
    • The application key (context menu) will present a menu with the actions available for the currently selected add-on. Currently only "install".
  • Read-only edit "description", containing the description of the add-on provided by the author.
  • Action buttons for the addon, currently only "Install".
  • Read-only edit "details", containing extended details for the add-on
    • Publisher, Version, Channel, Homepage (link), License (link), Source Code (link)

Installation:

  • When installing an add-on, the add-on is downloaded in the background.
  • The user is able to continue browsing add-ons, and even queue further add-ons for download / installation.
  • When the user attempts to exit the add-on store, the add-ons are installed and the user is prompted to restart NVDA.
  • If the user attempts to exit the add-on store before the add-ons have completed downloading, the user is told how many add-ons are still downloading and asked if they wish to cancel the download of those add-ons. If they choose to cancel the still in progress downloads any add-ons that have already been downloaded are installed.

An image of the add-on store dialog:
image

Testing strategy:

This system is designed to make replicating unusual occurrences easy for developers, strategies that are helpful:

  • Update the timestamp in a cached "available addons" json file to within 6 hours of current time. It will be used instead of fetching fresh data from the Add-on store API. This allows for testing variations of data provided by the API, including add-on versions that it shouldn't supply.
  • Use a simple python http server to supply add-on files hosted locally, this server can be accessed through a local proxy tool (E.G. Clumsy) to replicate varying network conditions. Ensure to update the download URL in the cached "available addons" json file to do so.
  • Modify the manifests of the *.nvda-addon files being supplied to replicate various outcomes.

Many edge cases have been tested this way, however we will be relying on real world usage from alpha users to find edge cases we haven't yet considered.

Known issues with pull request:

  • Versions of NVDA that have not been added to nvdaAPIVersions.json will not be able to query the API.
    • Until this is resolved, work around the issue for testing purposes by overriding currentVersion in _getCurrentApiVersionForURL (source/addonStore/dataManager.py) to (2022, 2, 0)
    • Further explanation on how to override the value.
  • Currently the add-on store dialog can only be used for browsing and installing add-ons.
    • Manual and automatic update is planned.
    • We intend to integrate all functionality from the add-on manager, eventually removing the add-on manager dialog.
    • It will continue to be possible to "side-load" add-ons.
  • Installed add-ons are not yet shown in the add-on store. However, once installed they are no longer listed unless the latest version available (of the add-on) has changed.
  • There is no support for "dev" add-ons (distributing pre-stable add-ons, targeting a future version of NVDA)
  • Currently shows all add-ons. There is no way to select only stable / beta / all.
    • There are plans to address this with a new configuration panel for the add-on store.
  • There are 'ok' / 'cancel' buttons, despite no difference in behavior. A single button "done" is more appropriate.
  • Pressing enter on a add-on list item should open the context menu, where actions for that add-on are found.
  • Pressing enter on a link (in the details) should open the URL.
  • The user experience could be improved if add-ons were installed (and the add-on install task ran) when NVDA next restarts. However there is a risk this may break assumptions by add-on authors, so will considered a compatibility breaking change. This will be scheduled for the next compat breaking release.
  • User documentation is still missing for this change, due to evolving state of the UI it will be written when the approaching the final stages of the feature.

Change log entries:

New features

An add-on store has been introduced into NVDA.
  - This allows browsing / searching for community add-ons.
  - Installing add-ons

Code Review Checklist:

  • Pull Request description:
    • description is up to date
    • change log entries
  • Testing:
    • Unit tests
    • System (end to end) tests
    • Manual testing
  • API is compatible with existing add-ons.
  • Documentation:
    • User Documentation
    • Developer / Technical Documentation
    • Context sensitive help for GUI changes
  • UX of all users considered:
    • Speech
    • Braille
    • Low Vision
    • Different web browsers
    • Localization in other languages / culture than English

feerrenrut added 5 commits Aug 4, 2022
Initial design for addon store.

- A new dialog ("add-on store") can be launched from the 'tools' menu.
- Data is pulled from the live Add-on API and shown in the Dialog.
- The dialog presents a filterable sortable list with basic add-on data.
- An add-on can be selected and its description / further details are presented.
- When filtering, care is taken to preserve the selection.

Known issues:
- The current version of NVDA (alpha 2022.2) is not known to the add-on store yet.
- Fetching add-on listings for it produces a 400 error. This could be resolved with Allow 'dev' version of add-on addon-datastore#40
- The first time the dialog is opened, there is a noticeable delay, the dialog creation is blocked by downloading the add-on data. This is then cached in memory, there is no way to refresh the data, NVDA must be restarted. Will be resolved in a future commit.
- The list currently shows all add-ons. There is no way to select between stable / beta / all. Planned for resolution.
- Due to inheriting from SettingsDialog (for other functionality, such as single instance etc) there are ok / cancel buttons. A single button "done" may be more appropriate.
- In order to be able to test the NVDA add-on store implementation locally,
developers must be able to provide test data for the store.
- The add-on store is fetching data from the server every time it is opened,
this may overload the server.
- There was a delay when opening the add-on store

Description of change:
Introduce a (json) file cache, which includes:
- the string (data) returned by the API
- the datetime when the data was fetched (stored as an ISO date time string)

With this cache file:
- Testing can be achieved by overriding the cached data.
- Data is cached every 6 hours.
- The cache can be used (almost) instantly.

Testing strategy:
- Ran NVDA without an internet connection. Led to ConnectionError.
- Ran NVDA with a version that returns no data. Cache is used instead.
- Ensured that when the cache has a time stamp less than 6 hour old there is no delay to use it.
- Ensured that the cache can be modified locally, the change is reflected in the GUI.
- When the cache is older than 6 hours, there is a short delay before data is populated into the GUI.

Known issues:
- The cache does not include the NVDA version that was used when fetching. This may mean that an invalid cache could be used for up to 6 hours after updating NVDA.
- When the cache is older than 6 hours, there is a short delay before data is populated into the GUI.
- The add-on store needs a way to allow installation.
- The actions should happen in the background, steps like downloading may take significant time.
- Progress should be discoverable.

Description of change:
- Introduces a way to associate actions with the GUI.
- To cater to power users a context menu has been added to list items (available add-ons)
- To ensure discoverability, buttons for actions are added to the details.

Note
There is currently an "update" action, which only logs.
It is included just as a demonstration / proof of concept.

There are many rough edges in this implementation, but since this is already a sizable change,
and many further changes are more likely to self contained it is a good checkpoint.

Testing strategy:
- Used the links in the add-on store data to download several *.nvda-addon files
- The manifests were modified (in various ways) to create different installation outcomes.
- The python "simpleHttpServer" module was used to srt.
- The links to the URL for add-ons in the cached addon-store file were pointed to localhost.
- Used 'Clumsy' tool to simulate slow connections, adding latency to the
  download process.

Known issues:
These will be worked on separately:

- The status of installed add-ons isn't reflected in the list, installed
add-ons with a matching version should be omitte". There is a problem
here, an add-on manifest does not include a numerical version, only a
version name string. Ordering based on version number with the add-on
store will not be possible for side-loaded add-ons.
- Pressing enter on an addon should open the context menu.
- Pressing enter on a link (in the details) should open the URL
- When closing the dialog (after inste blocked by add-ons being installed
(consider NVDA exit / os shutdown), and progress shown.
- Task management required for download / install steps. Install steps for
multiple add-ons should be serialized. Download can happen in parallel.
- Ok / Cancel should be eplaced wih a 'Done' button
- Add-ons optionally have an install_task which runs post installation, prior
to restart. This can be disruptive when installing multiple add-ons from the
store. Consider making this occur post restart.
- When an addon was already installed (matching ID and version) it should not have been listed as available (to download)
- When the addon was installed, but there is a newer version available, it should not have been listed as "update available".
- When the addon isn't compatible, the status column should say so. This shouldn't occur if the add-on submission process works correctly, however, to catch bugs with that system it is worth showing.

- Adds typing and deeper docs to the addonHandler and addonVersioning. This needs to be understood for the version / name / id comparisons with addonStore data.
- Set status of add-ons to "installed" / "enabled" / "disabled" / "update available" / "incompatible"
- Don't show add-ons that are "enabled" (I.E. Installed and running).
- Don't show add-ons that are "disabled"
- Check for compatibility, show incompatible as status.

- Used the links in the add-on store data to download several *.nvda-addon files
- The manifests were modified (in various ways) to create different installation outcomes.
- The python "simpleHttpServer" module was used to serve the add-ons.
- The links to the URL for add-ons in the cached addon-store file were pointed to localhost.
- Used 'Clumsy' tool to simulate slow connections, adding latency to the
  download process.
- Modified the cached addon-store file to test different add-on versions being available (to test updates available)
- Installed an add-on to ensure that they aren't listed when "running".
- Disabled add-on to ensure that they aren't listed when "disabled".
- Modified the addon-store file to test showing addon compatibility in status.

- Does not properly handle add-on updates (from the store). The numerical version information from the add-on needs to be stored somewhere. Information for side loaded add-ons will be shown as "update available" if the version doesn't match, even if the add-on store version is older.
Installing add-ons must happen on the main thread. They must be installed one by one.
Downloads may happen concurrently, moving off the main thread allows NVDA to stay responsive.

Description of change:
Use a ThreadPoolExecutor to enable downloading in the background.
This will allow scaling up the number of threads as required.
Provided an abstraction to make cancellation/tracking of complete simpler.
Addons are installed (if download has completed) when the user tries to exit the dialog.
@feerrenrut feerrenrut requested a review from a team as a code owner Aug 4, 2022
@feerrenrut feerrenrut requested a review from seanbudd (assigned from nvaccess/developers) Aug 4, 2022
@CyrilleB79
Copy link
Contributor

CyrilleB79 commented Aug 4, 2022

It's a very good news to see this topic arrive in NVDA's repo!

The PR is not in draft. Is it already testable?

I get the following error:

ERROR - external:addonStore.dataManager.DataManager._getLatestAvailableAddonsData (11:25:34.047) - getAddonData (13724):
Unable to get data from API (https://nvaccess.org/addonStore/en/all/2022.4.0.json), response (400): b'Addon API version not available'
ERROR - stderr (11:25:34.104) - getAddonData (13724):
Exception in thread getAddonData:
Traceback (most recent call last):
  File "C:\Users\Cyrille\AppData\Local\Programs\Python\Python37-32\lib\threading.py", line 926, in _bootstrap_inner
    self.run()
  File "C:\Users\Cyrille\AppData\Local\Programs\Python\Python37-32\lib\threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Users\Cyrille\Documents\DevP\GIT\nvda\source\gui\addonStoreGui\viewModels.py", line 569, in _getAddonsInBG
    addons = self._dataManager.getLatestAvailableAddons()
  File "C:\Users\Cyrille\Documents\DevP\GIT\nvda\source\addonStore\dataManager.py", line 222, in getLatestAvailableAddons
    return self._availableAddonCache.availableAddons
AttributeError: 'NoneType' object has no attribute 'availableAddons'

@feerrenrut
Copy link
Member Author

feerrenrut commented Aug 4, 2022

@CyrilleB79 theoretically it should be testable.

However, I had previously been testing it before the NVDA version change, and with a prior datastore cache this error doesn't cause a major issue. I'll look into improving the robustness in this case.

There is a known issue to allow support for "in development" NVDA versions on the API side.

For testing purposes, you can safely override currentVersion in _getCurrentApiVersionForURL (source/addonStore/dataManager.py):

def _getCurrentApiVersionForURL() -> str:
	#currentVersion = addonAPIVersion.CURRENT
	currentVersion = (2022, 2, 0)

@AppVeyorBot

This comment was marked as outdated.

@CyrilleB79

This comment has been hidden.

@feerrenrut

This comment has been hidden.

@josephsl

This comment has been hidden.

@nvdaes

This comment has been hidden.

@feerrenrut
Copy link
Member Author

feerrenrut commented Aug 5, 2022

Thanks for the feedback.

@josephsl

Updating add-ons (in the future): at least the PR recognizes when updates are available. Would it be possible to present current installed version somewhere so users can compare current versus update version, similar to Add-on Updater implementation?

Our next phase will be looking at the updating use-cases more carefully. Hopefully this will address these concerns.

Also, I don't know if it is me, but when downloading add-ons, some kind of a dialog is briefly shown.

Can you get me a log or some information about the dialog? I haven't noticed this, and don't know what it could be.

@nvdaes

I'd like that Install button has a shortcut, and even that multiple add-ons can be selected, for example with a list of checkboxes.

Note you can access "actions" for the selected add-on via the application/context menu. I intend to open this menu with the enter key is press while an add-on is selected. This is still a todo item. When we are confident about the full list of actions we can also add in accelerator keys.

When the install button is pressed, it would be nice if the add-ons list was focused instead of further details.

Is the concern about how long it takes to get back to the list, perhaps an accelerator key (for the list) would be sufficient?

Some add-ons perform onInstall tasks, and the add-on name maybe presented in this cases, or this may be documented so that authors mention it explicitly. For example, clipContentsDesigner and reportPasswords.

Yes, this is a concern. It isn't always obvious which add-on is presenting a dialog. We intent to move the install tasks running to after NVDA is restarted, which will make this worse. This might resolve itself through add-on updates. Let's give it some time, if the problem still exists when we get to that stage we can look into providing more information about which add-on install is completing.

Copy link
Collaborator

@leonardder leonardder left a comment

Great to see this flying!

source/addonStore/dataManager.py Show resolved Hide resolved
source/addonStore/dataManager.py Outdated Show resolved Hide resolved
source/gui/addonStoreGui/viewModels.py Show resolved Hide resolved
source/gui/addonStoreGui/views.py Show resolved Hide resolved
@josephsl

This comment has been hidden.

@nvdaes

This comment has been hidden.

@nvdaes
Copy link
Sponsor Contributor

nvdaes commented Aug 5, 2022

Regarding the further details view, hyperlinks are reported but seems there's nothing to do with them, for example copy URLs or open them pressing Enter. Is this intended or a todo?



class AddonListVM:
presentedAttributes = [
Copy link
Sponsor Contributor

@nvdaes nvdaes Aug 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be a tuple, not list?

Suggested change
presentedAttributes = [
presentedAttributes = (

Copy link
Sponsor Contributor

@nvdaes nvdaes left a comment

presentedAttributes is a list. Is this needed or a tuple would be enough?

@feerrenrut
Copy link
Member Author

feerrenrut commented Aug 8, 2022

No, the list is not focused after pressing the Install button. I think it maybe related to this code:

I see, STR:

  • Tab to an add-on description
  • Tab one more time to the install button
  • Press enter

Actual:

  • install button becomes disabled
  • focus shifts to the next control: "Other details"

Expected:
Shift focus somewhere more useful.

I think It's debatable where focus should be shifted. Given this is the standard Windows behavior, I think there should be a pretty strong rational for changing it. Note that when there are other buttons in this group, focus will shift to one of those buttons.

At this stage, this is a low priority usability concern but may be worth considering further later.

return self.manifest.get('minimumNVDAVersion')

@property
def lastTestedNVDAVersion(self):
def lastTestedNVDAVersion(self) -> typing.Tuple[int, int, int]:
Copy link
Contributor

@lukaszgo1 lukaszgo1 Aug 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't you use AddonApiVersionT as a type annotation here?

@@ -766,7 +808,8 @@ def _validateApiVersionRange(self):
minRequiredVersion = self.get("minimumNVDAVersion")
return minRequiredVersion <= lastTested

def validate_apiVersionString(value):

def validate_apiVersionString(value) -> typing.Tuple[int, int, int]:
Copy link
Contributor

@lukaszgo1 lukaszgo1 Aug 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here w.r.t using AddonApiVersionT

from datetime import datetime, timedelta

from logHandler import log
import requests
Copy link
Contributor

@lukaszgo1 lukaszgo1 Aug 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Requests should be listed in our requirements file explicitly - now it is installed only because Sphinx depends on it.



def _getCurrentApiVersionForURL() -> str:
currentVersion = addonAPIVersion.CURRENT
Copy link
Contributor

@lukaszgo1 lukaszgo1 Aug 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While you've mentioned in the PR description that support for not yet released version of NVDA is not implemented on the server side at present, it would be good to know what are plans with regard to this. As I see there are two cases to consider:

  • Version of NVDA in the Alpha stage - in that case it seems reasonable to return add-ons compatible with the latest stable NVDA known by the server
  • The first version of NVDA which breaks backward compatibility - in that case the new version has to be registered on the server before the first Alpha with modified back compatibility values gets released.

@@ -328,6 +334,24 @@ def onAddonsManagerCommand(self,evt):
d.Show()
self.postPopup()

@blockAction.when(
Copy link
Contributor

@lukaszgo1 lukaszgo1 Aug 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opening add-on store should be also blocked for Windows Store versions of NVDA - unless the intent is to allow browsing available add-ons, yet disallow installation in that case.

from gui import (
guiHelper,
nvdaControls,
DpiScalingHelperMixinWithoutInit,
Copy link
Contributor

@lukaszgo1 lukaszgo1 Aug 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DpiScalingHelperMixinWithoutInit can be imported from gui only because it is star imported there from settingsDialogs. To make future refactoring easier it should be imported from dpiScalingHelper explicitly.

# Translators: The name of the column that contains the addons version string. In the add-on store dialog.
self.InsertColumn(1, pgettext("addonStore", "Version"))
# Translators: The name of the column that contains the addons publisher. In the add-on store dialog.
self.InsertColumn(2, pgettext("addonStore", "Publisher"))
Copy link
Contributor

@lukaszgo1 lukaszgo1 Aug 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently the add-on publisher is always the GitHub user name of the author. I don't know if it is a requirement, but if so there are several problems with this from the user perspective.

  1. It is inconsistent with the author field in the manifest - if this dialog is going to replace add-on manager we should make them as similar as possible.
  2. The GitHub user name provides no contact to the author for the less thech-savvy people
  3. Most other package manager I've seen (Python PIP, InTune Portal) provide much more friendly strings for the publisher.

menuItem = self._actionMenuItemMap[addonActionVM]
menuItem.Enable(enable=addonActionVM.isValid)

# noinspection PyMethodMayBeStatic
Copy link
Contributor

@lukaszgo1 lukaszgo1 Aug 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any particular reason for suppressing the warning rather than making the method static as suggested - as far as I can tell this should work as well as in the current design?

# move passed last character of the label string.
iTextRange2_disp.moveEnd(comInterfaces.tom.tomCharacter, 1)
iTextRange2_disp.collapse(comInterfaces.tom.tomEnd)
iTextRange2_disp.text = linkText
Copy link
Contributor

@lukaszgo1 lukaszgo1 Aug 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code fails for me at this point with the following error:

ERROR - extensionPoints.Action.notify (22:50:35.383) - MainThread (7208):
Error running handler <bound method AddonDetails._updatedListItem of <gui.addonStoreGui.views.AddonDetails object at 0x0D7A8AD0>> for <extensionPoints.Action object at 0x0D7AEAB0>
Traceback (most recent call last):
  File "D:\my_repos\nvda\.venv\lib\site-packages\comtypes\client\lazybind.py", line 123, in __bind
    return self._tdesc[(name, invkind)]
KeyError: ('url', 4)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "extensionPoints\__init__.py", line 47, in notify
    callWithSupportedKwargs(handler, **kwargs)
  File "extensionPoints\util.py", line 170, in callWithSupportedKwargs
    return func(*boundArguments.args, **boundArguments.kwargs)
  File "gui\addonStoreGui\views.py", line 377, in _updatedListItem
    self._refresh()
  File "gui\addonStoreGui\views.py", line 439, in _refresh
    urlFunc()
  File "gui\addonStoreGui\views.py", line 463, in <lambda>
    lambda: _insertLinkForLabelWithTomViaComIDispatch(detailsTextCtrl, label, value, URL)
  File "gui\addonStoreGui\views.py", line 229, in _insertLinkForLabelWithTomViaComIDispatch
    iTextRange2_disp.url = f'"{url}"'
  File "D:\my_repos\nvda\.venv\lib\site-packages\comtypes\client\lazybind.py", line 209, in __setattr__
    put = self.__bind(name, DISPATCH_PROPERTYPUT)
  File "D:\my_repos\nvda\.venv\lib\site-packages\comtypes\client\lazybind.py", line 126, in __bind
    descr = self._tcomp.Bind(name, invkind)[1]
  File "D:\my_repos\nvda\.venv\lib\site-packages\comtypes\typeinfo.py", line 366, in Bind
    raise NameError("Name %s not found" % name)
NameError: Name url not found

That occurs because ITextRange2 is not available before Windows 8.
It appears to be possible to insert various objects such as links to the controls using older ITextRange, however the procedure looks pretty involved.

)
self.contents.Add(self.otherDetailsLabel, flag=wx.EXPAND)
self.otherDetailsLabel.Show(False)
self.otherDetailsTextCtrl = wx.TextCtrl(
Copy link
Contributor

@lukaszgo1 lukaszgo1 Aug 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like using the wx.TextCtrl is causing several issues:

  1. Failure to create links under Windows 7 as described above.
  2. Links cannot be easily activated as mentioned in the known issues of the PR
  3. The presentations of links in speech is pretty strange (there are some silent symbols before it when navigating character by character, and the url of the link seems to be reported twice).

Given these issues has it been considered to use either wx.html.HtmlWindow or wx.html2.WebView?
These would be standard virtual buffers, with known working behavior for links activation and presentation. They behavior would also don't depend on the version of Windows in use, and styling should be significantly easier when done with CSS.
The only slight issue seems to be accessibility of these web views when focusing, but the work around in this SO question should help.

@lukaszgo1
Copy link
Contributor

lukaszgo1 commented Aug 14, 2022

@feerrenrut From the discussion on the PR it seems you're planning to make the install tasks execute after NVDA is restarted, rather than, as it is now, during the add-on install. This is going to make most usages of install tasks pretty difficult and make them much less useful. I don't want to go into specific examples here to avoid getting off topic, and also because you gave no reasoning for the change, so it is hard to discuss pros and cons. Could you create a separate issue / discussion outlining what, exactly, you intend to modify and why, so that add-on and core developers can be informed in advance and check if this is going to meet their needs?

@seanbudd seanbudd changed the title Addon store Add-on store Aug 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants