Date   
Errors in alpha when using Outlook 365

Andy B.
 

Hi,

 

I get the following errors when opening Outlook 365.

 

ERROR - RPC process 3724 (nvda_slave.exe) (07:21:40.151):

__main__.main:

slave error

Traceback (most recent call last):

  File "nvda_slave.pyw", line 91, in main

  File "comHelper.pyc", line 22, in _lresultFromGetActiveObject

  File "comtypes\client\__init__.pyc", line 180, in GetActiveObject

  File "comtypes\__init__.pyc", line 1245, in GetActiveObject

  File "_ctypes/callproc.c", line 933, in GetResult

OSError: [WinError -2147221021] Operation unavailable

 

 

Add-on Updater 19.08 released, first of two mandatory updates for everyone #addonrelease

 

Hi everyone,

 

Add-on Updater 19.08 is now available. This is the first of two mandatory updates for anyone using Add-on Updater.

 

Specifically:

 

  • Version 19.08 removes an experimental feature to present a toast message on Windows 10 when new add-on updates become available. Although this is useful, it was found that it isn’t ready for primetime yet (thanks for community feedback). Because this experiment was controlled by a setting, version 19.08 removes this, hence this being a mandatory update.
  • Version 19.08 includes a possible fix for download time-out. Specifically, if you respond to update notification more than five minutes of it appearing, you may get an error in regards to update download. This has been corrected, along with a new way of accessing the add-ons website to retrieve update status information for various add-ons.

 

The following describes Add-on Updater releases for the next few weeks:

 

  • 19.08 (released today): supports NVDA 2019.1, first mandatory update.
  • 19.08.1: to be released shortly after NVDA 2019.2 is released. The only change will be minimum NVDA version supported – 2019.2. This is not a mandatory update.
  • 19.09 (anniversary update): to be released later in August (or by early September at the latest), second mandatory update for everyone and requiring NVDA 2019.2 or later. By then, if the time-out bug is resolved, it’ll become a permanent feature of this add-on.

 

Cheers,

Joseph

Re: Joseph Lee's add-ons: alpha builds of strictly Python 3 versions of some add-ons to make their debut soon

 

Hi,
The "install bit" referred to any scenario where you install the Python 3
add-ons on top of an existing one, so it covers both installed and portable
copies.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail
list account via Groups.Io
Sent: Wednesday, August 7, 2019 3:27 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Joseph Lee's add-ons: alpha builds of strictly
Python 3 versions of some add-ons to make their debut soon

However I'm assuming there is not any reason why one cannot have a portable
version running from the previous stable in which case it will have the
older add on, as You say the older ones will not install and vice versa, I
assume.

I'm still playing with the extended winamp to see if I can get it to work in
python 2 after making it python 3. I know I'm thick!
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 07, 2019 12:43 AM
Subject: [nvda-devel] Joseph Lee's add-ons: alpha builds of strictly Python
3 versions of some add-ons to make their debut soon


Hi everyone,



Although most of my add-ons (except one or two) are Python 2 and 3
compatible, I hinted that there are some that are strictly Python 3
compatible - that is, requiring NVDA 2019.3 (alpha form at the
moment). A few days ago I hinted that I'll be releasing thee "strictly
Python 3"
add-ons in August, and yes, they will make their debut very soon in
the form of alpha add-on snapshots, shortly after NVDA 2019.2 stable
is released.



The following add-ons do have a Python 3 strict version:



* Add-on Updater
* Resource Monitor
* StationPlaylist



In addition, the following add-ons will participate in testing due to
use of wxPython 4 (phoenix):



* Golden Cursor
* SystrayList



Note: although there is a Python 3 branch for Add-on Updater, this add-on
will not participate in this test.



A few things to note about these add-ons (especially for ones that are
strictly Python 3):



1. All of them will require NVDA 2019.3 alpha in order for them to even
install.
2. Upcoming alpha snapshots of these add-ons will not receive updates
via Add-on Updater - you will need to install updates manually. For the
time
being, alpha builds for these add-ons will be hosted on my website (links
will be provided once the snapshots go live).
3. If you happen to be using StationPlaylist, after installing Python 3
snapshot, there is no going back; attempting to do so will result in
certain
features not working properly. This is due to use of pickle module.
4. In case bugs are found, please provide steps to reproduce. Once I
can verify them and tested with current stable releases, I'll incorporate
changes to either the Python 3 version or the stable release if they are
strictly due to Python 3 or reproducible in stable releases, respectively.
5. Shortly after NVDA 2019.3 beta is released, some add-ons will show
up on development channel so they can be tested widely. These add-ons will
then become eligible for update checks via Add-on Updater if told to check
for development releases. Again, for some add-ons, after installing these
snapshots, there is no going back.
6. Shortly after NVDA 2019.3 stable version is released, some add-ons
will switch the stable channel to Python 3 version. In 2020, all add-ons
from me will be powered by Python 3. As I noted earlier, I'll announce
when
this will happen shortly before then.



Special note on Add-on Updater: the policy for this add-on is to support
the
latest stable release of NVDA because the add-on itself is destined for
NVDA
Core as a pull request. However, I know that some may wish to delay
updating
to NVDA 2019.3 stable (later this year) due to add-ons they love which are
not Python 3 ready (hence the call to the community to port add-ons).
Therefore, if you are using this add-on, I will give you some more weeks
to
migrate to NVDA 2019.3, thus Add-on Updater will be the last add-on to
switch to Python 3 fully. I'll announce the transition date for this
add-on
shortly after NVDA 2019.3 release candidate (RC) is released.



Cheers,

Joseph




Re: Joseph Lee's add-ons: alpha builds of strictly Python 3 versions of some add-ons to make their debut soon

Brian's Mail list account
 

However I'm assuming there is not any reason why one cannot have a portable version running from the previous stable in which case it will have the older add on, as You say the older ones will not install and vice versa, I assume.

I'm still playing with the extended winamp to see if I can get it to work in python 2 after making it python 3. I know I'm thick!
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 07, 2019 12:43 AM
Subject: [nvda-devel] Joseph Lee's add-ons: alpha builds of strictly Python 3 versions of some add-ons to make their debut soon


Hi everyone,



Although most of my add-ons (except one or two) are Python 2 and 3
compatible, I hinted that there are some that are strictly Python 3
compatible - that is, requiring NVDA 2019.3 (alpha form at the moment). A
few days ago I hinted that I'll be releasing thee "strictly Python 3"
add-ons in August, and yes, they will make their debut very soon in the form
of alpha add-on snapshots, shortly after NVDA 2019.2 stable is released.



The following add-ons do have a Python 3 strict version:



* Add-on Updater
* Resource Monitor
* StationPlaylist



In addition, the following add-ons will participate in testing due to use of
wxPython 4 (phoenix):



* Golden Cursor
* SystrayList



Note: although there is a Python 3 branch for Add-on Updater, this add-on
will not participate in this test.



A few things to note about these add-ons (especially for ones that are
strictly Python 3):



