I've had one report, from another thread, of the vi text editor, as provided in my dotpet, not working. However, I've tested it on my Puppy 2.17.1 machine and it works perfectly for me.

I'd be grateful if any of you who have used the vi dotpet provided could let me know if it worked okay for you, and on what hardware and Puppy version. If others are having trouble with it, I'd endeavour to find a work around or fix for the problem, but I need more info to sort out what the issue is.

Also, if anyone knows of a modeless full screen commandline usable text editor that doesn't have any status line (which tends to keep being spoken out by yasr/espeak) I'd be happy to hear about it. Not everyone likes vi (!) but I've not been able to find a simple full screen editor which works with yasr/espeak (the ones I have tried don't speak out what is happening on screen or speak out too much junk - such as an ever-changing status line). If you do suggest one, I'd be particularly interested in any special configuration it needs to make it work well with the yasr/espeak screen reader environment (e.g. any option allowing the turning off of the editor's status line).

I've installed Lynx and Vi on 2.14R and both seem to be running OK. I had my doubts about Vi until I found out that you need to press Esc to enter any text! It could appear to be broken if you expected to be able to enter text straight away, which was my first thought. It runs though, which is what you need to know

I've installed Lynx and Vi on 2.14R and both seem to be running OK. I had my doubts about Vi until I found out that you need to press Esc to enter any text!

Thanks, Keef. Yes, vi takes a bit of getting used to since it is not modeless (i.e. it isn't automatically in insert text mode).
The basic commands any user needs in order to use vi are:

1. Either start vi with a filename to edit or tell vi what filename to use later. For example, when writing the edited file to disc at the end you can use the special colon command :w filename
2. Once vi has started, press escape key in order to enter main command mode.
3. Press 'i' key in order to enter insert text mode, or
4. press 'a' key in order to enter append text mode.
5. Press escape key, once you have finished adding text, in order to return to main command mode.
6. Press the special colon command :w followed by pressing enter key in order to write (i.e. save) your file to disc. If you haven't already done so, you need to supply a filename here. For example :w myfile.txt
7. Press the special colon command :q followed by pressing enter key in order to quit vi
8. If you want to quit vi without saving what you have done you need to press the special forcing colon command :q! followed by pressing enter key in order to forcibly quit vi
(i.e. the exclamation mark here means "force").

Note that you can combine the write and quit commands by entering :wq filename

I've now uploaded these instructions to my current screen reader environment repository (at Caneri's site) as the file viREADME.txt, in order to help people get started with using vi:

In addition to viREADME.txt, I've now also uploaded a collection of slightly edited forum posts on edbrowse usage examples in the file edbrowseUSAGEexamples.txt

Hopefully, these will help you learn how to use edbrowse. Note, that I was only learning edbrowse usage myself at the time I wrote these, so you will almost certainly find better ways of doing things.

Remember, once you have installed all the ScreenReaderEnviro dotpets, on whatever Puppy Linux system you are using, you can start up the whole SRE environment under menu control by simply entering the following two commands, one after the other, in a console commandline window:

Sorry for such a quick change/modification/addition to the ScreenReaderEnviro, but I came across a commandline spreadsheet called sc which uses vi-like key-bindings.

Had a bit trouble compiling it (needed to modify xmalloc.c malloc type declaration to void), but that got it compiled.

I can't say sc works with yasr/espeak to my satisfaction, so your mileage will vary, and it probably has a bit of a learning curve (comes with a tutorial though). I admittedly pressed alt-enter to temporarily disable yasr whilst studying sc's tutorial and help instructions in this instance.

EDIT: sc works not too bad afterall, even with yasr. As a test I summed a column of three numbers as follows:

1. I moved to A0 (can use vi controls hjkl or the cursor keys) and pressed 'e' to edit the cell contents.
2. I entered the value 5
3. I similary put the values 7 and 4 in cells A1 and A2 respectively.
4. In cell A3 I entered the formula: @sum(A0:A2)
and the spreadsheet correctly displayed the total = 16.

Anyway, it may prove useful and I've consequently modified/upgraded version numbers of some of the other related dotpets. You thus need to re-download and install:

The documentation provided in this 'first' release is hopefully better than nothing, but not much more than that.

Documentation in itself is a huge job, and even the authors of the provided applications, who have worked on their documentation for years, struggle to provide it in an easy to assimilate form.

As with anything else, there are many conflicting ideas about what style and format of documentation is best.

On Puppy Linux, for install size considerations, it is common practice to strip out as much installed documentation as possible, and to rely on the applications' online documentation.

