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.

Sign up for GitHub

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

Jump to bottom

Add-Ons Manager: Generating a List of Installed Add-ons and their states #14613

Open
britechguy opened this issue Feb 6, 2023 · 15 comments
Open

Add-Ons Manager: Generating a List of Installed Add-ons and their states #14613

britechguy opened this issue Feb 6, 2023 · 15 comments
Labels
triaged Has been triaged, issue is waiting for implementation.

Comments

@britechguy
Copy link

Is your feature request related to a problem? Please describe.

No

Describe the solution you'd like

Very often the question arises regarding what add-ons a given user has installed, and whether those are enabled or disabled. There is no automated way to have Add-On manager generate this, and doing it by hand gets very tedious, and error-prone. Adding a button to generate such a list in a plain text file should be added.

Describe alternatives you've considered

None.

Additional context

This would be really handy to have for debugging purposes or discussions between NVDA users where it's suspected that an add-on might be causing behavioral differences.
@amirmahdifard
Copy link

there is really not much point of doing this, in the addon manager dialog, you can see the status of addon if you focus on it.

@britechguy
Copy link
Author

Actually, yes, there is, or I wouldn't have requested it. I need to know (or supply) a list of ALL the add-ons I have installed, and whether or not they're active, when engaged in technical support or debugging. I've needed to send, or receive, same on many occasions.

Creating them by hand, when it should be, "hit a button and a text file gets generated," since this is the information the Add-On manager presents is really tedious, and ridiculous.

If it were only for a single add-on, what you say would be true. But in debug/support situations you often need to have the full view of all add-ons that are installed, their versions, and their states (enabled/disabled).

@CyrilleB79
Copy link
Collaborator

This is a totally valid request IMO with a clear use case.

Note that there is already a workaround to get an automated way to get the info regarding add-ons; you need to ask for a log at DEBUG mode and look at NVDA initialization. However, parsing the log is also tedious and having the add-on information (name, version and enabled/disabled state) in a synthetic way would really be a plus.

Side note: @britechguy, your feature request is clearly meant to respond to a problem, i.e. asking installed add-on information for support. You could have split your description with the first half in the first paragraph.

@Brian1Gaff
Copy link

Brian1Gaff commented Feb 7, 2023 via email

@CyrilleB79
Copy link
Collaborator

As another workaround, you may ask to open the Python console, copy/paste the following line:
import addonHandler;print('\n'.join(f"{a.name} - {a.version} - {a.manifest['author']}" for a in addonHandler.getRunningAddons()))
and copy the result seen in the console output.

Or better copy/past this line in the Python console:
import addonHandler;api.copyToClip('\n'.join(f"{a.name} - {a.version} - {a.manifest['author']}" for a in addonHandler.getRunningAddons()))
And you'll get the add-on list directly in your clipboard, ready to be pasted somewhere.

These two commands only list the currently running add-on, i.e. those who have an effect during the current run of NVDA. It include add-ons pending for disable or pending for removal, but it does not include add-ons pending for install, pending for enable or incompatible.

@josephsl
Copy link
Collaborator

josephsl commented Feb 7, 2023

Hi,

Note: this is similar to #11240 but raised after a use case was found, specifically confusion over feature source. There has been a discussion on the NVDA users list about potential workarounds, the one most suggested being looking at add-ons table from add-ons manager. This works on the local system, but imagine a remote or a tech support scenario where the developer and/or the tech support personnel may wish to get a better idea of the situation and try to isolate issues with add-ons by looking at add-ons data in a concise, compact way.

I think a compromise would be to do what Reef suggested in #11240: a debug command where info about NVDA's installation (with add-ons data added) would be copied to the clipboard for diagnosis provided that users are aware of privacy implications. I think it would be best to do it not as a command but a Python Console method to communicate to the public that this should be done when instructed by a developer or a tech support personnel, similar to the method used to prepare to generate crash dumps when NVDA freezes while using apps. Alternatively, a button could be added to NVDA's about dialog to generate diagnostic data, similar in concept to recent Windows releases where one can copy system information from Settings/System/About (Windows+Pause). These two methods helps NVDA keep screen reading front and center while giving folks a possibility to review diagnostic information when requested (after all, one of the highest priorities of NVDA is making sure users can access screen information in an efficient, effective, and user-friendly way; add-ons are important to the ecosystem, but when it comes to the mission of NVDA project, screen reading is on the highest priority list).

