Re: WE on other platforms. Was: Re: Why Narrator will be better as a Screen Reader
David, I would sum it up this way. The very nature of a screen reader inexorably ties it to the operating system it was written to work on. And that in and of itself precludes it from being ported to any other operating system. Regards, Tom On 8/30/2018 4:16 AM, David wrote: There you are, Tom. Would you agree, if we try to cook it down to something even non-tech people will understand, we might basically explain it all like this? When we see a program well-known to Windows users, all the sudden pop up as an app on IOS or Android - it is NOT because the program itself was ported over. Very basically spoken, the ideas or features of the program, even to some extent the layout, will have been transferred. Yet, the very code behind it all, will likely to a very high extent have been rewritten. Let's try this with an example. Again, let's go to the traffic. When you see a family car rolling down the street, will you then exclaim: Hey, look, a mini truck! Well, in essense, the car has a number of features resembling and quite compatible with those of a truck or bus. They all have four wheels (at least). All have a steering wheel, and they all have windows all around. Still, you please talk to the ingeneers who designed the family car, and ask them if they simply just could down-scale a truck, and let it out the doors. Think of the fact, that your car has breaks that operate on hydraulic system, whereas the truck has air-operated breaks (what is known as pneumatic breaks). The truck definitely is running on a diesel engine, likely your car is on gasolin or even all electric. The truck even might have numerous wheels, tell me if you are the owner of a family car with anything more than four. Obviously, both vihicles have been designed for transportation, with some basics in common. And the designers might likely have used the knowledge from one production, in their work on the other. They might even have a certain similarity, for instance if your family car actually would happen to be a pickup truck. Nonetheless, they are such different constructions that they likely are being produced on separate sites, and your local repair shop might only do work on one of them. You even will have to get a totally different drivers license for each. If you Olusegun are dreaming of seeing a screen reader on Android, which will resemble some - or most - of the features of Window-Eyes, your dreams might be valid enough. If, on the other hand, you think someone could simply just take the code of Window-Eyes and process it through some kind of converter; well, just to break your day, don't even waste your time... :) Even on the Windows platform itself, we find several programming languages. Some three decades ago, I started doing small tasks under one of them, named Basic. Later on I moved on to Turbo Pascal, and when Windows started to become the road of the day, I ran into AutoHotkey. Then came the scripting capability of Window-Eyes, and here the VBScript language became much the standard of most apps. I did look shortly into JScript, and have peeked at some of the codes in Python, and even Pearle. No, i don't expect most readers to recognize much of the names, just want to show you some of the variety - and that is all Windows programming. What I want to stress to you all: Believe me, you won't be able to take code from one of these languages, and simply copy it into the other. There does exist NO converters, whatever your dreams might look like, that would let the one program be ported over to another of these languages. And even for a driven programmer, going from one language over to the other, might be quite confusing. Should I please get two seconds of your day, in showing you one simple example? In one language, the calculations performed inside the code, will always be interpretted from left to right. an expression like: 2 plus 3, multiplied with 4 (2+3*4), would result in the computer taking 2, adding on 3, getting 5; and then multiplying it all with 4, resulting in a grand total of 20. Now, bring that simple expression: 2+3*4 into the other programming language, and your surprise and frustration will be complete. Here the interpretation takes place from right to left. 4 will be multiplied with 3, giving us 12; and 2 will be added, resulting in a grand total of 14. Imagine a code of thousands of lines, where each line will be at best wrongly interpretted - if even recognized at all, and see if your code will run anything like expected. For your information, the free NVDA screen reader is based on Python version 2. The newest Python is in the third generation, but is not fully backward compatible, resulting in NVDA still being transcribed into modern versions of the programming language. And all of this confusion is on one and same platform, Windows. Meaning, it all takes place, based on much the same CPU, and underlaying instructions. Now move to Android, you wi
Re: WE on other platforms. Was: Re: Why Narrator will be better as a Screen Reader
There you are, Tom. Would you agree, if we try to cook it down to something even non-tech people will understand, we might basically explain it all like this? When we see a program well-known to Windows users, all the sudden pop up as an app on IOS or Android - it is NOT because the program itself was ported over. Very basically spoken, the ideas or features of the program, even to some extent the layout, will have been transferred. Yet, the very code behind it all, will likely to a very high extent have been rewritten. Let's try this with an example. Again, let's go to the traffic. When you see a family car rolling down the street, will you then exclaim: Hey, look, a mini truck! Well, in essense, the car has a number of features resembling and quite compatible with those of a truck or bus. They all have four wheels (at least). All have a steering wheel, and they all have windows all around. Still, you please talk to the ingeneers who designed the family car, and ask them if they simply just could down-scale a truck, and let it out the doors. Think of the fact, that your car has breaks that operate on hydraulic system, whereas the truck has air-operated breaks (what is known as pneumatic breaks). The truck definitely is running on a diesel engine, likely your car is on gasolin or even all electric. The truck even might have numerous wheels, tell me if you are the owner of a family car with anything more than four. Obviously, both vihicles have been designed for transportation, with some basics in common. And the designers might likely have used the knowledge from one production, in their work on the other. They might even have a certain similarity, for instance if your family car actually would happen to be a pickup truck. Nonetheless, they are such different constructions that they likely are being produced on separate sites, and your local repair shop might only do work on one of them. You even will have to get a totally different drivers license for each. If you Olusegun are dreaming of seeing a screen reader on Android, which will resemble some - or most - of the features of Window-Eyes, your dreams might be valid enough. If, on the other hand, you think someone could simply just take the code of Window-Eyes and process it through some kind of converter; well, just to break your day, don't even waste your time... :) Even on the Windows platform itself, we find several programming languages. Some three decades ago, I started doing small tasks under one of them, named Basic. Later on I moved on to Turbo Pascal, and when Windows started to become the road of the day, I ran into AutoHotkey. Then came the scripting capability of Window-Eyes, and here the VBScript language became much the standard of most apps. I did look shortly into JScript, and have peeked at some of the codes in Python, and even Pearle. No, i don't expect most readers to recognize much of the names, just want to show you some of the variety - and that is all Windows programming. What I want to stress to you all: Believe me, you won't be able to take code from one of these languages, and simply copy it into the other. There does exist NO converters, whatever your dreams might look like, that would let the one program be ported over to another of these languages. And even for a driven programmer, going from one language over to the other, might be quite confusing. Should I please get two seconds of your day, in showing you one simple example? In one language, the calculations performed inside the code, will always be interpretted from left to right. an expression like: 2 plus 3, multiplied with 4 (2+3*4), would result in the computer taking 2, adding on 3, getting 5; and then multiplying it all with 4, resulting in a grand total of 20. Now, bring that simple expression: 2+3*4 into the other programming language, and your surprise and frustration will be complete. Here the interpretation takes place from right to left. 4 will be multiplied with 3, giving us 12; and 2 will be added, resulting in a grand total of 14. Imagine a code of thousands of lines, where each line will be at best wrongly interpretted - if even recognized at all, and see if your code will run anything like expected. For your information, the free NVDA screen reader is based on Python version 2. The newest Python is in the third generation, but is not fully backward compatible, resulting in NVDA still being transcribed into modern versions of the programming language. And all of this confusion is on one and same platform, Windows. Meaning, it all takes place, based on much the same CPU, and underlaying instructions. Now move to Android, you will have a totally different CPU, with its very own set of instructions. Or, take it to IOS, and see what Apple will want to comprehend of your code. Oh, let's just illustrate once again. The sailor meets with the pilot, and t
