devel@groups.io | NVDA Core: things to deprecate, things to keep for a little longer, sorting through a soil of mixed styles and expectations (2024)

#39647

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

#39651

#39652

-----Original Message-----
From: Brian's Mail list account BY [mailto:bglists@...498...]
Sent: Tuesday, February 16, 2016 1:30 AM
To: NVDA screen reader development <nvda-devel@...>
Subject: Re: [Nvda-devel] NVDA Core: things to deprecate, things to keep for
a little longer, sorting through a soil of mixed styles and expectations

Just one comment here, aye the answer is to create another test branch that
as many people with varied machines, o/s and other things can use based on
master and then if anything weird presents itself, you are less likely to
miss it before it kind of gets buried and becomes very hard to trace later
on.

I was just thinking the other day that if nvda needs to go on, lots of info
about bits of it need to be grabbed and held somewhere as there is nothing
worse than a new coder trying to understand what on earth others did and
their thought processes at that time, if they are no longer around to
answer the question.

I'm not up to being a coder these days, but back in the 1980s, I found this
problem when trying to make somebody elses program do something differently
or expand it.
Brian

--------------------------------------------------
From: "Joseph Lee" <joseph.lee22590@...12...>
Sent: Tuesday, February 16, 2016 7:09 AM
To: "'NVDA screen reader development'" <nvda-devel@...>
Cc: <nvda-addons@...10...>
Subject: [Nvda-devel] NVDA Core: things to deprecate,things to keep for a
little longer,sorting through a soil of mixed styles and expectations

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

----------------------------------------------------------------------
--------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

_______________________________________________
Nvda-devel mailing list
Nvda-devel@...
https://lists.sourceforge.net/lists/listinfo/nvda-devel

bglists@...5308...
via blueyonder.
Please address personal email to:-
briang1@...498..., putting 'Brian Gaff'
in the display name field.

----------------------------------------------------------------------------
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
Nvda-devel@...
https://lists.sourceforge.net/lists/listinfo/nvda-devel

#39655

#39657

-----Original Message-----
From: Brian's Mail list account BY [mailto:bglists@...498...]
Sent: Tuesday, February 16, 2016 8:15 AM
To: NVDA screen reader development <nvda-devel@...>
Subject: Re: [Nvda-devel] NVDA Core: things to deprecate, things to keep for
a little longer, sorting through a soil of mixed styles and expectations

What I meant was if you accidentally remove something which was marked for
deletion but something still used it, say an old add on.
Brian

--------------------------------------------------
From: "Joseph Lee" <joseph.lee22590@...12...>
Sent: Tuesday, February 16, 2016 9:35 AM
To: "'NVDA screen reader development'" <nvda-devel@...>
Subject: Re: [Nvda-devel] NVDA Core: things to deprecate,things to keep for
a little longer,sorting through a soil of mixed styles and expectations

Hi,
It won't be features that'll be going away (that is quite drastic).
What I'm proposing is for us to clean up code paths (which are
variables, import statements, functions and so on) that are clearly
marked for deprecation and removal. All the work will be done from a
separate branch.
Cheers,
Joseph

-----Original Message-----
From: Brian's Mail list account BY [mailto:bglists@...498...]
Sent: Tuesday, February 16, 2016 1:30 AM
To: NVDA screen reader development <nvda-devel@...>
Subject: Re: [Nvda-devel] NVDA Core: things to deprecate, things to
keep for a little longer, sorting through a soil of mixed styles and
expectations

Just one comment here, aye the answer is to create another test
branch that as many people with varied machines, o/s and other things
can use based on master and then if anything weird presents itself,
you are less likely to miss it before it kind of gets buried and
becomes very hard to trace later on.

I was just thinking the other day that if nvda needs to go on, lots of
info about bits of it need to be grabbed and held somewhere as there
is nothing worse than a new coder trying to understand what on earth
others did and their thought processes at that time, if they are no
longer around to answer the question.

I'm not up to being a coder these days, but back in the 1980s, I
found this problem when trying to make somebody elses program do
something differently or expand it.
Brian

--------------------------------------------------
From: "Joseph Lee" <joseph.lee22590@...12...>
Sent: Tuesday, February 16, 2016 7:09 AM
To: "'NVDA screen reader development'"
<nvda-devel@...>
Cc: <nvda-addons@...10...>
Subject: [Nvda-devel] NVDA Core: things to deprecate,things to keep
for a little longer,sorting through a soil of mixed styles and
expectations

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

---------------------------------------------------------------------
-
--------
Site24x7 APM Insight: Get Deep Visibility into Application
Performance APM + Mobile APM + RUM: Monitor 3 App instances at just
$35/Month Monitor end-to-end web transactions and take corrective
actions now Troubleshoot faster and improve end-user experience. Signup

Now!

http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

_______________________________________________
Nvda-devel mailing list
Nvda-devel@...
https://lists.sourceforge.net/lists/listinfo/nvda-devel

bglists@...5308...
via blueyonder.
Please address personal email to:-
briang1@...498..., putting 'Brian Gaff'
in the display name field.

----------------------------------------------------------------------
------
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
Nvda-devel@...
https://lists.sourceforge.net/lists/listinfo/nvda-devel

----------------------------------------------------------------------
--------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
Nvda-devel@...
https://lists.sourceforge.net/lists/listinfo/nvda-devel

bglists@...5308...
via blueyonder.
Please address personal email to:-
briang1@...498..., putting 'Brian Gaff'
in the display name field.

----------------------------------------------------------------------------
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
Nvda-devel@...
https://lists.sourceforge.net/lists/listinfo/nvda-devel