However, sometimes it is nice to have some local docs available.

I am concerned to keep the SREcore dotpet down in size, so I am now going to create a separate dotpet, SREcoredocs, for documentation alone, so that the user can choose to install it or not. I can however only supply the documentation I have had time to write, or that which the various applications' authors have provided. It is thus up to the individual user to tailor any provided documentation for their own needs. Of course, if users post their own more polished help file efforts, I will select from these for possible inclusion in my to-be-provided SREcoredocs dotpet. Html forms of documentation would be especially nice since they allow easy navigation.

Note well that a major task in writing such documentation is to make it as espeak friendly as possible. For example, the filename of the program I often refer to as "k rec speakk" is really "krecspk" but the latter spelling is very poorly enunciated by e speak. Like wise email is better written in separate syllables as "e mail" and vi as v i. You need to experiment to find the best ways for other symbols and words.

The skeleton menusp program, which I provide, is also due for some simple restructuring related to documentation handling. However, menusp, is only intended as a possible starter template and users are encourage to write their own frontend UI's for their own purposes.

A simple menu, from another project, which illustrates the kind of thing required can be seen at:

http://www.ipsis.hr/gls/about.html
[just over half way down that page]

However, in the case of the S R E there is more than one text editor and browser to be linked to from the menu, so the simple naming scheme of the above link (first referred to by Lobster as far as I know) is probably not quite appropriate.Last edited by mcewanw on Tue 04 Mar 2008, 09:16; edited 6 times in total

Note that the Screen Reader Environment is not intended to be useful solely for blind users. The visually impaired generally and sighted users as well may find it useful. Indeed I often run edbrowse, as a way of reading out webpage text, but maybe quickly visit the same webpage in Seamonkey at the same time, just to have any images visible.

That is, a G U I browser can conveniently provide graphics images, whilst the S R E can read out the page. This is a simpler alternative to the use of any bloated screen-scraper type of solution to transform the text content of a complex G U I browser such as Seamonkey.

Indeed, the above process can easily be automated in a frontend script.
-------------------
You can also highlight any GUI text anywhere and copy it into the cut/paste buffer and execute commands like:

The whole filesystem remains embedded in the one dotpet of size less than 4 MBytes. After installing, start the SRE by entering the following two commands, one after the other:

Code:

initsp
menusp

Much work still needs to be done on the help system files to make them e speak friendly. Having them re written into html form would also be excellent. In the meantime, the available rough documentation remains within SREcore.

I've hopefully written the provided menusp in a way that is easy for anyone to modify, should they so wish. I've intentionally written the menu as a relatively simple and hopefully reasonably structured shell script at this stage, in order to make it more accessible to others who might want to customise it. For example, the key letters used to select categories can be changed to anything that suits.

I've also included what I hope is a complex/flexible enough hierarchical structure to the menu itself (for example, key h for help calls up another menu), to allow for easy adaptation and expansion. The same hierarchical structure can be duplicated elsewhere in the menu to expand it, if you wish, simply by cutting and pasting relevant sections of code appropriately and assigning suitable select keys. A more sophisticated programming technique could have been used, but for now I wanted to keep it in a language many people know.

If any particular user or group of users would like a custom arrangement, but do not know shell scripting, let me know and I'll see if I can help.

Whatever menu arrangement you do use, let me know what works for you. At this stage I'm perfectly happy to include several such menus in the dotpet. A menu such as the provided one takes up very little space, so choice in this case is a good thing I think. Indeed, the next menu may include a choice of "skins". Clearly, a more complex programming technique might be used in the future.

What I'd really like now is better, "blind friendly/ e speak friendly", documentation to replace what is provided currently. Though I've provided a fair amount of documentation from various sources, most of it is admittedly far from adequate, at this stage, in terms of usability and intelligibility when used with e speak.

Unfortunately, I don't have time at present to add much more documentation or to polish up the existing material. Furthermore, I know I'm not the best person to do that job; I'm not blind, and what I think works or sounds adequate may not actually be as good as I think it is. Indeed, no matter my good intentions, I can't trust myself to not occasionally look at the screen! So, I'm hoping some kind volunteers/testers, particularly those from within the blind/visually impaired community, will help in that all important but very complex documentation production and re writing process.

There are inevitably limitations with a package like this, which employs diverse applications, most of which were not written with screen reading in mind, like alone to work compatibly with each other. In that sense, this approach cannot fairly be compared to, for example, emacspeak, which employs the power of one huge but consistent application to do pretty much everything. Nevertheless, I hope that the SRE provides a lot of usable functionality in what is a very small and easily installed package.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum