Topics

Concern about terminology in developer guides

 

    Hello all, particularly Joseph and Luke,


Cross posting to both the add-ons list and the development list, as I think this concern both applies to add-on development and NVDA development in general.


While reading the add-on developer guide (I actually never did so before), I came across the following note:


Note: add-ons are sometimes called "Plugins", especially in the [NVDA Developer Guide]. In general, we will call them add-ons in this guide for the sake of clarity, but just be aware that they are the same thing.


I tend to disagree with this. First of all, let's start with what the official dev guide says about plugins


Plugins allow you to customize the way NVDA behaves overall or within a particular application.

....

There are two types of plugins. These are:
- App Modules: code specific to a particular application.
The App Module receives all events for a particular application, even if that application is not currently active.
When the application is active, any commands that the App Module has bound to key presses or other input can be executed by the user.
- Global Plugins: code global to NVDA; i.e. it is used in all applications.
Global Plugins Receive all events for all controls in the Operating System.
Any commands bound by a Global Plugin can be executed by the user wherever they are in the operating system, regardless of application.


So, what the NVDA developer guide tells us, is that there are several types of plugins. The NVDA developer guide only names two types, but I think there's much to say to distinguish five of them: appModules, globalPlugins, synthDrivers, brailleDisplayDrivers and visionEnhancementProviders


Anyway, I think an add-on should be described as a bundle of plugins, most of the time only containing one plugin, but in case of win ten apps for example, there are lots of plugins in one add-on. Therefore, what the add-on developer guide calls add-on modules, might be better to describe as what the nvda dev guide calls plugins.


Furthermore, a module and a plugin don't have to be the same either. A plugin is what NVDA uses, appModule, globalPlugin, etc. A module can also be a helper module, a plugin could also be a python package with several sub modules.


Any thoughts on this and on how to improve this documentation?


Regards,

Leonard

Brian's Mail list account
 

Does it matter what is under the hood to the end user, so what you really need in the developer guide is some explanation as you have just given, to rationalise the over simplified term add on because as you say the function of an add on can be many, or indeed very specific to an application, but in many cases the desired result can only be achieved by a mixture of many methods, such as redefining an app module or creating whole new functions.

Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Leonard de Ruijter" <@leonardder>
To: <nvda-addons@nvda-addons.groups.io>; <nvda-devel@groups.io>
Sent: Thursday, October 31, 2019 10:09 AM
Subject: [nvda-devel] Concern about terminology in developer guides


Hello all, particularly Joseph and Luke,


Cross posting to both the add-ons list and the development list, as I
think this concern both applies to add-on development and NVDA
development in general.


While reading the add-on developer guide (I actually never did so
before), I came across the following note:


Note: add-ons are sometimes called "Plugins", especially in the [NVDA
Developer Guide]. In general, we will call them add-ons in this guide
for the sake of clarity, but just be aware that they are the same thing.


I tend to disagree with this. First of all, let's start with what the
official dev guide says about plugins


Plugins allow you to customize the way NVDA behaves overall or within a
particular application.

....

There are two types of plugins. These are:
- App Modules: code specific to a particular application.
The App Module receives all events for a particular application, even if
that application is not currently active.
When the application is active, any commands that the App Module has
bound to key presses or other input can be executed by the user.
- Global Plugins: code global to NVDA; i.e. it is used in all applications.
Global Plugins Receive all events for all controls in the Operating System.
Any commands bound by a Global Plugin can be executed by the user
wherever they are in the operating system, regardless of application.


So, what the NVDA developer guide tells us, is that there are several
types of plugins. The NVDA developer guide only names two types, but I
think there's much to say to distinguish five of them: appModules,
globalPlugins, synthDrivers, brailleDisplayDrivers and
visionEnhancementProviders


Anyway, I think an add-on should be described as a bundle of plugins,
most of the time only containing one plugin, but in case of win ten apps
for example, there are lots of plugins in one add-on. Therefore, what
the add-on developer guide calls add-on modules, might be better to
describe as what the nvda dev guide calls plugins.