Thanks.

@britechguy
Copy link
Author

Side note: @britechguy, your feature request is clearly meant to respond to a problem, i.e. asking installed add-on information for support. You could have split your description with the first half in the first paragraph.

Cyrille, I guess some of this comes from my own time as a developer on other software projects. "Problem"/"bug" was synonymous. If the ticket was not to address an active bug, it was a "feature request" and there was no "problem" to address.

But in light of all of the conversation, I have to say that you need to understand that this request comes from me, a sophisticated NVDA user, who frequently offers support to others. There are many more like me. I don't want to have to read debug logs nor have a user generate same for something like this. On my own machine, I can open the Add-Ons Manager and see, in tabular format, precisely what it is that I'm asking for. The information is already collected, and presented, but it's locked in Add-Ons manager. If someone has, say, 15 add-ons, and that's not unrealistic, hand compiling that information is extremely tedious. Assistants often ask the same thing that gets asked in the suggested NVDA bug report steps, one of which is starting NVDA with add-ons disabled, to see if it's an add-on that's causing whatever may be. But then it comes down to figuring out which one.

I take an approach not unlike the "clean boot" technique for Windows where you then enable half, see if the issue comes back, then if it doesn't enable the other half. This process is repeated, paring each half in half until you zero in on the one and only (add-on in NVDA's case) process that is the culprit.

There are things that assistants who are trying to help users, who are not a part of the NVDA development team, have every right to ask for and which also make abundant sense. I know that the answer may not end up being, "Sure," but I also know that it is entirely wrong for anyone to claim that there is not a valid use case for this function. Many assistants are not able to read a debug log, and I can assure you that many NVDA issues with add-ons end up being cured, via the manual version of "search and destroy" for a problematic add-on, that will never make it on to the NVDA radar screen in GitHub. Anything that makes it easier for self-helpers to accomplish this should be considered a major plus and given due consideration for inclusion in a later NVDA update.

@michaelDCurran michaelDCurran added the triaged Has been triaged, issue is waiting for implementation. label Feb 9, 2023
@michaelDCurran
Copy link
Member

Clearly there will be a positive impact for some, and I doubt that adding an extra button to the add-ons manager would cause a negative impact for those who never use it, as long as it is clearly labeled and explained in the user guide.
I'm in support.

@marrie
Copy link

marrie commented Feb 10, 2023

I'm 100 percent in support for this, I'm a 1 button kind of person when needed and since I have about 15 or so add ons I use almost on a daily basis, I would also love to see this, maybe located under settings and not easilygotten to so as not to confuse the newbie user.

@britechguy
Copy link
Author

I would also love to see this, maybe located under settings and not easilygotten to so as not to confuse the newbie user.

If this were to come into existence, I really want it to be a button that's a part of add-ons manager. This is a case where tightly binding a feature to the existing interface that handles add-ons is key. Were the button to read, "Generate Add-Ons List," and do just that, even if a newbie user were to activate it, there's nothing done that is damaging in any way. I presume that a Save dialog would be presented and if they didn't intend to do this they'd just hit the Cancel button, as is pretty standard practice under Windows in general.

@marrie
Copy link

marrie commented Feb 10, 2023 via email

@rperez030
Copy link

rperez030 commented Feb 10, 2023 via email

@josephsl
Copy link
Collaborator

josephsl commented Feb 10, 2023 via email

@britechguy
Copy link
Author

I have no objection to an implementation that places same on the clipboard. The only reason I suggested a file is that, for myself, I'll virtually always be pasting that information into something, and if it's for me, that would be a file. But since this information could be being sent to an assistant, being able to paste into an email message is useful, too.

The big goal is not having the user have to compile such a list to share by hand.

@rperez030
Copy link

rperez030 commented Feb 10, 2023 via email

@XLTechie XLTechie mentioned this issue Apr 24, 2023
Merged
6 tasks
@britechguy britechguy mentioned this issue May 21, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
triaged Has been triaged, issue is waiting for implementation.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@marrie @josephsl @michaelDCurran @Brian1Gaff @CyrilleB79 @britechguy @rperez030 @amirmahdifard