@jcsteh / @feerrenrut: Mind setting a milestone/priority for this?

This work would be to generify the current implementation so that it could easily be used to display an active nvda "background task". Please correct me if I have misunderstood.

P3 Assuming that I have understood this issue correctly.
I can see the value in this generally, however I think this could potentially be higher if we knew what this would be blocking. Are there specific preexisting issues or add-on ideas that would benefit from making this code generic?

One idea:

When the user presses donate, they have to go donate, and come back to
press done. Then they have to wait for the download. If NVDA were to
give them a reward, downloading the bundle when they are busy donating,
then the user comes back and hits done, and bang, their update starts
automatically.

On 11/11/2016 10:54 PM, Reef Turner wrote:

This work would be to generify the current implementation so that it
could easily be used to display an active nvda "background task".
Please correct me if I have misunderstood.

P3 Assuming that I have understood this issue correctly.
I can see the value in this generally, however I think this could
potentially be higher if we knew what this would be blocking. Are
there specific preexisting issues or add-on ideas that would benefit
from making this code generic?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#3504 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFGivcczw4uVmoQxaGq0OCZ_bJJ6_YVOks5q9VSEgaJpZM4Kv_Ih.

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu
Phone: (303) 906-2194

The most important issue blocked by this one is #3208. Also, a nice
to have for #4263 and #6281.

I actually wrote a branch (t3504) years ago which does most (maybe all?) of this. I can't remember why I abandoned it. I think perhaps it wasn't going to fully solve the use case I had at the time (the OCR add-on) and I didn't see any point in pursuing it further. Unfortunately, I don't remember if anything was incomplete, but a brief look suggests not. It'll probably be partial bit rot by now, though.

Hi,

The download manager should be able to download URL's it receives (not only NVDA updates, but also add-on updates as well). We should limit this to installed copies only (after all, the file in question will be stored in temp directory). In case of add-ons manager using this, see #3208. Thanks.

Hi,

Modernized to include enhancements from recent releases, including HTTPS support, file hashes and so on. Testing shows it is working as advertised by @jcsteh. Thanks.

@josephsl will this be also solved when the addon update feature come into NVDA's core? Or are you going to raise a separate PR for this?

I believe that it would allow updating addons via addonUpdater on try builds, which would be very nice to have. @josephsl Am i right? If I am maybe you can consider working on this.

Hi,

No, because Ad-on Updater is really an implementation of #3208, not this one. I also prefer to limit this to Core modules as we don't want someone writing an add-on designed to promote download of illegal content through NVDA.

Thanks.