headers
rangzen | 1 Mar 2005 10:41

GOK and a different way of show keyboard

Hello to all the list,

first of all : thank you for your work !

and second : sorry for my english :)

I work on pylisiere https://gna.org/projects/pylisiere a virtual keyboard.
When i start this program my first goal was to find a way to write for
people who can only use a binary signal to communicate like people under
Lock-in syndrom or who can only move a finger (up or down, mouvement or
not) or control their breath (breath or not, in or out).
For this, a virtual keyboard wich look like our keyboard with more than
100 keys is unusable, even with automatic advance in the key, it's too
slow ...

My works now looks like the ditionnary who help you to write on cell phone
with predictive words and more than 1 letter per key. This "technlogy" is
called T9 in cell phone. I show my works to an hospital on a livecd wich
is very interested and propose me some tests with disabled people to test
their use of the program.

There is a group of letter by touch so you have to use a dictionnary to
propose the words wich can match with.
Example :
Key 1 : eairs
Key 2 : tnoc
You press 1,1 and 2
Wich word match with [eairs][eairs][tnoc] : set, sin, etc order by number
of use or freq of use in your langage, etc.
You can see a screenshot at http://home.gna.org/pylisiere/
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Bolter | 1 Mar 2005 15:14
Picon
Picon
Favicon

Re: GOK and a different way of show keyboard

Hello and welcome to the list!

GOK has been designed to be highly customizable. I don't know how much 
you know about GOK (and Onscreen Keyboards in general) so I'm not sure 
what to say ;-)

I think you can do what you are attempting by customizing GOK. One area 
of GOK which we haven't had time to implement is described here: 
http://www.gok.ca/morse.html  The figure on this page is not necessarily 
what the user would see, but describes the selection process.  There is 
also something we call Visually Cued Coded Access with generalizes this 
technique (see http://www.gok.ca/concepts.html).

In designing GOK we conceptually separated: Selection Technique, 
Grouping of keys, and Controlling Acts (user->hardware).

Feel free to email me directly with more detailed questions etc.  Maybe 
you could tell me more about pylisiere?  It is interesting that you use 
python, as we have an interest in using that language.

cheers,

David

rangzen wrote:

>Hello to all the list,
>
>first of all : thank you for your work !
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Haneman | 1 Mar 2005 16:26
Picon

Re: GOK and a different way of show keyboard

Hi Rangzen,

It's very nice to hear from you, and thanks for your work on pylisiere.

I agree that we should try to work together.  There are many problems 
which onscreen keyboard will have in common, and GOK is already well 
developed.  Perhaps you saw the '1.0' announcement that was sent to this 
list very recently.

While it is true that scanning a full 'compose'/'qwerty' keyboard one 
key at a time is too slow, GOK supports a variety of scanning methods.  
The row/column scanning which is currently offered for single-switch 
users is much faster, and GOK uses word completion (including 
user-specified dictionaries, and 'learning'), but the maximum input 
speed for this method is still only about 8 words per minute or so. 

One thing which you've probably already discovered is that GOK supports 
multiple 'access methods' for activating its keys.  I've mentioned one, 
above ('automatic scanning'), but for some users with 'locked in 
syndrome' there may be other choices, for instance there have been 
previous experiments connecting a device activated by breathing to a 1-d 
valuator, which demonstrate that useful scanning algorithms can be 
constructed with only one axis, with or without an additional switch.  
The main point is that different 'access methods' will suit users with 
different needs.  GOK is designed to allow new access methods to plug in 
to its framework, and this is an area where you could definitely help us.

While it would certainly be possible to present a set of 
multiple-character buttons using GOK, to produce something that looks 
similar to pylisiere, it might make just as much sense to adapt a new
(Continue reading)

Permalink | Reply | 2 comments |
headers
rangzen | 2 Mar 2005 01:10

Re: GOK and a different way of show keyboard

Thanks for yours positive answers !

Let's start a long email. Once again and a last time :) forgive my english.

Once upon a time ... in a f*****g world. I think on pylisiere for at least
2 years, just like an idea in my head. All start with a book "wrote" by a
man with a lockin syndrom. I was surprised by the sytem used to
communicate. His wife have to count the number of wink. I started thinking
on a better system, i work on computer so i thinking to a program and
thinking and thinking. My uncle had an accident and survive but disabled.
I thought "now wrote it, stop thinking". I start it last year, some hours
of code time to time ... Pylisiere is just a proof of concept but i think
it can work. Now, with what i saw and what i thinking understand on the
need of disabled people, i think that the best way for my ideas, is the
integration of my "work" like a way of input in gok.

Now, pylisiere ...
I use python cause i discover python 3 years ago and i said "Whouah !!!
Bye bye C ! Hello python !". I'm lucky and at work they said "If you want
..." So i use python only for 2 years.

My main goal is to gain time to permit a dialog with more than 8 words per
minute if you have only a binary signal to communicate. The main idea is
to group letters to gain time. And let the computer find what's happens.

The choice in group of letters is free cause i didn't find "the better way".
[abcdefgh][ijklmnopqr] or [abc][def][ghi][jkl][mno] or [et][ianm][svrw] or
etc. I think that the best is to purpose the choice to user.

A big work was the dictionnary. I use SQLite and 2 free dictionnary. 1 big
(Continue reading)

Permalink | Reply | 1 comment |
headers
Samuel Thibault | 3 Mar 2005 01:06
Gravatar

AT-SPI, focus leaving and window IDs

Hi,

There are several things which should be added to AT-SPI to my mind:

- Focus leaving should be reported as well: else gnopernicus for
  instance would keep showing the last accessible widget's content while
  non-accessible windows are active. In that case, gnopernicus would
  then be able to show it can't access the non-accessible window (maybe
  at least show its title).

  It would also permit to launch several at-spi readers: brltty for
  instance now has an at-spi driver so as to be able to read xterms. But
  it needs to know exactly when the focus is on a terminal widget, in
  order to produce display only when needed.

