See my other reply which may or may not appear on this list as well as the
other one!
Brian
--------------------------------------------------
From: "Shaun Everiss" <sm.everiss@xxxxxxxxx>
Sent: Tuesday, February 16, 2016 7:35 AM
To: <nvda-addons@xxxxxxxxxxxxx>
Subject: [nvda-addons] Re: NVDA Core: things to deprecate, things to keep
for a little longer, sorting through a soil of mixed styles and expectations
Hmmm interesting, I do think as a user that I'd like a history of the reader where its come from etc to be noted with major and minor events or just major ones and that kept updated well as updated as it could be for the user anyway.
We have come a long way since build 425 which was the earliest build I ever ran.
On 16/02/2016 8:09 p.m., Joseph Lee wrote:
Hi all (NVDA Core developers and add-on writers):----------------------------------------------------------------
Sorry for this style of email - sending this one to both the developers and
add-ons list at the same time. I don't remember if I brought this up before.
Since this year is an important milestone for NVDA, I'd like to propose that
we take some time cleaning up NVDA's source code. Over the years, our
beloved NVDA Core source code became a repository of additions, changes and
deletions that records the overall history of NVDA and screen reading in
general. Although we do have algorithms and module imports that withstood
trials of time, I think there are certain parts of the source code that
should be gone (either because the code is no longer relevant or no-one uses
some code paths anymore).
We also have mixture of code styles in use. Some of these include monkey
patches that may have seen the light of day by official builds (such as
certain Python monkey patches related to tempfile path handling), duplicate
imports (unless circular dependencies are introduced), and odd declarations
such as certain class declaration wording (especially speech processing
modules). Although code styles are good at showing the history of NVDA
contributions and expresses views of programmers, I think we may send a
wrong message to our posterity: mixed styles are acceptable (this is also an
issue for add-ons as well).
Thus I'd like to request that we:
* Document what needs to be gone. We do have deprecation warnings
posted on certain code paths (for instance, config/__init__.py). Let's
remove truly deprecated code paths once we verify that it is time to let
them go.
* Document what needs to be kept for a little while: This includes
things such as i18n names for speech settings and what not (when I (with
guidance from Jamie) wrote that code regarding accelerators, I anticipated
that the old code would be removed within a year or two).
* Code style unification and cleaning up imports: This is a hard
one, as we need to consider best practices in coding style as well as take
views of developers into account. I believe that, for the benefit of future
developers, we should unify code styles (this includes putting appropriate
header on files, trying to track and document who wrote parts of modules and
so on).
* Add-on cleanup (for add-on writers and reviewers): We have add-ons
that I believe they have served their purposes and it's time to retire them.
For items 1 and 2, I'd like to gather feedback on what needs to go and kept
alive for a little while. I've dedicated a branch for this purpose at my own
NVDA code fork:
http://github.com/josephsl/nvda
Branch is "deprecationRemoval". Once we hear "testimonies" from code paths
concerned, we should collect necessary modifications and present them in a
single pull request (I'll take care of this at this point so other devs can
work on more important things).
In regards to item 3, I think NV Access should have a final say on styles,
imports and what not (after all, Mick and Jamie are the public face of NVDA
development). As for item 4, I think this is something that add-ons
community will need help from other NVDA developers.
Please let me and others know if you have suggestions, comments, concerns
and so on, or if you'd like to "represent" deprecated code paths (let us
know why it should be kept).
Cheers,
Joseph
NVDA add-ons: A list to discuss add-on code enhancements and for reporting bugs.
Community addons are available from: http://addons.nvda-project.org
To send a message to the list: nvda-addons@xxxxxxxxxxxxx
To change your list settings/unsubscribe: //www.freelists.org/list/nvda-addons
To contact list moderators: nvda-addons-moderators@xxxxxxxxxxxxx
