Hi,
I would like to propose that there be no app modules in core. Unless I'm
incorrect, MS Word, Excel, and Outlook are not app modules in the sense that
add-ons are. Feel free to correct me.
Jim
==========
Jim Homme,
Accessibility Consultant,
Bender HighTest Accessibility Team
Bender Consulting Services, Inc.,
412-787-8567,
jhomme@xxxxxxxxxxxxxxxxx
http://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
E+R=O
-----Original Message-----
From: nvda-addons-bounce@xxxxxxxxxxxxx
[mailto:nvda-addons-bounce@xxxxxxxxxxxxx] On Behalf Of Brian's Mail list
account BY
Sent: Tuesday, February 16, 2016 6:55 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
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