Furthermore, a module and a plugin don't have to be the same either. A
plugin is what NVDA uses, appModule, globalPlugin, etc. A module can
also be a helper module, a plugin could also be a python package with
several sub modules.


Any thoughts on this and on how to improve this documentation?


Regards,

Leonard



Luke Davis
 

On Thu, 31 Oct 2019, Leonard de Ruijter wrote:

While reading the add-on developer guide (I actually never did so before), I came across the following note:
Note: add-ons are sometimes called "Plugins", especially in the [NVDA Developer Guide]. In general, we will call them add-ons in this guide for the sake of
clarity, but just be aware that they are the same thing.
I wrote that section with the thought of very new developers in mind, trying to cut down on information overload and eliminate confusion.

Plugins allow you to customize the way NVDA behaves overall or within a particular application.
Which is the very definition of an add-on as well, is it not?

Was that written before we called them add-ons, or is add-on just not the preferred term from a development prospective?

There are two types of plugins. These are:
Well, as you don't quite say, that just isn't true--there are four or five types. But the main Dev Guide seems to only want to talk about those two types, at least in that area.

Anyway, I think an add-on should be described as a bundle of plugins, most of the time only containing one plugin, but in case of win ten apps for example,
there are lots of plugins in one add-on. Therefore, what the add-on developer guide calls add-on modules, might be better to describe as what the nvda dev
guide calls plugins.
I think there is merit in this. If I remember right, I used the already accepted terminology when I was expanding those sections, based on what was there before and I assumed was well understood by the community already. But at least at the moment I am in favor of revising this according to what you say. I would like to hear Joseph's thoughts though.

Effectively we would be restricting the term module to its more pythonic use, which I don't find objectionable. App Module is really just another way of saying App Plugin anyway.

Furthermore, a module and a plugin don't have to be the same either. A plugin is what NVDA uses, appModule, globalPlugin, etc. A module can also be a helper
module, a plugin could also be a python package with several sub modules.
I am not sure about that last bit. What is the context for "a plugin could also be a python package with several sub modules." as different from the way that NVDA uses the word plugin?

Any thoughts on this and on how to improve this documentation?
I can improve the add-on dev guide later today. I haven't read the main dev guide in quite a while, so I am not sure what it says about the other kinds of plugins (synth drivers, etc.), but I think it should talk more about those in the section you quoted, even if it is just to point to other sections.

Luke

zvonimir stanečić, 9a5dsz
 

Hi to all!
Let me give my two points regarding this as a translator:
1. Plugin and addon are two completely different things. Add-on implies a
bundle of global plugin, speech synthesizer or app module.
2. that's I distinguish two terminologies.
So, in polish we have a distinct terms: wtyczka and dodatek.
In Croatian, it is one word.

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Luke Davis
Sent: Thursday, October 31, 2019 11:52 AM
To: nvda-devel@groups.io
Cc: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-devel] Concern about terminology in developer guides

On Thu, 31 Oct 2019, Leonard de Ruijter wrote:

While reading the add-on developer guide (I actually never did so before),
I came across the following note:

Note: add-ons are sometimes called "Plugins", especially in the [NVDA
Developer Guide]. In general, we will call them add-ons in this guide for
the sake of clarity, but just be aware that they are the same thing.

I wrote that section with the thought of very new developers in mind, trying
to cut down on information overload and eliminate confusion.

Plugins allow you to customize the way NVDA behaves overall or within a
particular application.

Which is the very definition of an add-on as well, is it not?

Was that written before we called them add-ons, or is add-on just not the
preferred term from a development prospective?

There are two types of plugins. These are:
Well, as you don't quite say, that just isn't true--there are four or five
types. But the main Dev Guide seems to only want to talk about those two
types, at least in that area.

Anyway, I think an add-on should be described as a bundle of plugins,
most of the time only containing one plugin, but in case of win ten
apps for example, there are lots of plugins in one add-on. Therefore, what
the add-on developer guide calls add-on modules, might be better to describe
as what the nvda dev guide calls plugins.

