Hi, about add-ons, I had thought on cleaning some of them following the
contributing guidelines posted in the NVDA community wiki by Jame, for
instance, deleting encoding declaration when it's not needed and
selecting Windows format for line endings.
There are add-ons, as placeMarkers and readFeeds, that have dialogs to
copy and restore the configuration for allow to import it when a new
version is done. I opened a ticket time ago, since, when these dialogs
are opened, we can't close NVDA settings dialogs.
If this can't be fixed, we can use another kind of dialog for the add-ons.
Emoticons add-on use a settings dialog to allow to insert emoticons. I
think it will be better to use another kind of dialog, as done in
DayOfWeek, for instance.
Now I have connectivity issues due to my service provider. So I have to
use an USB modem, but when I can, I will work on this if needed.
Thanks.
El 16/02/2016 a las 8:09, Joseph Lee escribió:
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
