Yep, I agree in all your points. My message was not meant as a complaint, more as a question, weather or not, loading a chunk of scripts with WE would cause the resources on a computer to be eaten up. At the same time, - and this is based on my many years as a programmer - it is in place to remind all script builders, to keep their codes as small and smoothly working as possible. Just because a function is available, doesn't say it has the quickest, smoothest handling of the problem. But that is for another list. Just wanted to bring it out, as I guess more than me has been wondering whether or not all the scripting will cause slow-downs on their system.
----- Original Message ----- From: Darrell Shandrow To: [email protected] Sent: Friday, August 22, 2008 9:32 PM Subject: Re: WE scripts, resources - tech question, and a suggestion Hello David, I'd just like to make a couple of observations to your note about scripting and performance. First, I've run several of the betas with scripting turned completely off for a short time, and only notice a very slight increase in performance with all scripting disabled. Second, simply by running a complex computer operating system like Windows, you have already agreed to the concepts of object-oriented programming and significant amounts of shared code, including all the dependencies that entails. Think about all the DLL files in your \windows directory and many of the program directories under \"program files". Almost all Windows programs can't run independently of any other code; most in fact heavily depend on facilities provided by the operating system itself or other shared code libraries. Now that we have scripting, in fact, it could actually be said that Window-Eyes is acting more like other mainstream software on a typical Windows PC. Even such popular productivity apps as those found in Microsoft Office depend heavily on both shared code and scripting. Finally, you just can't get away from scripting. JAWS would do virtually nothing were the default scripts and all those other third-party offerings removed from the product. In fact, I believe, without the default scripts, those for Internet Explorer and Microsoft Office, I think JAWS would be completely useless for everyone! Your points are well taken, but I think the way GW is doing things now finally brings us into the present with respect to the state of the art in screen reading. ----- Original Message ----- From: David To: WE English mailing list Sent: Friday, August 22, 2008 12:22 PM Subject: WE scripts, resources - tech question, and a suggestion This spring GW finally released the much anticipated WE7, betas, that holds the scripting power. GREAT! I like it, and use several of the scripts frequently, even daily. Many with me... Many a time, when a question comes up - or even a request for some kind of functionality - we are told the same standard reply: "You can do it with a script." At one point, it crossed my mind, GW should have an automated server, that simply spit out that reply, whenever the subject line held the word request, or something. OK, that was an excergerating joke. But the answer often comes anyway. Yes, scripting is powerful,and helpful. My question, though, is how much resources does a script eat? Yep, you geeks, slow down that reply button one sec; I know, it depends on what the script has to do. Some operations naturally will take less resources, copared to more advanced ones. What I am after is, if a certain functionality - i.e redirecting a given keystroke - could be done with a single command in the source code of the software, but now it has the need of a whole script; how much resources are waisted? Even so, we see that many of the scripts, 'depends' on other scripts, like Homer and GWToolkit. This means, that first your computer will have to accept the keystroke, then run the 'redirecting' script, which tells it to run a certain part of say GWToolkit, then return to the redirecting script to see if anything else is to be done about that key - and finally, it can perform whatever it is meant to do, upon that one keystroke. Before you take next bite of your sandwich, do emember to split it apart, to realize what it contains, then take the ham to the fridge to see if it compares with the ham in the package, take it back to your sandwich, look to see if you need to do anything more before eating it, reassemble your sandwich; and take the bite... Get it? Lattely, also several users have noticed trouble with scripts loading. Personally, I think it has something to do with the Beta2; as it started to occur more or less same day as I installed Beta2. Whenever starting WE, you were left with a load of messages saying that your script had an error. You press I-gnore Error, and next script tells you IT has an error. It sure got better in a few days, as the different scripts got their updates, and particularly after downloading/installing Homer script (taht one, I didn't find any setting for to autoupdate, so had to do it all manually). It seems a bit critical to me, that scripts are so dependent on each other, that updating one, but not the other, leaves the user in trouble. Think there is two ways around it. 1) Instead of distributing one big package - GWTooolkit - each 'tool' could be its own small block of source code, that the script builder could download and implement into his script. Wel, not very smooth a solution, so let's take a look on the other one... 2) Could it be possible to have a call in all scripts, (at the beginning of the code), that checked to see if the user has the version of the BASE-script that is needed; and if not, automatically ran an autoupdate on that BASE-script? I.e, I make a script named 'startsound', which is using calls from GWToolkit. When the 'startsound' is initialized, it checks for GWToolkit v6 or later. If not found, it automatically downloads and installs it. In script manager: Could there be a checkbox which read 'autoupdate all scripts'? When checked, all scripts installed would have their autoupdate setting turned on. This would make it easier to ensure the user always has the latest version of whatever scripts he has installed. If, out of some reason, he does not want a given script to autoupdate, he could turn that one off manually, by the already existing, incividual update feature. If you reply to this message it will be delivered to the original sender only. If your reply would benefit others on the list and your message is related to GW Micro, then please consider sending your message to [email protected] so the entire list will receive it. All GW-Info messages are archived at http://www.gwmicro.com/gwinfo, and can be searched through and sorted using the search form at the bottom of the page. If you wish to unsubscribe from this list, send a message to [EMAIL PROTECTED] and include leave gw-info in the body of the message. If you reply to this message it will be delivered to the original sender only. If your reply would benefit others on the list and your message is related to GW Micro, then please consider sending your message to [email protected] so the entire list will receive it. All GW-Info messages are archived at http://www.gwmicro.com/gwinfo, and can be searched through and sorted using the search form at the bottom of the page. If you wish to unsubscribe from this list, send a message to [EMAIL PROTECTED] and include leave gw-info in the body of the message. If you reply to this message it will be delivered to the original sender only. If your reply would benefit others on the list and your message is related to GW Micro, then please consider sending your message to [email protected] so the entire list will receive it. All GW-Info messages are archived at http://www.gwmicro.com/gwinfo, and can be searched through and sorted using the search form at the bottom of the page. If you wish to unsubscribe from this list, send a message to [EMAIL PROTECTED] and include leave gw-info in the body of the message.