I think there is merit in this. If I remember right, I used the already
accepted terminology when I was expanding those sections, based on what was
there before and I assumed was well understood by the community already. But
at least at the moment I am in favor of revising this according to what you
say. I would like to hear Joseph's thoughts though.

Effectively we would be restricting the term module to its more pythonic
use, which I don't find objectionable. App Module is really just another way
of saying App Plugin anyway.

Furthermore, a module and a plugin don't have to be the same either. A
plugin is what NVDA uses, appModule, globalPlugin, etc. A module can also
be a helper module, a plugin could also be a python package with several sub
modules.

I am not sure about that last bit. What is the context for "a plugin could
also be a python package with several sub modules." as different from the
way that NVDA uses the word plugin?

Any thoughts on this and on how to improve this documentation?
I can improve the add-on dev guide later today. I haven't read the main dev
guide in quite a while, so I am not sure what it says about the other kinds
of plugins (synth drivers, etc.), but I think it should talk more about
those in the section you quoted, even if it is just to point to other
sections.

Luke

 

Thanks for the quick reply, Luke!


Plugins allow you to customize the way NVDA behaves overall or within a particular application.

Which is the very definition of an add-on as well, is it not?


I see what you mean. You could swap the word plugin by add-on in this example, however still, strictly spoken it's not the add-on itself that changes the behavior, but the plugins in the add-on. The add-on is the container that bundles the plugins.


Thinking more aboutthis, I see how the community has gotten used to this way of using the word add-on. We have an add-on development list, we're developing add-ons, which are in fact the plugins that are bundled in add-ons.


Was that written before we called them add-ons, or is add-on just not the preferred term from a development prospective?


Likely the former, yes. I think talking about add-on development is fine, as long as we do'nt say that plugins and add-ons are the same. From one perspective this might be the case, for the other perspective it is not.



there are lots of plugins in one add-on. Therefore, what the add-on developer guide calls add-on modules, might be better to describe as what the nvda dev
guide calls plugins.

I think there is merit in this. If I remember right, I used the already accepted terminology when I was expanding those sections, based on what was there before and I assumed was well understood by the community already. But at least at the moment I am in favor of revising this according to what you say. I would like to hear Joseph's thoughts though.


Thanks!

Effectively we would be restricting the term module to its more pythonic use, which I don't find objectionable. App Module is really just another way of saying App Plugin anyway.


Yes, that makes sense.


Furthermore, a module and a plugin don't have to be the same either. A plugin is what NVDA uses, appModule, globalPlugin, etc. A module can also be a helper
module, a plugin could also be a python package with several sub modules.

I am not sure about that last bit. What is the context for "a plugin could also be a python package with several sub modules." as different from the way that NVDA uses the word plugin?
For example, the NVDA Remote add-on contains one plugin: this plugin is a package with several python submodules, one for the gui, one for the callback manager, etc.


Regards,

Leonard

 

Hi,

The term “plugin” was in use way before the concept of “add-on” was defined by NVDA community in 2012. Since add-on development guide was written way later than NVDA Core development guide, I implied they are the same.

I think one possible way to reduce this confusion is adding an explanation that says that, although at first glance, plugins and add-ons are the same, they are really not, then give the proposed definition by Leonard. Another way is to provide a synonym for “plugin” such as “component” or “parts”, and add an explanation that add-ons can be made up of parts or a collection of plugins.

By the way, I think the original message wasn’t received by add-ons list.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Thursday, October 31, 2019 5:15 AM
To: nvda-devel@groups.io
Cc: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-devel] Concern about terminology in developer guides

 

Thanks for the quick reply, Luke!



Plugins allow you to customize the way NVDA behaves overall or within a particular application.


Which is the very definition of an add-on as well, is it not?

 

I see what you mean. You could swap the word plugin by add-on in this example, however still, strictly spoken it's not the add-on itself that changes the behavior, but the plugins in the add-on. The add-on is the container that bundles the plugins.

 