1. All of them will require NVDA 2019.3 alpha in order for them to even
install.
2. Upcoming alpha snapshots of these add-ons will not receive updates
via Add-on Updater - you will need to install updates manually. For the time
being, alpha builds for these add-ons will be hosted on my website (links
will be provided once the snapshots go live).
3. If you happen to be using StationPlaylist, after installing Python 3
snapshot, there is no going back; attempting to do so will result in certain
features not working properly. This is due to use of pickle module.
4. In case bugs are found, please provide steps to reproduce. Once I
can verify them and tested with current stable releases, I'll incorporate
changes to either the Python 3 version or the stable release if they are
strictly due to Python 3 or reproducible in stable releases, respectively.
5. Shortly after NVDA 2019.3 beta is released, some add-ons will show
up on development channel so they can be tested widely. These add-ons will
then become eligible for update checks via Add-on Updater if told to check
for development releases. Again, for some add-ons, after installing these
snapshots, there is no going back.
6. Shortly after NVDA 2019.3 stable version is released, some add-ons
will switch the stable channel to Python 3 version. In 2020, all add-ons
from me will be powered by Python 3. As I noted earlier, I'll announce when
this will happen shortly before then.



Special note on Add-on Updater: the policy for this add-on is to support the
latest stable release of NVDA because the add-on itself is destined for NVDA
Core as a pull request. However, I know that some may wish to delay updating
to NVDA 2019.3 stable (later this year) due to add-ons they love which are
not Python 3 ready (hence the call to the community to port add-ons).
Therefore, if you are using this add-on, I will give you some more weeks to
migrate to NVDA 2019.3, thus Add-on Updater will be the last add-on to
switch to Python 3 fully. I'll announce the transition date for this add-on
shortly after NVDA 2019.3 release candidate (RC) is released.



Cheers,

Joseph



Joseph Lee's add-ons: alpha builds of strictly Python 3 versions of some add-ons to make their debut soon

 

Hi everyone,

 

Although most of my add-ons (except one or two) are Python 2 and 3 compatible, I hinted that there are some that are strictly Python 3 compatible – that is, requiring NVDA 2019.3 (alpha form at the moment). A few days ago I hinted that I’ll be releasing thee “strictly Python 3” add-ons in August, and yes, they will make their debut very soon in the form of alpha add-on snapshots, shortly after NVDA 2019.2 stable is released.

 

The following add-ons do have a Python 3 strict version:

 

  • Add-on Updater
  • Resource Monitor
  • StationPlaylist

 

In addition, the following add-ons will participate in testing due to use of wxPython 4 (phoenix):

 

  • Golden Cursor
  • SystrayList

 

Note: although there is a Python 3 branch for Add-on Updater, this add-on will not participate in this test.

 

A few things to note about these add-ons (especially for ones that are strictly Python 3):

 

  1. All of them will require NVDA 2019.3 alpha in order for them to even install.
  2. Upcoming alpha snapshots of these add-ons will not receive updates via Add-on Updater – you will need to install updates manually. For the time being, alpha builds for these add-ons will be hosted on my website (links will be provided once the snapshots go live).
  3. If you happen to be using StationPlaylist, after installing Python 3 snapshot, there is no going back; attempting to do so will result in certain features not working properly. This is due to use of pickle module.
  4. In case bugs are found, please provide steps to reproduce. Once I can verify them and tested with current stable releases, I’ll incorporate changes to either the Python 3 version or the stable release if they are strictly due to Python 3 or reproducible in stable releases, respectively.
  5. Shortly after NVDA 2019.3 beta is released, some add-ons will show up on development channel so they can be tested widely. These add-ons will then become eligible for update checks via Add-on Updater if told to check for development releases. Again, for some add-ons, after installing these snapshots, there is no going back.
  6. Shortly after NVDA 2019.3 stable version is released, some add-ons will switch the stable channel to Python 3 version. In 2020, all add-ons from me will be powered by Python 3. As I noted earlier, I’ll announce when this will happen shortly before then.

 

Special note on Add-on Updater: the policy for this add-on is to support the latest stable release of NVDA because the add-on itself is destined for NVDA Core as a pull request. However, I know that some may wish to delay updating to NVDA 2019.3 stable (later this year) due to add-ons they love which are not Python 3 ready (hence the call to the community to port add-ons). Therefore, if you are using this add-on, I will give you some more weeks to migrate to NVDA 2019.3, thus Add-on Updater will be the last add-on to switch to Python 3 fully. I’ll announce the transition date for this add-on shortly after NVDA 2019.3 release candidate (RC) is released.

 

Cheers,

Joseph

I suspect auto update is broken on alpha snaps

Brian's Mail list account
 

I have to force it to look every time, whereas other branches seem to tell me almost straight away after loading in the morning.

Could this be the case or is my experience unusual?

Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

Toolbars Explorer add on and Python 3

Brian's Mail list account
 

Hi I've been using my modified version for some days now. If Alberto is out there, then I hope its OK.

https://www.dropbox.com/s/y7i1i8siutwqpmi/toolbarsExplorer-1.2a.nvda-addon?dl=1

Obviously I am no coder but I altered the offending line as suggested for Python 3 and changed te tested on version in the manifest file.
Brian



bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

Re: Strange page error in browser

Brian's Mail list account
 

This seems totally random, today its not doing it.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Brian's Mail list account via Groups.Io" <bglists=blueyonder.co.uk@groups.io>
To: "NVDA Dev list on groups.io" <nvda-devel@groups.io>
Sent: Sunday, August 04, 2019 4:42 PM
Subject: [nvda-devel] Strange page error in browser


The log below is from the latest alpha and using Waterfox on Windows 7. It seems not to be particularly page specific, but stops say all with an error.

Speaking [LangChangeCommand ('en_GB'), 'heading level 3', 'link', 'Trimethoprim: uses, dose and side effects - NetDoctor']
IO - inputCore.InputManager.executeGesture (16:34:54.551):
Input: kb(desktop):enter
DEBUG - treeInterceptorHandler.update (16:34:54.748):
Adding new treeInterceptor to runningTable: <virtualBuffers.gecko_ia2.Gecko_ia2 object at 0x04EC4770>
DEBUG - virtualBuffers.VirtualBuffer._loadBuffer (16:34:54.749):
Buffer load took 0.001 sec, 11 chars
IO - speech.speak (16:34:54.798):
Speaking [LangChangeCommand ('en_GB'), 'about:blank busy']
IO - speech.speak (16:34:54.809):
Speaking [<speech.commands.CallbackCommand object at 0x042AD170>, LangChangeCommand ('en_GB'), 'about:blank']
IO - speech.speak (16:34:54.809):
Speaking [<speech.commands.CallbackCommand object at 0x042A30F0>]
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:34:54.950):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:34:54.960):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:34:55.145):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUG - treeInterceptorHandler.killTreeInterceptor (16:34:55.207):
Killed treeInterceptor: <virtualBuffers.gecko_ia2.Gecko_ia2 object at 0x04EC4770>
DEBUG - treeInterceptorHandler.update (16:34:55.216):
Adding new treeInterceptor to runningTable: <virtualBuffers.gecko_ia2.Gecko_ia2 object at 0x042AACD0>
DEBUG - virtualBuffers.VirtualBuffer._loadBuffer (16:34:55.217):
Buffer load took 0.000 sec, 67 chars
IO - speech.speak (16:34:55.223):
Speaking [LangChangeCommand ('en_GB'), 'Trimethoprim: uses, dose and side effects busy']
IO - speech.speak (16:34:55.226):
Speaking [<speech.commands.CallbackCommand object at 0x04ECB4D0>, LangChangeCommand ('en_GB'), 'https://www.netdoctor.co.uk/medicines/infection/a7689/trimethoprim/']
IO - speech.speak (16:34:55.227):
Speaking [<speech.commands.CallbackCommand object at 0x04ECB330>]
ERROR - speech.manager.SpeechManager._handleIndex (16:34:55.930):
Error running speech callback
Traceback (most recent call last):
File "speech\manager.pyc", line 375, in _handleIndex
File "speech\commands.pyc", line 260, in run
File "sayAllHandler.pyc", line 145, in <lambda>
File "sayAllHandler.pyc", line 174, in lineReached
File "documentBase.pyc", line 24, in makeTextInfo
File "virtualBuffers\__init__.pyc", line 208, in __init__
File "textInfos\offsets.pyc", line 424, in __init__
File "virtualBuffers\__init__.pyc", line 226, in _getStoryLength
OSError: [WinError 1775] A null context handle was passed from the client to the host during a remote procedure call
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:34:57.130):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:34:57.171):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:34:58.679):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:34:58.689):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:35:03.422):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:35:04.609):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
IO - inputCore.InputManager.executeGesture (16:35:05.086):
Input: kb(desktop):control+alt+r
IO - speech.speak (16:35:05.138):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar']
IO - speech.speak (16:35:05.193):
Speaking [LangChangeCommand ('en_GB'), 'reboot nvda with log terminal']
IO - speech.speak (16:35:05.194):
Speaking [LangChangeCommand ('en_GB'), '80 space', 'blank']
INFO - core.main (16:35:05.292):
Exiting

Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

Re: NVDA add-ons and Python 3: proper relative import syntax that works across Python versions

derek riemer
 

You can also do import appmodules.exename.foo, or import globalPlugins.myGlobalPluginName.foo, but there's a caviot. If the executable name has characters in it that aren't legal in module names, you can't import them this way and must use relative imports. We're working on a possible solution to this.

On Mon, Aug 5, 2019 at 12:36 AM Leonard de Ruijter <alderuijter@...> wrote:

Hello all,


I think it is important to add that the "from .something import *" import style is discouraged style. These import statements will cause warnings for the flake8 linter for example, as the linter does not know what names are imported when imported just everything.


Regards,

Leonard

Op 4-8-2019 om 16:31 schreef Joseph Lee:

Hi,

Syntax still works. For relative import, it’ll be “from . import something as somethingelse”.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of zvonimir stanecic, 9a5dsz
Sent: Sunday, August 4, 2019 3:43 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA add-ons and Python 3: proper relative import syntax that works across Python versions

 

Ok...

Can you tell me,

What’s used in python 3 to import something as something?

What is the backward compatibility approach?

In python 2 we had:

Import foots as foo

What’s used in py3?

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Sunday, August 4, 2019 5:48 AM
To: nvda-devel@groups.io
Subject: [nvda-devel] NVDA add-ons and Python 3: proper relative import syntax that works across Python versions

 

Hi all,

 

The following directive is based on more add-on compatibility investigations and a thread on add-ons list regarding Toolbars Explorer (incompatible at the moment). Because many add-ons are affected by this one, please apply fixes as soon as possible (if you intend to maintain your add-ons past 2019):

 

NVDA add-on and Python 3 August 2019 directive no. 2: relative imports

 

Many add-ons are structured like a package. That is, there is an __init__ file that imports modules from the same folder or other packages. If you wish to import a module from the same folder, you would use a relative import.

 

In Python 2, relative import of the form “import something” works, but in Python 3, due to preference for absolute imports, the former form will no longer work.

 

Examples:

 

# Yes:

from . import something # Works across Python 2 and 3

from .module import contents # Works across Python 2 and 3

# Or add the path to the current folder to sys.path and do:

import something # Works across Python 2 and 3

# If aliasing i.e. importing everything from a module:

from .module import * # Works across Python 2 and 3

 

# No:

import something # Not allowed in Python 3 if importing a module from the same folder

from module import contents # Not allowed in Python 3 if importing a module from the same folder

from something import * # Not allowed in Python 3 if aliasing a module from the same folder

 

Affected and compatible add-ons:

 

  • Add-on Updater
  • Character Information
  • Clock and calendar Add-on for NVDA
  • Resource Monitor
  • Station Playlist
  • UnicodeBrailleInput
  • Windows 10 App Essentials
  • Possibly more

 

Affected and incompatible add-ons:

 

  • Clipspeak
  • Dual Voice
  • Lambda Add-On for NVDA
  • NoBeepsSpeechMode
  • TeamTalk Classic
  • Text Information
  • Tip of the Day
  • ToolbarsExplorer
  • Possibly more

 

There are others that are currently incompatible but work is under way to make them compatible (work in progress or planned). These include Place Markers, Clip Contents Designer, Braille Extender and others.

 

Next steps: authors should provide a fix by using relative import statement compatible with both Python 2 and 3.

 

Cheers,

Joseph



--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com




Re: NVDA add-ons and Python 3: proper relative import syntax that works across Python versions

 

Hello all,


I think it is important to add that the "from .something import *" import style is discouraged style. These import statements will cause warnings for the flake8 linter for example, as the linter does not know what names are imported when imported just everything.


Regards,

Leonard

Op 4-8-2019 om 16:31 schreef Joseph Lee:

Hi,

Syntax still works. For relative import, it’ll be “from . import something as somethingelse”.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of zvonimir stanecic, 9a5dsz
Sent: Sunday, August 4, 2019 3:43 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA add-ons and Python 3: proper relative import syntax that works across Python versions

 

Ok...

Can you tell me,

What’s used in python 3 to import something as something?

What is the backward compatibility approach?

In python 2 we had:

Import foots as foo

What’s used in py3?

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Sunday, August 4, 2019 5:48 AM
To: nvda-devel@groups.io
Subject: [nvda-devel] NVDA add-ons and Python 3: proper relative import syntax that works across Python versions

 

Hi all,

 

The following directive is based on more add-on compatibility investigations and a thread on add-ons list regarding Toolbars Explorer (incompatible at the moment). Because many add-ons are affected by this one, please apply fixes as soon as possible (if you intend to maintain your add-ons past 2019):

 

NVDA add-on and Python 3 August 2019 directive no. 2: relative imports

 

Many add-ons are structured like a package. That is, there is an __init__ file that imports modules from the same folder or other packages. If you wish to import a module from the same folder, you would use a relative import.

 

In Python 2, relative import of the form “import something” works, but in Python 3, due to preference for absolute imports, the former form will no longer work.

 

Examples:

 

# Yes:

from . import something # Works across Python 2 and 3

from .module import contents # Works across Python 2 and 3

# Or add the path to the current folder to sys.path and do:

import something # Works across Python 2 and 3

# If aliasing i.e. importing everything from a module:

from .module import * # Works across Python 2 and 3

 

