From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@9fans.net Date: Tue, 21 Oct 2008 15:52:28 +0000 From: Chris Brannon Message-ID: <87ljwim0c2.fsf@cox.net> Content-Type: text/plain; charset=us-ascii References: <5d375e920810202220q1ec3d0abmb549aca65d902f63@mail.gmail.com>, <4056FAF3-2786-4C5A-950C-C27DC1B464D7@mac.com> Subject: Re: [9fans] How to go about doing screen reading Topicbox-Message-UUID: 23976a3a-ead4-11e9-9d60-3106f5b1d025 pietro10@mac.com (Pietro Gagliardi) writes: > In pseudocode: > > when mouse has not been moved for at least 1 second > find cursor position > if cursor has moved *SNIP* > Any technical problems with this approach? I think there is an easier way to do screen reading within Acme. Here's a quote from the Acme paper: The last file, event, is the most unusual. A program reading a window's eventfile is notified of all changes to the text of the window, and is asked to interpret all middle- and right-button actions. The data passed to the program is fixed-format and reports the source of the action (keyboard, mouse, external program, etc.), its location (what was pointed at or modified), and its nature (change, search, execution, etc.). This message, for example, MI15 19 0 4 time reports that actions of the mouse (M) inserted in the body (capital I) the 4 characters of timeat character positions 15 through 19; the zero is a flag word. Programs may apply their own interpretations of searching and execution, or may simply reflect the events back to Acme, by writing them back to the eventfile, to have the default interpretation applied. Some examples of these ideas in action are presented below. A screenreader can obtain information about changes to the state of the system by reading the event file. Do other parts of the window system provide this sort of interface? -- Chris