@LeonarddeR Please delete teamtalk4classic.py.

• System test failure
• Build (for testing PR)

See test results for failed build of commit e86270999a

I'm afraid I have trouble understanding why this PR has been created i.e. what value can it bring to the product. A few facts:

• The last functional commit to these modules dates to 2013 which proves that they are not a maintenance burden in any way.
• The mail clients for which the support is being removed by this PR are still quite popular amongst blind people. They are obviously old and unsupported but that is no business of ours for a several reasons:

• - We are developing a screen reader here not a software which monitors people computers and makes it annoying to use old programs for them.
  

• • If sighted people want to use lets say Outlook Express on Windows 10 we can say they are eccentric and that is all, however with this PR we are making harder (and just because we can) for blind people to use they preferred email client and at the same time take advantage of enhancements in the new versions of NVDA. The argument which often comes up in these discussions is that if someone is using old {insert name of the software here} they're not interested in updating NVDA - since I don't understand where this comes from I'm not going to discuss this further.
• The assumption that if someone really wants to use these apps they can just convert the old appmodule into an add-on is flawed - for most non developers this is not doable. This PR won't also have the desired effect i.e. people using these programs won't magically switch to let's say Thunderbird - they would either be using whatever they're using now without additional support from NVDA getting worse experience, or would stick with old version of NVDA. Some may also switch to the competition because these products aren't removing modules for programs which they already support just for the sake of it.

My personal view is that screen readers should provide access to as many software as possible and limiting it by removing existing code is counter productive. Also I believe that the only sane reason for removing code is when it does not work already and we don't have resources to fix it - otherwise it is just enforcing our software preferences on others which are not knowledgeable enough to enforce theirs on us.

The precedent I followed and Leonard is following is a series of commits which removed XP apps such as old Sound Recorder.

That is not the same situation.
Sound Recorder cannot be used with recent versions of NVDA because these recent versions do not support XP anymore. And I doubt that people try to port this little app unofficially on Windows 7 or 10.
On the contrary, Outlook Express and/or Windows Mail can be used unofficially on Windows 7 and 10; the exe has just to be copied if I remember well. And I have still heard recently someone using this unofficial config on a user mailing list.
Also heard recently of someone using Windows Live Mail.

If these modules are still functional and if they do not require maintenance, I would opt for keeping them in NVDA.

• System test failure
• Build (for testing PR)

See test results for failed build of commit e86270999a

I'm not very surprised with the discussion starting all over again. I have several reasons for this pr:

1. Keeping support for old and legacy software perpetuates insecure behaviour. For all pieces of software are decent and free alternatives.
2. We are enforcing people to look at their code closely with every add-on breaking API change version of NVDA. For every appModule in core, this is the responsibility of NV Access and/or core developers who can't simply afford to do this for legacy apps that are abandoned. I think it is not even legal to distribute this software without Microsoft's concent.

I totally agree with @lukaszgo1.
I don't understand why we'd like to remove support for apps if people could still want to run them on their computer, and if it has no downside on the NVDA development process.

Anyway, removing support for MSN/Windows Live Messenger seems reasonable to me as the protocol is discontinued and there are no reasons to use it in 2021.

@LeonarddeR @lukaszgo1 Are we OK if we only keep the support for Windows Live Mail and remove the others?

The end of support of Windows Live Mail was in 2017 and maybe some people still have it installed on their computer.

I fully support this PR. These legacy apps which are not even supported on current operating systems any more, should no longer have support in NVDA either. As @LeonarddeR points out above, it also creates an immense burden on core and add-on developers to possibly have to take into account these app modules and have no way to test them because the software is either no longer available, or won't install on operating systems they still have access to.

I understand why we take a year of Windows 7 support because that support just recently ended from the Microsoft side. And it is an operating system, so bigger than an individual app. But still supporting apps like these that have been discontinued for years, just feels irresponsible. And these have been decommissioned much longer than Adobe Flash which the team also just removed support for.

My thumbs up for this, and also for what @zstanecic added above.

I really don't see why would we remove Poedit 1 support in favour of something that's less accessible, while this version isn't unsupported in any way and is offered for download. When and if this changes, that can be considered.
Also, as far as I know, Skype 7 support has already been removed in the same PR which removed the XP sound recorder.
For these apps, the majority should be completely fine. I know a few people who use Outlook express or Windows mail, but MSN and old TeamTalk shouldn't really affect anybody at this point. Maybe these two can be reconsidered, but honestly, even Google isn't in favor of using Outlook express anymore and when signing in to GMail, you often get security errors and must manually visit the website to change the security settings.

It is absolutely better to work with the developer and improve the accessibility, I don't think anybody disagrees with this, but removing the support for a clearly more accessible version isn't solving anything. I personally use both, and I see no reason to call this supporting old technologies. It still works on the latest version of Windows and doesn't require any special steps to run.
Old and unsupported apps should be clear cases like the ones in this pull request that are hard to download or get working under versions of Windows NVDA still supports. Poedit 1 is downloadable from it's official website.

Poedit 1 support should be removed. Supporting old technologies is a waste of time.

We all know technology evolve a lot but we shouldn't force user to upgrade if they like a software. This is not because a software is called version 2 we should consider version 1 bad.
This type of argument is in my opinion counter intuitive with the open source philosophy, you say to user, you need to love new software and use them but why user should love them? I think user should decide what they want to use, this is our freedom.
People often consider supporting old technology is a waste of time but it is not, it is supporting users choice and don't force people. In some country technology is not well accepted because we want to force people to change their habits, their software for new one. Most people don't want to care about their computer, they just want to use it.

@nidza07 wrote:

... but honestly, even Google isn't in favor of using Outlook express anymore and when signing in to GMail, you often get security errors and must manually visit the website to change the security settings.

This is exactly why I believe a screen reader shouldn't facilitate the use of outdated and highly discouraged software. I'm not saying we should actively remove support for out of date software. However it is our duty to consider all of our code for an addon API breaking release.

As there are many people complaining about this change and there are several ideas about how to go forward, I"m going to close this pr.

1. It is probably better to discuss every app one by one. Having said that, I think all arguments have been mentioned yet and thus NV Access will have to make the final decision.
2. When we want to keep support for windows live mail while removing support for Outlook Express, we'll have to change the appModule, which is risky.