# No:

import something # Not allowed in Python 3 if importing a module from the same folder

from module import contents # Not allowed in Python 3 if importing a module from the same folder

from something import * # Not allowed in Python 3 if aliasing a module from the same folder

 

Affected and compatible add-ons:

 

  • Add-on Updater
  • Character Information
  • Clock and calendar Add-on for NVDA
  • Resource Monitor
  • Station Playlist
  • UnicodeBrailleInput
  • Windows 10 App Essentials
  • Possibly more

 

Affected and incompatible add-ons:

 

  • Clipspeak
  • Dual Voice
  • Lambda Add-On for NVDA
  • NoBeepsSpeechMode
  • TeamTalk Classic
  • Text Information
  • Tip of the Day
  • ToolbarsExplorer
  • Possibly more

 

There are others that are currently incompatible but work is under way to make them compatible (work in progress or planned). These include Place Markers, Clip Contents Designer, Braille Extender and others.

 

Next steps: authors should provide a fix by using relative import statement compatible with both Python 2 and 3.

 

Cheers,

Joseph

Strange page error in browser

Brian's Mail list account
 

The log below is from the latest alpha and using Waterfox on Windows 7. It seems not to be particularly page specific, but stops say all with an error.

Speaking [LangChangeCommand ('en_GB'), 'heading level 3', 'link', 'Trimethoprim: uses, dose and side effects - NetDoctor']
IO - inputCore.InputManager.executeGesture (16:34:54.551):
Input: kb(desktop):enter
DEBUG - treeInterceptorHandler.update (16:34:54.748):
Adding new treeInterceptor to runningTable: <virtualBuffers.gecko_ia2.Gecko_ia2 object at 0x04EC4770>
DEBUG - virtualBuffers.VirtualBuffer._loadBuffer (16:34:54.749):
Buffer load took 0.001 sec, 11 chars
IO - speech.speak (16:34:54.798):
Speaking [LangChangeCommand ('en_GB'), 'about:blank busy']
IO - speech.speak (16:34:54.809):
Speaking [<speech.commands.CallbackCommand object at 0x042AD170>, LangChangeCommand ('en_GB'), 'about:blank']
IO - speech.speak (16:34:54.809):
Speaking [<speech.commands.CallbackCommand object at 0x042A30F0>]
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:34:54.950):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:34:54.960):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:34:55.145):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUG - treeInterceptorHandler.killTreeInterceptor (16:34:55.207):
Killed treeInterceptor: <virtualBuffers.gecko_ia2.Gecko_ia2 object at 0x04EC4770>
DEBUG - treeInterceptorHandler.update (16:34:55.216):
Adding new treeInterceptor to runningTable: <virtualBuffers.gecko_ia2.Gecko_ia2 object at 0x042AACD0>
DEBUG - virtualBuffers.VirtualBuffer._loadBuffer (16:34:55.217):
Buffer load took 0.000 sec, 67 chars
IO - speech.speak (16:34:55.223):
Speaking [LangChangeCommand ('en_GB'), 'Trimethoprim: uses, dose and side effects busy']
IO - speech.speak (16:34:55.226):
Speaking [<speech.commands.CallbackCommand object at 0x04ECB4D0>, LangChangeCommand ('en_GB'), 'https://www.netdoctor.co.uk/medicines/infection/a7689/trimethoprim/']
IO - speech.speak (16:34:55.227):
Speaking [<speech.commands.CallbackCommand object at 0x04ECB330>]
ERROR - speech.manager.SpeechManager._handleIndex (16:34:55.930):
Error running speech callback
Traceback (most recent call last):
File "speech\manager.pyc", line 375, in _handleIndex
File "speech\commands.pyc", line 260, in run
File "sayAllHandler.pyc", line 145, in <lambda>
File "sayAllHandler.pyc", line 174, in lineReached
File "documentBase.pyc", line 24, in makeTextInfo
File "virtualBuffers\__init__.pyc", line 208, in __init__
File "textInfos\offsets.pyc", line 424, in __init__
File "virtualBuffers\__init__.pyc", line 226, in _getStoryLength
OSError: [WinError 1775] A null context handle was passed from the client to the host during a remote procedure call
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:34:57.130):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:34:57.171):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:34:58.679):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:34:58.689):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:35:03.422):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:35:04.609):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
IO - inputCore.InputManager.executeGesture (16:35:05.086):
Input: kb(desktop):control+alt+r
IO - speech.speak (16:35:05.138):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar']
IO - speech.speak (16:35:05.193):
Speaking [LangChangeCommand ('en_GB'), 'reboot nvda with log terminal']
IO - speech.speak (16:35:05.194):
Speaking [LangChangeCommand ('en_GB'), '80 space', 'blank']
INFO - core.main (16:35:05.292):
Exiting

Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

Re: NVDA add-ons and Python 3: proper relative import syntax that works across Python versions

 

Hi,

Syntax still works. For relative import, it’ll be “from . import something as somethingelse”.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of zvonimir stanecic, 9a5dsz
Sent: Sunday, August 4, 2019 3:43 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA add-ons and Python 3: proper relative import syntax that works across Python versions

 

Ok...

Can you tell me,

What’s used in python 3 to import something as something?

What is the backward compatibility approach?

In python 2 we had:

Import foots as foo

What’s used in py3?

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Sunday, August 4, 2019 5:48 AM
To: nvda-devel@groups.io
Subject: [nvda-devel] NVDA add-ons and Python 3: proper relative import syntax that works across Python versions

 

Hi all,

 

The following directive is based on more add-on compatibility investigations and a thread on add-ons list regarding Toolbars Explorer (incompatible at the moment). Because many add-ons are affected by this one, please apply fixes as soon as possible (if you intend to maintain your add-ons past 2019):

 

NVDA add-on and Python 3 August 2019 directive no. 2: relative imports

 

Many add-ons are structured like a package. That is, there is an __init__ file that imports modules from the same folder or other packages. If you wish to import a module from the same folder, you would use a relative import.

 

In Python 2, relative import of the form “import something” works, but in Python 3, due to preference for absolute imports, the former form will no longer work.

 

Examples:

 

# Yes:

from . import something # Works across Python 2 and 3

from .module import contents # Works across Python 2 and 3

# Or add the path to the current folder to sys.path and do:

import something # Works across Python 2 and 3

# If aliasing i.e. importing everything from a module:

from .module import * # Works across Python 2 and 3

 

# No:

import something # Not allowed in Python 3 if importing a module from the same folder

from module import contents # Not allowed in Python 3 if importing a module from the same folder

from something import * # Not allowed in Python 3 if aliasing a module from the same folder

 

Affected and compatible add-ons:

 

  • Add-on Updater
  • Character Information
  • Clock and calendar Add-on for NVDA
  • Resource Monitor
  • Station Playlist
  • UnicodeBrailleInput
  • Windows 10 App Essentials
  • Possibly more

 

Affected and incompatible add-ons:

 

  • Clipspeak
  • Dual Voice
  • Lambda Add-On for NVDA
  • NoBeepsSpeechMode
  • TeamTalk Classic
  • Text Information
  • Tip of the Day
  • ToolbarsExplorer
  • Possibly more

 

