Re: Extended Winamp and others with no recent author presence: emergency Python 3 compatibility releases to go out this week, community maintenance

Luke Davis

On Tue, 26 Nov 2019, Shaun Everiss wrote:

If you are talking about a legacy mode, either nvda needs to be able to run
Nobody is talking about a legacy mode.
It can't, and it won't. We're talking about the website. The add-ons website: whether to leave add-ons that are stable now, but become non-functional under 2019.3, in the stable section of the website; or whether to maybe move them to a "legacy stable" section or similar.

legacy addons however without any new features or a legacy nvda version for the addons.
Yes, a legacy version. People can run whatever old version of NVDA they want, in order to support whatever add-ons they want. That is not new, and doesn't require any new behavior in NVDA. If you find your special add-on that hasn't been updated requires 2019.2.1, run that. Maybe as portable, just for that specific application.

What would be the issue of including legacy functions in new nvda with the stipulation, that while legacy addons will be able to run for what they were designed for that they could be limited.
What you are asking does not really compute. Including "legacy functions" in NVDA core, in order to use older add-ons, would mean effectively running two different NVDA versions in one container. It really can't be done. Many things have changed in new NVDA (2019.3). An old add-on simply doesn't know how to talk to many of the deep parts of NVDA.
Including code to make them think they are running in an older version of NVDA, is not practical in any kind of way. Additionally, NVDA would have to know the way those add-ons need to receive information, and adapt to them.
What you are asking for is far beyond reasonably possible.
It would be much much easier to hire a team of coders to update all of the add-ons that haven't been updated to work with 2019.3.

I see no issue with legacy application supports like the jgt or other program spaciffic addons like teamtalk though it would be nice if this was updated.
There is no "issue" as far as wanting to support them, but there is an issue of it being technically possible for those old add-ons to continue working with NVDA.
You can't just turn on some compatibility flag, and suddenly have Python 3 behave like Python 2, all the old code that has been removed suddenly come back and work again, and so on.

Computers change over time. Programs and interfaces change over time. NVDA either has to change along with everything else, or its useful life comes to an end. And older add-ons either have to change to continue working hand in hand with NVDA, or they too, will be left behind.

The minimum we can do, is tell people where to find them, and which NVDA version they worked with last. That is what this conversation is about.
The maximum we could do, is rewrite them to work with modern NVDA.
In no case can we make NVDA have some legacy mode, where it "acts" like an older NVDA in order for some old add-on to work.

Now, the add-on itself can try to figure out which NVDA its running in, and adapt itself accordingly, but that isn't what we're talking about here.

It would be nice if things like jgt were modified, but also interactive fiction interpriters.
Saying that, that module, the ifinterpriters has been about for ages and its been stable.
And it's about to become very much unstable. Until somebody updates it to work with a modern version of NVDA, people who need it will have to stick with NVDA 2019.2.1.
You can include it in 2019.3 as an add-on, and it will fail. You can try to insert its "stable" code directly into NVDA core, and NVDA as a whole will fail.
"Stable" does not mean what you seem to think it means.

Stable only means, that the stable thing works, for now, and isn't showing its age. Stable in the context of that add-on, the way you are using it, actually means "more and more out of date and ready to break at any moment".
Stable, in the sense of not receiving updates, does not mean good. In fact, it means bad.

The word you actually mean when you say stable, I think, is "unchanging". But unchanging, not receiving updates, for software that depends on other software (NVDA) in order to work, is actually the worst possible state of affairs, and is very un-stable.

Stable, meaning unchanging--stuck in the past, is not good for an add-on. It means that its time of failure is guaranteed to be on the way, and gets much closer with every tiny NVDA update.

A goofy example of what you are saying is: A life form (add-on) evolves to breath a methane atmosphere. It gets very good at living there, and over millions of years becomes stable. Then some comets full of water and algae crash and the atmosphere undergoes a conversion to oxygen-nitrogen. Your argument with these add-ons, is that because the organism is stable in its breathing methane ways, it should be able to survive in the oxygen-nitrogen atmosphere. But in reality that doesn't happen, because the stable--unevolving organism--doesn't bother learning how to metabolize oxygen. As the air changes, it dies. And that's what's happening to these older add-ons. Unless they evolve to survive in the new software atmosphere, they will die, except for the rare cases where a scientist keeps one in a sealed ecosystem which is specifically designed to work with the organism. In this case, that means running the old add-on in an old NVDA.

Also any addon which you know is unlikely to need to be changed should be
conciddered for core use.
That's what I'm trying to explain. They all, every single add-on, are not only likely to need to be changed, but absolutely, definitely, without a doubt, have to be changed, and with some degree of regularity.

Most game runners probably will not change that much if ever. As long as teamtalk has classic mode and it doesn't seem to be changing any time soon
None of that matters. It's the add-on that has to change, and the add-on that isn't changing.
Windows does change. NVDA does change. As a result, the code needed to support that software, needs to change to keep up with them.
And that means that there needs to be someone, with programming experience and interest enough, to make those changes.
If you include code that is never updated in a huge and complex piece of software like NVDA, eventually it will break NVDA, or cause mystery problems that are hard to track down, at the very least.

If something gets included in core, then the NVDA developers have to commit to maintain it. Maintain doesn't just mean that they look and say "yup, the application still works the same way". They have to make sure the software (add-on, or core app-module) still supports that application, with all of the constant change going on around it in Windows and NVDA as a whole. For that to be justified, the application supported has to be of interest to more than just a few people.

In that situation as long as none of these addons effect system functions which is what we are trying to protect I'd be happy for application addons to not need as rigerous compatability if all they do is support a spaciffic app or groups of apps or something like it.
How do you think those add-ons do what they do? By using "system functions". They use NVDA functions to tell NVDA what to say to the user, to read keyboard input, to read the screen, etc. They completely rely on system and other functions outside their control, in order to be useful. As soon as the add-on's idea of how a function works, differs from the new way that function actually works, everything falls apart.

Compatibility isn't "something nice to have", that we can ignore when it becomes inconvenient. It is something we have to have in order for the add-on to do anything other than take up space on disk.

A Ford Model T transmission is not compatible with a 2019 Ford Focus. They can both drive on the same unchanging road, and so the application the transmission supports hasn't changed. But nobody in his right mind would suggest that we just forgo rigorous compatibility, and stuff that Model T transmission in the Ford Focus because it's the only transmission we have at the moment. Either you build a new transmission to work with a Focus, or rebuild the old one to some how fit in the Focus, or you get content with driving a Model T, where that transmission actually works.

P.S. And if anyone who knows more about cars or planetary science than I do finds those examples ridiculous, well then I don't blame you, LOL.

Join to automatically receive all group messages.