- It would also be useful to be able to get widgets' X-window ID to
  better handle focus.

Regards,
Samuel
Permalink | Reply | 0 comments |
headers
Samuel Thibault | 4 Mar 2005 10:03
Gravatar

Re: AT-SPI, focus leaving and window IDs

Hi,

Kenny Hitt <kenny hittsjunk net> wrote:
> > - Focus leaving should be reported as well: else gnopernicus for
> >   instance would keep showing the last accessible widget's content while
> >   non-accessible windows are active. In that case, gnopernicus would
> >   then be able to show it can't access the non-accessible window (maybe
> >   at least show its title).
> 
> That already happens. The way I realize I have started an app that
> isn't accessable is no speech from Gnopernicus. Using alt-tab to cycle
> through windows will announce the title of the window containing the non
> accessable app.  Using this, it's easy to switch back to the window and
> close the app using alt-f4.

That's quite painy.

And one can't assume that every application running on X-windows will
use at-spi to provide its braille output: it may directly provide it to
BrlAPI, in which case gnopernicus needs to know when to give braille
access back to other BrlAPI applications.

> >   It would also permit to launch several at-spi readers: brltty for
> >   instance now has an at-spi driver so as to be able to read xterms. But
> >   it needs to know exactly when the focus is on a terminal widget, in
> >   order to produce display only when needed.

By 'xterms', I meant gnome-terminal for instance. Other xterms should be
made at-spi accessible as well in some future.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Bill Haneman | 4 Mar 2005 14:07
Picon

Re: Re: AT-SPI, focus leaving and window IDs

Samuel Thibault wrote:

>>That already happens. The way I realize I have started an app that
>>isn't accessable is no speech from Gnopernicus. Using alt-tab to cycle
>>through windows will announce the title of the window containing the non
>>accessable app.  Using this, it's easy to switch back to the window and
>>close the app using alt-f4.
> 
> 
> That's quite painy.

A client can compare the focussed window object with the registered 
accessible applications and determine when an 'inaccessible' application 
has been focussed, already.

What do you want the screen reader to do in this case which it is not 
already doing?