Thinking more aboutthis, I see how the community has gotten used to this way of using the word add-on. We have an add-on development list, we're developing add-ons, which are in fact the plugins that are bundled in add-ons.

 

Was that written before we called them add-ons, or is add-on just not the preferred term from a development prospective?

 

Likely the former, yes. I think talking about add-on development is fine, as long as we do'nt say that plugins and add-ons are the same. From one perspective this might be the case, for the other perspective it is not.

 



there are lots of plugins in one add-on. Therefore, what the add-on developer guide calls add-on modules, might be better to describe as what the nvda dev
guide calls plugins.


I think there is merit in this. If I remember right, I used the already accepted terminology when I was expanding those sections, based on what was there before and I assumed was well understood by the community already. But at least at the moment I am in favor of revising this according to what you say. I would like to hear Joseph's thoughts though.

 

Thanks!

Effectively we would be restricting the term module to its more pythonic use, which I don't find objectionable. App Module is really just another way of saying App Plugin anyway.

 

Yes, that makes sense.



Furthermore, a module and a plugin don't have to be the same either. A plugin is what NVDA uses, appModule, globalPlugin, etc. A module can also be a helper
module, a plugin could also be a python package with several sub modules.


I am not sure about that last bit. What is the context for "a plugin could also be a python package with several sub modules." as different from the way that NVDA uses the word plugin?

For example, the NVDA Remote add-on contains one plugin: this plugin is a package with several python submodules, one for the gui, one for the callback manager, etc.

 

Regards,

Leonard

zvonimir stanečić, 9a5dsz
 

Hi,

A term part would make confusion in the slavic language, as it is a piece.

Term component or module will be better here.

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Thursday, October 31, 2019 2:39 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Concern about terminology in developer guides

 

Hi,

The term “plugin” was in use way before the concept of “add-on” was defined by NVDA community in 2012. Since add-on development guide was written way later than NVDA Core development guide, I implied they are the same.

I think one possible way to reduce this confusion is adding an explanation that says that, although at first glance, plugins and add-ons are the same, they are really not, then give the proposed definition by Leonard. Another way is to provide a synonym for “plugin” such as “component” or “parts”, and add an explanation that add-ons can be made up of parts or a collection of plugins.

By the way, I think the original message wasn’t received by add-ons list.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Thursday, October 31, 2019 5:15 AM
To: nvda-devel@groups.io
Cc: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-devel] Concern about terminology in developer guides

 

Thanks for the quick reply, Luke!

 

Plugins allow you to customize the way NVDA behaves overall or within a particular application.


Which is the very definition of an add-on as well, is it not?

 

I see what you mean. You could swap the word plugin by add-on in this example, however still, strictly spoken it's not the add-on itself that changes the behavior, but the plugins in the add-on. The add-on is the container that bundles the plugins.

 

Thinking more aboutthis, I see how the community has gotten used to this way of using the word add-on. We have an add-on development list, we're developing add-ons, which are in fact the plugins that are bundled in add-ons.

 

Was that written before we called them add-ons, or is add-on just not the preferred term from a development prospective?

 

Likely the former, yes. I think talking about add-on development is fine, as long as we do'nt say that plugins and add-ons are the same. From one perspective this might be the case, for the other perspective it is not.

 

 

there are lots of plugins in one add-on. Therefore, what the add-on developer guide calls add-on modules, might be better to describe as what the nvda dev
guide calls plugins.


I think there is merit in this. If I remember right, I used the already accepted terminology when I was expanding those sections, based on what was there before and I assumed was well understood by the community already. But at least at the moment I am in favor of revising this according to what you say. I would like to hear Joseph's thoughts though.

 

Thanks!

Effectively we would be restricting the term module to its more pythonic use, which I don't find objectionable. App Module is really just another way of saying App Plugin anyway.

 

Yes, that makes sense.

 