There are others that are currently incompatible but work is under way to make them compatible (work in progress or planned). These include Place Markers, Clip Contents Designer, Braille Extender and others.

 

Next steps: authors should provide a fix by using relative import statement compatible with both Python 2 and 3.

 

Cheers,

Joseph

Re: NVDA add-ons and Python 3: proper relative import syntax that works across Python versions

zvonimir stanečić, 9a5dsz
 

Ok...

Can you tell me,

What’s used in python 3 to import something as something?

What is the backward compatibility approach?

In python 2 we had:

Import foots as foo

What’s used in py3?

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Sunday, August 4, 2019 5:48 AM
To: nvda-devel@groups.io
Subject: [nvda-devel] NVDA add-ons and Python 3: proper relative import syntax that works across Python versions

 

Hi all,

 

The following directive is based on more add-on compatibility investigations and a thread on add-ons list regarding Toolbars Explorer (incompatible at the moment). Because many add-ons are affected by this one, please apply fixes as soon as possible (if you intend to maintain your add-ons past 2019):

 

NVDA add-on and Python 3 August 2019 directive no. 2: relative imports

 

Many add-ons are structured like a package. That is, there is an __init__ file that imports modules from the same folder or other packages. If you wish to import a module from the same folder, you would use a relative import.

 

In Python 2, relative import of the form “import something” works, but in Python 3, due to preference for absolute imports, the former form will no longer work.

 

Examples:

 

# Yes:

from . import something # Works across Python 2 and 3

from .module import contents # Works across Python 2 and 3

# Or add the path to the current folder to sys.path and do:

import something # Works across Python 2 and 3

# If aliasing i.e. importing everything from a module:

from .module import * # Works across Python 2 and 3

 

# No:

import something # Not allowed in Python 3 if importing a module from the same folder

from module import contents # Not allowed in Python 3 if importing a module from the same folder

from something import * # Not allowed in Python 3 if aliasing a module from the same folder

 

Affected and compatible add-ons:

 

  • Add-on Updater
  • Character Information
  • Clock and calendar Add-on for NVDA
  • Resource Monitor
  • Station Playlist
  • UnicodeBrailleInput
  • Windows 10 App Essentials
  • Possibly more

 

Affected and incompatible add-ons:

 

  • Clipspeak
  • Dual Voice
  • Lambda Add-On for NVDA
  • NoBeepsSpeechMode
  • TeamTalk Classic
  • Text Information
  • Tip of the Day
  • ToolbarsExplorer
  • Possibly more

 

There are others that are currently incompatible but work is under way to make them compatible (work in progress or planned). These include Place Markers, Clip Contents Designer, Braille Extender and others.

 

Next steps: authors should provide a fix by using relative import statement compatible with both Python 2 and 3.

 

Cheers,

Joseph

NVDA add-ons and Python 3: proper relative import syntax that works across Python versions

 

Hi all,

 

The following directive is based on more add-on compatibility investigations and a thread on add-ons list regarding Toolbars Explorer (incompatible at the moment). Because many add-ons are affected by this one, please apply fixes as soon as possible (if you intend to maintain your add-ons past 2019):

 

NVDA add-on and Python 3 August 2019 directive no. 2: relative imports

 

Many add-ons are structured like a package. That is, there is an __init__ file that imports modules from the same folder or other packages. If you wish to import a module from the same folder, you would use a relative import.

 

In Python 2, relative import of the form “import something” works, but in Python 3, due to preference for absolute imports, the former form will no longer work.

 

Examples:

 

# Yes:

from . import something # Works across Python 2 and 3

from .module import contents # Works across Python 2 and 3

# Or add the path to the current folder to sys.path and do:

import something # Works across Python 2 and 3

# If aliasing i.e. importing everything from a module:

from .module import * # Works across Python 2 and 3

 

# No:

import something # Not allowed in Python 3 if importing a module from the same folder

from module import contents # Not allowed in Python 3 if importing a module from the same folder

from something import * # Not allowed in Python 3 if aliasing a module from the same folder

 

Affected and compatible add-ons:

 

  • Add-on Updater
  • Character Information
  • Clock and calendar Add-on for NVDA
  • Resource Monitor
  • Station Playlist
  • UnicodeBrailleInput
  • Windows 10 App Essentials
  • Possibly more

 

Affected and incompatible add-ons:

 

  • Clipspeak
  • Dual Voice
  • Lambda Add-On for NVDA
  • NoBeepsSpeechMode
  • TeamTalk Classic
  • Text Information
  • Tip of the Day
  • ToolbarsExplorer
  • Possibly more

 

There are others that are currently incompatible but work is under way to make them compatible (work in progress or planned). These include Place Markers, Clip Contents Designer, Braille Extender and others.

 

Next steps: authors should provide a fix by using relative import statement compatible with both Python 2 and 3.

 

Cheers,

Joseph

Re: Python 3 and Windows API functions: please standardize around Unicode (wide character) functions unless justified otherwise

 

Hi,
Correct. As I noted yesterday, there are other add-ons exhibiting this
issue, and I hope authors will take care of that when they are ready.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail
list account via Groups.Io
Sent: Saturday, August 3, 2019 12:41 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Python 3 and Windows API functions: please
standardize around Unicode (wide character) functions unless justified
otherwise

That explains why keypresses in extended winamp are ignored then as
effectively their is a mismatch wheree there should be a match.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Saturday, August 03, 2019 2:11 AM
Subject: [nvda-devel] Python 3 and Windows API functions: please standardize
around Unicode (wide character) functions unless justified otherwise


Hi all,



The following Python 3 porting directive applies to anyone working
with Windows API functions, specifically ones requiring strings for
certain
operations:



August 2019 Python 3 add-on directive no. 1: standardize around
Unicode (wide character) functions unless justified otherwise



Certain Windows API functions expect different string data format
depending on which function signature is invoked:



* *A: ANSI (bytes)
* *W: Unicode (wide characters)



Functions defined this way include FindWindow, FindWindowEx, and others.
Because Python 3 wants to use Unicode by default, you should call wide
character functions (FindWindowW, for example) unless justified otherwise.
If you absolutely need to use ANSI functions, please prefix strings with a
"b" (without quotes).



Examples:



# Yes:

HWND = winUser.user32.FindWindowW("windowClassName", None) # strictly
Python
3

HWND = winUser.user32.FindWindowA(b"ANSIClassName", None) # Python 2 and 3

HWND = winUser.user32.FindWindowW(u"UnicodeClassName", None) # Python 2
and
3

HWND = winUser.user32.FindWindowA("windowClassName", None) # strictly
Python
2



# No:

HWND = winUser.user32.FindWindowA("UnicodeClassName", None) # No in Python
3

HWND = winUser.user32.FindWindowW(b"ANSIClassName", None) # Wrong data
type
across Python versions



Of these, I recommend going with option 3 (from first list), as it
guarantees widest compatibility.



The following add-ons are affected:



* Dropbox
* Extended Winamp
* StationPlaylist
* SystrayList
* Many more



Add-ons noted above may load under NVDA 2019.3 alpha if manifests are
modified. For add-ons hosted on community add-ons website, StationPlaylist
and SystrayList passes this check.



