Hi Jim,
App modules are essential in Core. We do need app module support in Core and
we need support for various app out of the box, otherwise people will not be
inspired to write new app modules and users may not be drawn to NVDA due to
lack of app modules.
Microsoft Office support routines: some are part of external app modules,
while majority of them cannot become app modules. This is because many
controls throughout Office are powered by Microsoft Word, Excel or others.
Same goes with support for various IAccessible objects for use in Mozilla
software (Firefox, Thunderbird), UIA and Edge controls (Microsoft Edge,
various Windows 10 controls and so forth) and others. As such, MS Office
ones are technically NVDA objects.
Cheers,
Joseph
-----Original Message-----
From: nvda-addons-bounce@xxxxxxxxxxxxx
[mailto:nvda-addons-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Homme
Sent: Tuesday, February 16, 2016 4:40 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
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-s
olutions
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