> And one can't assume that every application running on X-windows will
> use at-spi to provide its braille output: it may directly provide it to
> BrlAPI, in which case gnopernicus needs to know when to give braille
> access back to other BrlAPI applications.

I doubt this at least for graphical applications.  As long as 
gnopernicus is using brltty I don't see any conflict here, unless 
there's something I don't understand about brltty which prevents its use 
by multiple clients.

>>>  It would also permit to launch several at-spi readers: brltty for
>>>  instance now has an at-spi driver so as to be able to read xterms. But
(Continue reading)

Permalink | Reply | 7 comments |
headers
Bill Haneman | 4 Mar 2005 14:55
Picon

Detecting focus on a terminal [was Re: Re: AT-SPI, focus leaving and window IDs]

Samual said...
> By 'xterms', I meant gnome-terminal for instance. Other xterms should be
> made at-spi accessible as well in some future.

The way you detect when focus has moved to a terminal is to listen for 
"focus:" events.  When you receive a focus event from an object with 
ROLE_TERMINAL, then a terminal has been focussed.

Any at-spi accessible terminals should provide this information, as 
gnome-terminal now does.

I believe that if you really wanted gnopernicus not to announce terminal 
changes (because, for instance, you want brltty to do it instead), you 
can modify the gnopernicus "presentation settings" to suppress speech 
and/or braille from objects of ROLE_TERMINAL.

So the only remaining issue has to do with sharing of brlapi by clients. 
  I am not aware of any reason why one brlapi client must explicitly 
"release" the braille display before another client can send to it, but 
perhaps there is one...

regards

Bill
Permalink | Reply | 0 comments |
headers
Samuel Thibault | 4 Mar 2005 16:37
Gravatar

Re: Re: AT-SPI, focus leaving and window IDs

Hi,

I reordered things for (hopefully) easier reading.

Bill Haneman, le ven 04 mar 2005 13:07:30 +0000, wrote:
> >>>- It would also be useful to be able to get widgets' X-window ID to
> >>> better handle focus.
> 
> I disagree; I don't know of anything that the XID helps with here.

That's the only ID we can rely on about X applications (including
inaccessible ones).

> A client can compare the focussed window object with the registered 
> accessible applications and determine when an 'inaccessible' application 
> has been focussed, already.

But compare what ? An inaccessible application doesn't register itself
in at-spi (and there will always remain inaccessible applications in the
world). If the register doesn't provide X-window ID, there is no way to
compare accessible application windows and inaccessible application
windows.

> the current implementation is 90% correct because gnopernicus 
> does not send braille commands when non-at-spi-participating 
> applications are focussed.

Well, it stops sending braille output, but that is not sufficient to
distinguish between the case when the current accessible application's
widget doesn't change, and the case when the current accessible
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Mielke | 4 Mar 2005 17:20

Re: Re: AT-SPI, focus leaving and window IDs

[quoted lines by Bill Haneman on 2005/03/04 at 13:07 +0000]

>we expect ALL applications which care about 
>accessibility to participate and cooperate in the at-spi environment.

I think it'd be unreasonable to require a text mode only BrlAPI application to
have a dependency on the graphical environment. I also think it'd be
unreasonable for the basic infrastructure to preclude the possibility of a text
mode only accessible application.

Right now, BrlAPI allows a text mode application to claim the braille display.
It knows which application should be in control of the display, or (the
default) that BRLTTY should be in control of the display, based on the tty
which is currently active. It'd be nice if this same capability were available
for a text mode application running within a terminal window. The default
within a terminal window would be that Gnopernicus is in control of the
display. If, however, a text mode BrlAPI application is running within a
particular terminal window then BrlAPI needs to be able to know/detect this so
that it can give control to that application while its terminal window has the
focus.

--

-- 
Dave Mielke           | 2213 Fox Crescent | I believe that the Bible is the
Phone: 1-613-726-0014 | Ottawa, Ontario   | Word of God. Please contact me
EMail: dave <at> mielke.cc | Canada  K2A 1H7   | if you're concerned about Hell.
http://FamilyRadio.com/                   | http://Mielke.cc/bible/
Permalink | Reply | 5 comments |

Gmane