Next steps: please contact add-on authors regarding their thoughts on
compatibility.



Thanks.

Cheers,

Joseph




Re: Alpha will not download, was Re: [nvda-devel] Extra checks forPull Requests

zvonimir stanečić, 9a5dsz
 

Yes, now this issue is fixed.

 

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of derek riemer
Sent: Saturday, August 3, 2019 10:00 AM
To: nvda-devel@groups.io
Subject: Re: Alpha will not download, was Re: [nvda-devel] Extra checks forPull Requests

 

oh.

 

On Sat, Aug 3, 2019 at 1:58 AM Arnold Loubriat <datatriny@...> wrote:

Hi Derek,

Just for reference: no it was not an AppVeyor outage.

See https://github.com/nvaccess/nvda/pull/10020 that got merged by Reef yesterday!

Have a nice day.

 

Arnold

 

De : derek riemer
Envoyé le :samedi 3 août 2019 07:04
À : nvda-devel@groups.io
Objet :Re: Alpha will not download, was Re: [nvda-devel] Extra checks forPull Requests

 

I think appVeyor had an outage or something. it's working again.

 

On Thu, Aug 1, 2019 at 1:34 PM Brian's Mail list account via Groups.Io <bglists=blueyonder.co.uk@groups.io> wrote:

For completeness.

IO - speech.speak (20:29:39.220):
Speaking [LangChangeCommand ('en_GB'), 'space', EndUtteranceCommand()]
IO - speech.speak (20:29:39.220):
Speaking [LangChangeCommand ('en_GB'), 'pressed']
IO - speech.speak (20:29:39.388):
Speaking [LangChangeCommand ('en_GB'), 'Downloading Update  dialog
Connecting']
IO - speech.speak (20:29:39.393):
Speaking [LangChangeCommand ('en_GB'), 'Cancel  button']
ERROR - updateCheck.UpdateDownloader._bg (20:29:40.938):
Error downloading
https://ci.appveyor.com/api/buildjobs/vg63itgyy5xrff9m/artifacts/output/nvda_snapshot_alpha-18266,1af87759.exe
Traceback (most recent call last):
  File "updateCheck.pyc", line 601, in _bg
  File "updateCheck.pyc", line 624, in _download
  File "urllib\request.pyc", line 222, in urlopen
  File "urllib\request.pyc", line 531, in open
  File "urllib\request.pyc", line 641, in http_response
  File "urllib\request.pyc", line 563, in error
  File "urllib\request.pyc", line 503, in _call_chain
  File "urllib\request.pyc", line 755, in http_error_302
  File "urllib\request.pyc", line 531, in open
  File "urllib\request.pyc", line 641, in http_response
  File "urllib\request.pyc", line 569, in error
  File "urllib\request.pyc", line 503, in _call_chain
  File "urllib\request.pyc", line 649, in http_error_default
urllib.error.HTTPError: HTTP Error 404: The specified blob does not exist.
IO - speech.speak (20:29:41.040):
Speaking [LangChangeCommand ('en_GB'), 'Error  dialog  Error downloading
update.']
IO - speech.speak (20:29:41.049):
Speaking [LangChangeCommand ('en_GB'), 'OK  button']

Brian


bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "zvonimir stanečić, 9a5dsz" <zvonimirek222@...>
To: <nvda-devel@groups.io>
Sent: Thursday, August 01, 2019 8:02 PM
Subject: Re: [nvda-devel] Extra checks for Pull Requests


Hi Reef,

To hijack the thread…

Why it’s not possible to download the latest alpha?

Somewhere we have 404 errors



From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Reef Turner
Sent: Thursday, August 1, 2019 8:59 PM
To: nvda-devel@groups.io
Subject: [nvda-devel] Extra checks for Pull Requests



Hi everyone,



We have recently introduced new checks for Pull Requests on GitHub
<https://github.com/nvaccess/nvda/pull/9958> .



Code contributors regularly have to deal with ill-defined and inconsistently
enforced code style requirements. Code reviewers spend much of their time
reporting minor issues, time that would be better spent looking for
architectural problems / product issues / logic errors.



To improve this situation, in future PR builds the Flake8 linter will be run
checking any new code that will be introduced with a PR. This can also be
run with SCons using `scons lint base=origin/master`. Please see the
`tests/lint/readme.md` file for more information.



As part of a PR build, the Flake8 linter will be run checking any new code
that will be introduced with a PR. When Flake8 reports the does not comply
with it’s configuration, a message from Appveyor will be added as a comment
to the Pull Request, and the build will fail. Please note, that in this case
the artifacts (PR build executable) will still be available if those steps
were successful.



We have included an extension with the linter setup to allow tabs instead of
spaces, and my find it necessary to disable other warnings, or introduce
workarounds. However, in general we would like to stick as close to the
default settings as possible.



Thanks for all your contributions!

--

Reef Turner
Software Developer



 <https://www.nvaccess.org/> www.nvaccess.org

Facebook: https://www.facebook.com/NVAccess
Twitter: @NVAccess

  <https://docs.google.com/uc?export=download&id=1ewvP2k8vO2yVx8f7qN46MLkUNt6pt8f_&revid=0B9qtAUOcqzA6dW5BQW55ZEp5UUptWjVYaXF5bnV4VC9qSGVRPQ>












--

Derek Riemer
Improving the world one byte at a time!       
⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com


 



--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com



Re: Alpha will not download, was Re: [nvda-devel] Extra checks forPull Requests

derek riemer
 

oh.

On Sat, Aug 3, 2019 at 1:58 AM Arnold Loubriat <datatriny@...> wrote:

Hi Derek,

Just for reference: no it was not an AppVeyor outage.

See https://github.com/nvaccess/nvda/pull/10020 that got merged by Reef yesterday!

Have a nice day.

 

Arnold

 

De : derek riemer
Envoyé le :samedi 3 août 2019 07:04
À : nvda-devel@groups.io
Objet :Re: Alpha will not download, was Re: [nvda-devel] Extra checks forPull Requests

 

I think appVeyor had an outage or something. it's working again.

 

On Thu, Aug 1, 2019 at 1:34 PM Brian's Mail list account via Groups.Io <bglists=blueyonder.co.uk@groups.io> wrote:

For completeness.

IO - speech.speak (20:29:39.220):
Speaking [LangChangeCommand ('en_GB'), 'space', EndUtteranceCommand()]
IO - speech.speak (20:29:39.220):
Speaking [LangChangeCommand ('en_GB'), 'pressed']
IO - speech.speak (20:29:39.388):
Speaking [LangChangeCommand ('en_GB'), 'Downloading Update  dialog
Connecting']
IO - speech.speak (20:29:39.393):
Speaking [LangChangeCommand ('en_GB'), 'Cancel  button']
ERROR - updateCheck.UpdateDownloader._bg (20:29:40.938):
Error downloading
https://ci.appveyor.com/api/buildjobs/vg63itgyy5xrff9m/artifacts/output/nvda_snapshot_alpha-18266,1af87759.exe
Traceback (most recent call last):
  File "updateCheck.pyc", line 601, in _bg
  File "updateCheck.pyc", line 624, in _download
  File "urllib\request.pyc", line 222, in urlopen
  File "urllib\request.pyc", line 531, in open
  File "urllib\request.pyc", line 641, in http_response
  File "urllib\request.pyc", line 563, in error
  File "urllib\request.pyc", line 503, in _call_chain
  File "urllib\request.pyc", line 755, in http_error_302
  File "urllib\request.pyc", line 531, in open
  File "urllib\request.pyc", line 641, in http_response
  File "urllib\request.pyc", line 569, in error
  File "urllib\request.pyc", line 503, in _call_chain
  File "urllib\request.pyc", line 649, in http_error_default
urllib.error.HTTPError: HTTP Error 404: The specified blob does not exist.
IO - speech.speak (20:29:41.040):
Speaking [LangChangeCommand ('en_GB'), 'Error  dialog  Error downloading
update.']
IO - speech.speak (20:29:41.049):
Speaking [LangChangeCommand ('en_GB'), 'OK  button']

Brian


bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "zvonimir stanečić, 9a5dsz" <zvonimirek222@...>
To: <nvda-devel@groups.io>
Sent: Thursday, August 01, 2019 8:02 PM
Subject: Re: [nvda-devel] Extra checks for Pull Requests


Hi Reef,

To hijack the thread…

Why it’s not possible to download the latest alpha?

Somewhere we have 404 errors



From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Reef Turner
Sent: Thursday, August 1, 2019 8:59 PM
To: nvda-devel@groups.io
Subject: [nvda-devel] Extra checks for Pull Requests



Hi everyone,



We have recently introduced new checks for Pull Requests on GitHub
<https://github.com/nvaccess/nvda/pull/9958> .



Code contributors regularly have to deal with ill-defined and inconsistently
enforced code style requirements. Code reviewers spend much of their time
reporting minor issues, time that would be better spent looking for
architectural problems / product issues / logic errors.



To improve this situation, in future PR builds the Flake8 linter will be run
checking any new code that will be introduced with a PR. This can also be
run with SCons using `scons lint base=origin/master`. Please see the
`tests/lint/readme.md` file for more information.



As part of a PR build, the Flake8 linter will be run checking any new code
that will be introduced with a PR. When Flake8 reports the does not comply
with it’s configuration, a message from Appveyor will be added as a comment
to the Pull Request, and the build will fail. Please note, that in this case
the artifacts (PR build executable) will still be available if those steps
were successful.



We have included an extension with the linter setup to allow tabs instead of
spaces, and my find it necessary to disable other warnings, or introduce
workarounds. However, in general we would like to stick as close to the
default settings as possible.



Thanks for all your contributions!

--

Reef Turner
Software Developer



 <https://www.nvaccess.org/> www.nvaccess.org

Facebook: https://www.facebook.com/NVAccess
Twitter: @NVAccess

  <https://docs.google.com/uc?export=download&id=1ewvP2k8vO2yVx8f7qN46MLkUNt6pt8f_&revid=0B9qtAUOcqzA6dW5BQW55ZEp5UUptWjVYaXF5bnV4VC9qSGVRPQ>













--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com



 



--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com




Re: Alpha will not download, was Re: [nvda-devel] Extra checks forPull Requests

Arnold Loubriat
 

Hi Derek,

Just for reference: no it was not an AppVeyor outage.

See https://github.com/nvaccess/nvda/pull/10020 that got merged by Reef yesterday!

Have a nice day.

 

Arnold

 

De : derek riemer
Envoyé le :samedi 3 août 2019 07:04
À : nvda-devel@groups.io
Objet :Re: Alpha will not download, was Re: [nvda-devel] Extra checks forPull Requests

 

I think appVeyor had an outage or something. it's working again.

 

On Thu, Aug 1, 2019 at 1:34 PM Brian's Mail list account via Groups.Io <bglists=blueyonder.co.uk@groups.io> wrote:

For completeness.

IO - speech.speak (20:29:39.220):
Speaking [LangChangeCommand ('en_GB'), 'space', EndUtteranceCommand()]
IO - speech.speak (20:29:39.220):
Speaking [LangChangeCommand ('en_GB'), 'pressed']
IO - speech.speak (20:29:39.388):
Speaking [LangChangeCommand ('en_GB'), 'Downloading Update  dialog
Connecting']
IO - speech.speak (20:29:39.393):
Speaking [LangChangeCommand ('en_GB'), 'Cancel  button']
ERROR - updateCheck.UpdateDownloader._bg (20:29:40.938):
Error downloading
https://ci.appveyor.com/api/buildjobs/vg63itgyy5xrff9m/artifacts/output/nvda_snapshot_alpha-18266,1af87759.exe
Traceback (most recent call last):
  File "updateCheck.pyc", line 601, in _bg
  File "updateCheck.pyc", line 624, in _download
  File "urllib\request.pyc", line 222, in urlopen
  File "urllib\request.pyc", line 531, in open
  File "urllib\request.pyc", line 641, in http_response
  File "urllib\request.pyc", line 563, in error
  File "urllib\request.pyc", line 503, in _call_chain
  File "urllib\request.pyc", line 755, in http_error_302
  File "urllib\request.pyc", line 531, in open
  File "urllib\request.pyc", line 641, in http_response
  File "urllib\request.pyc", line 569, in error
  File "urllib\request.pyc", line 503, in _call_chain
  File "urllib\request.pyc", line 649, in http_error_default
urllib.error.HTTPError: HTTP Error 404: The specified blob does not exist.
IO - speech.speak (20:29:41.040):
Speaking [LangChangeCommand ('en_GB'), 'Error  dialog  Error downloading
update.']
IO - speech.speak (20:29:41.049):
Speaking [LangChangeCommand ('en_GB'), 'OK  button']

Brian


bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "zvonimir stanečić, 9a5dsz" <zvonimirek222@...>
To: <nvda-devel@groups.io>
Sent: Thursday, August 01, 2019 8:02 PM
Subject: Re: [nvda-devel] Extra checks for Pull Requests


Hi Reef,

To hijack the thread…

Why it’s not possible to download the latest alpha?

Somewhere we have 404 errors



From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Reef Turner
Sent: Thursday, August 1, 2019 8:59 PM
To: nvda-devel@groups.io
Subject: [nvda-devel] Extra checks for Pull Requests



Hi everyone,



We have recently introduced new checks for Pull Requests on GitHub
<https://github.com/nvaccess/nvda/pull/9958> .



Code contributors regularly have to deal with ill-defined and inconsistently
enforced code style requirements. Code reviewers spend much of their time
reporting minor issues, time that would be better spent looking for
architectural problems / product issues / logic errors.



To improve this situation, in future PR builds the Flake8 linter will be run
checking any new code that will be introduced with a PR. This can also be
run with SCons using `scons lint base=origin/master`. Please see the
`tests/lint/readme.md` file for more information.



As part of a PR build, the Flake8 linter will be run checking any new code
that will be introduced with a PR. When Flake8 reports the does not comply
with it’s configuration, a message from Appveyor will be added as a comment
to the Pull Request, and the build will fail. Please note, that in this case
the artifacts (PR build executable) will still be available if those steps
were successful.



We have included an extension with the linter setup to allow tabs instead of
spaces, and my find it necessary to disable other warnings, or introduce
workarounds. However, in general we would like to stick as close to the
default settings as possible.



Thanks for all your contributions!

--

Reef Turner
Software Developer



 <https://www.nvaccess.org/> www.nvaccess.org

Facebook: https://www.facebook.com/NVAccess
Twitter: @NVAccess

  <https://docs.google.com/uc?export=download&id=1ewvP2k8vO2yVx8f7qN46MLkUNt6pt8f_&revid=0B9qtAUOcqzA6dW5BQW55ZEp5UUptWjVYaXF5bnV4VC9qSGVRPQ>













--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com



 

Re: Python 3 and Windows API functions: please standardize around Unicode (wide character) functions unless justified otherwise

Brian's Mail list account
 

That explains why keypresses in extended winamp are ignored then as effectively their is a mismatch wheree there should be a match.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Saturday, August 03, 2019 2:11 AM
Subject: [nvda-devel] Python 3 and Windows API functions: please standardize around Unicode (wide character) functions unless justified otherwise


Hi all,



The following Python 3 porting directive applies to anyone working with
Windows API functions, specifically ones requiring strings for certain
operations:



August 2019 Python 3 add-on directive no. 1: standardize around Unicode
(wide character) functions unless justified otherwise



Certain Windows API functions expect different string data format depending
on which function signature is invoked:



* *A: ANSI (bytes)
* *W: Unicode (wide characters)



Functions defined this way include FindWindow, FindWindowEx, and others.
Because Python 3 wants to use Unicode by default, you should call wide
character functions (FindWindowW, for example) unless justified otherwise.
If you absolutely need to use ANSI functions, please prefix strings with a
"b" (without quotes).



Examples:



# Yes:

HWND = winUser.user32.FindWindowW("windowClassName", None) # strictly Python
3

HWND = winUser.user32.FindWindowA(b"ANSIClassName", None) # Python 2 and 3

HWND = winUser.user32.FindWindowW(u"UnicodeClassName", None) # Python 2 and
3

HWND = winUser.user32.FindWindowA("windowClassName", None) # strictly Python
2



# No:

HWND = winUser.user32.FindWindowA("UnicodeClassName", None) # No in Python 3

HWND = winUser.user32.FindWindowW(b"ANSIClassName", None) # Wrong data type
across Python versions



Of these, I recommend going with option 3 (from first list), as it
guarantees widest compatibility.



The following add-ons are affected:



* Dropbox
* Extended Winamp
* StationPlaylist
* SystrayList
* Many more



Add-ons noted above may load under NVDA 2019.3 alpha if manifests are
modified. For add-ons hosted on community add-ons website, StationPlaylist
and SystrayList passes this check.



Next steps: please contact add-on authors regarding their thoughts on
compatibility.



Thanks.

Cheers,

Joseph



Re: Alpha will not download, was Re: [nvda-devel] Extra checks for Pull Requests

derek riemer
 

I think appVeyor had an outage or something. it's working again.

On Thu, Aug 1, 2019 at 1:34 PM Brian's Mail list account via Groups.Io <bglists=blueyonder.co.uk@groups.io> wrote:
For completeness.

IO - speech.speak (20:29:39.220):
Speaking [LangChangeCommand ('en_GB'), 'space', EndUtteranceCommand()]
IO - speech.speak (20:29:39.220):
Speaking [LangChangeCommand ('en_GB'), 'pressed']
IO - speech.speak (20:29:39.388):
Speaking [LangChangeCommand ('en_GB'), 'Downloading Update  dialog
Connecting']
IO - speech.speak (20:29:39.393):
Speaking [LangChangeCommand ('en_GB'), 'Cancel  button']
ERROR - updateCheck.UpdateDownloader._bg (20:29:40.938):
Error downloading
https://ci.appveyor.com/api/buildjobs/vg63itgyy5xrff9m/artifacts/output/nvda_snapshot_alpha-18266,1af87759.exe
Traceback (most recent call last):
  File "updateCheck.pyc", line 601, in _bg
  File "updateCheck.pyc", line 624, in _download
  File "urllib\request.pyc", line 222, in urlopen
  File "urllib\request.pyc", line 531, in open
  File "urllib\request.pyc", line 641, in http_response
  File "urllib\request.pyc", line 563, in error
  File "urllib\request.pyc", line 503, in _call_chain
  File "urllib\request.pyc", line 755, in http_error_302
  File "urllib\request.pyc", line 531, in open
  File "urllib\request.pyc", line 641, in http_response
  File "urllib\request.pyc", line 569, in error
  File "urllib\request.pyc", line 503, in _call_chain
  File "urllib\request.pyc", line 649, in http_error_default
urllib.error.HTTPError: HTTP Error 404: The specified blob does not exist.
IO - speech.speak (20:29:41.040):
Speaking [LangChangeCommand ('en_GB'), 'Error  dialog  Error downloading
update.']
IO - speech.speak (20:29:41.049):
Speaking [LangChangeCommand ('en_GB'), 'OK  button']

Brian


bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "zvonimir stanečić, 9a5dsz" <zvonimirek222@...>
To: <nvda-devel@groups.io>
Sent: Thursday, August 01, 2019 8:02 PM
Subject: Re: [nvda-devel] Extra checks for Pull Requests


Hi Reef,

To hijack the thread…

Why it’s not possible to download the latest alpha?

Somewhere we have 404 errors



From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Reef Turner
Sent: Thursday, August 1, 2019 8:59 PM
To: nvda-devel@groups.io
Subject: [nvda-devel] Extra checks for Pull Requests



Hi everyone,



We have recently introduced new checks for Pull Requests on GitHub
<https://github.com/nvaccess/nvda/pull/9958> .



Code contributors regularly have to deal with ill-defined and inconsistently
enforced code style requirements. Code reviewers spend much of their time
reporting minor issues, time that would be better spent looking for
architectural problems / product issues / logic errors.



To improve this situation, in future PR builds the Flake8 linter will be run
checking any new code that will be introduced with a PR. This can also be
run with SCons using `scons lint base=origin/master`. Please see the
`tests/lint/readme.md` file for more information.



As part of a PR build, the Flake8 linter will be run checking any new code
that will be introduced with a PR. When Flake8 reports the does not comply
with it’s configuration, a message from Appveyor will be added as a comment
to the Pull Request, and the build will fail. Please note, that in this case
the artifacts (PR build executable) will still be available if those steps
were successful.



We have included an extension with the linter setup to allow tabs instead of
spaces, and my find it necessary to disable other warnings, or introduce
workarounds. However, in general we would like to stick as close to the
default settings as possible.



Thanks for all your contributions!

--

Reef Turner
Software Developer



 <https://www.nvaccess.org/> www.nvaccess.org

Facebook: https://www.facebook.com/NVAccess
Twitter: @NVAccess

  <https://docs.google.com/uc?export=download&id=1ewvP2k8vO2yVx8f7qN46MLkUNt6pt8f_&revid=0B9qtAUOcqzA6dW5BQW55ZEp5UUptWjVYaXF5bnV4VC9qSGVRPQ>














--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com