Furthermore, a module and a plugin don't have to be the same either. A plugin is what NVDA uses, appModule, globalPlugin, etc. A module can also be a helper
module, a plugin could also be a python package with several sub modules.


I am not sure about that last bit. What is the context for "a plugin could also be a python package with several sub modules." as different from the way that NVDA uses the word plugin?

For example, the NVDA Remote add-on contains one plugin: this plugin is a package with several python submodules, one for the gui, one for the callback manager, etc.

 

Regards,

Leonard

Travis Siegel
 

And, this is exactly why I've given up entirely on trying to get the NVDA community to clarify, identify, or just explain things more clearly, because there's always push back like this saying that what is there is just fine, and changing things would just cause confusion or take too much time, or something else equally silly.  I no longer have any interest in trying to improve NVDA in any way, I use it, yes, and I will continue to do so, but I have no interest in arguing with an entire group of developers/users who feel like that's the way it's always been done is an acceptable method of defense.  I'm sure this will piss off a lot of people, but quite honestly, at this point, I just don't care anymore.  I'm getting old enough now that this kind of nonsense isn't worth my attention, I've got better things to do with my time than butt heads with people who can't tell the difference between an actual version vs. an arbitrary one that doesn't exist yet.

On 10/31/2019 6:34 AM, Brian's Mail list account via Groups.Io wrote:
Does it matter what is under the hood to the end user, so what you really need in the developer guide is some explanation as you have just given, to rationalise the over simplified term add on because as you say the function of an add on can be many, or indeed very specific to an application, but in many cases the desired result can only be achieved by a mixture of many methods, such as redefining an app module or creating whole new functions.

Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message ----- From: "Leonard de Ruijter" <@leonardder>
To: <nvda-addons@nvda-addons.groups.io>; <nvda-devel@groups.io>
Sent: Thursday, October 31, 2019 10:09 AM
Subject: [nvda-devel] Concern about terminology in developer guides


Hello all, particularly Joseph and Luke,


Cross posting to both the add-ons list and the development list, as I
think this concern both applies to add-on development and NVDA
development in general.


While reading the add-on developer guide (I actually never did so
before), I came across the following note:


Note: add-ons are sometimes called "Plugins", especially in the [NVDA
Developer Guide]. In general, we will call them add-ons in this guide
for the sake of clarity, but just be aware that they are the same thing.


I tend to disagree with this. First of all, let's start with what the
official dev guide says about plugins


Plugins allow you to customize the way NVDA behaves overall or within a
particular application.

....

There are two types of plugins. These are:
- App Modules: code specific to a particular application.
The App Module receives all events for a particular application, even if
that application is not currently active.
When the application is active, any commands that the App Module has
bound to key presses or other input can be executed by the user.
- Global Plugins: code global to NVDA; i.e. it is used in all applications.
Global Plugins Receive all events for all controls in the Operating System.
Any commands bound by a Global Plugin can be executed by the user
wherever they are in the operating system, regardless of application.


So, what the NVDA developer guide tells us, is that there are several
types of plugins. The NVDA developer guide only names two types, but I
think there's much to say to distinguish five of them: appModules,
globalPlugins, synthDrivers, brailleDisplayDrivers and
visionEnhancementProviders


Anyway, I think an add-on should be described as a bundle of plugins,
most of the time only containing one plugin, but in case of win ten apps
for example, there are lots of plugins in one add-on. Therefore, what
the add-on developer guide calls add-on modules, might be better to
describe as what the nvda dev guide calls plugins.


Furthermore, a module and a plugin don't have to be the same either. A
plugin is what NVDA uses, appModule, globalPlugin, etc. A module can
also be a helper module, a plugin could also be a python package with
several sub modules.


Any thoughts on this and on how to improve this documentation?


Regards,

Leonard






--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Karl-Otto Rosenqvist
 

Hi!
As a new developer of NVDA app modules I would say that Add-ons are a way of packaging app modules, global plugins and drivers for braile displays and speech syntersizers.

You can distribute plugins and drivers stand-alone and the users have to put the files in their correct folders in order to get them up and running. Equivalent with distributing an application in a zip-file.
Packaging plugins and drivers in an add-on it would be equivalent with using an installation program. It ensures your installing it on an operating system it supports, if there's already a version installed, that the plugins and drivers your about to install are compatible with other components such as NVDA and places the files in the appropriate place without the user having to know anything about it.

Add-on = Packaging and distribution
Plugin and driver = Modules/components/code/libraries (call it whatever sounds appropriate in each language) that do the actual work


Kind regards

Karl-Otto

Karl-Otto Rosenqvist
MAWINGU
Orgnr: 750804-3937
+46 (0)701 75 98 56
karl-otto@...

Den 2019-10-31 kl. 17:33, skrev Travis Siegel:

And, this is exactly why I've given up entirely on trying to get the NVDA community to clarify, identify, or just explain things more clearly, because there's always push back like this saying that what is there is just fine, and changing things would just cause confusion or take too much time, or something else equally silly.  I no longer have any interest in trying to improve NVDA in any way, I use it, yes, and I will continue to do so, but I have no interest in arguing with an entire group of developers/users who feel like that's the way it's always been done is an acceptable method of defense.  I'm sure this will piss off a lot of people, but quite honestly, at this point, I just don't care anymore.  I'm getting old enough now that this kind of nonsense isn't worth my attention, I've got better things to do with my time than butt heads with people who can't tell the difference between an actual version vs. an arbitrary one that doesn't exist yet.
On 10/31/2019 6:34 AM, Brian's Mail list account via Groups.Io wrote:
Does it matter what is under the hood to the end user, so what you really need in the developer guide is some explanation as you have just given, to rationalise the over simplified term add on because as you say the function of an add on can be many, or indeed very specific to an application, but in many cases the desired result can only be achieved by a mixture of many methods, such as redefining an app module or creating whole new functions.

Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message ----- From: "Leonard de Ruijter" <@leonardder>
To: <nvda-addons@nvda-addons.groups.io>; <nvda-devel@groups.io>
Sent: Thursday, October 31, 2019 10:09 AM
Subject: [nvda-devel] Concern about terminology in developer guides


Hello all, particularly Joseph and Luke,


Cross posting to both the add-ons list and the development list, as I
think this concern both applies to add-on development and NVDA
development in general.


While reading the add-on developer guide (I actually never did so
before), I came across the following note:


Note: add-ons are sometimes called "Plugins", especially in the [NVDA
Developer Guide]. In general, we will call them add-ons in this guide
for the sake of clarity, but just be aware that they are the same thing.


I tend to disagree with this. First of all, let's start with what the
official dev guide says about plugins


Plugins allow you to customize the way NVDA behaves overall or within a
particular application.

....

There are two types of plugins. These are:
- App Modules: code specific to a particular application.
The App Module receives all events for a particular application, even if
that application is not currently active.
When the application is active, any commands that the App Module has
bound to key presses or other input can be executed by the user.
- Global Plugins: code global to NVDA; i.e. it is used in all applications.
Global Plugins Receive all events for all controls in the Operating System.
Any commands bound by a Global Plugin can be executed by the user
wherever they are in the operating system, regardless of application.


So, what the NVDA developer guide tells us, is that there are several
types of plugins. The NVDA developer guide only names two types, but I
think there's much to say to distinguish five of them: appModules,
globalPlugins, synthDrivers, brailleDisplayDrivers and
visionEnhancementProviders


Anyway, I think an add-on should be described as a bundle of plugins,
most of the time only containing one plugin, but in case of win ten apps
for example, there are lots of plugins in one add-on. Therefore, what
the add-on developer guide calls add-on modules, might be better to
describe as what the nvda dev guide calls plugins.


Furthermore, a module and a plugin don't have to be the same either. A
plugin is what NVDA uses, appModule, globalPlugin, etc. A module can
also be a helper module, a plugin could also be a python package with
several sub modules.


Any thoughts on this and on how to improve this documentation?


Regards,

Leonard