Bill Haneman wrote: > SOK doesn't support any kind of switch-only user, nor does it support > scanning users. It can only support users who can both point with high > accuracy, and click. > What is the difference between a 'switch-only' user and a 'scanning' user? I would assume that someone who uses one or two simple switches to interact with the computer would want their on-screen keyboard to work in scanning mode. Otherwise we are talking about morse code entry or similar and that's beyond the scope of an on-screen keyboard IMO.
There is no reason SOK cannot support scanning modes. We are currently working on a simple implementation that will be ready by the 6.10 release and we will add support for more input devices later. > You will find that the pointer-grab problem will defeat many of your > cases if you try to access menus and control programs via AT-SPI. > Do you have any specific cases of this that I can test? I'd like to see the problem for myself so I can start thinking about a solution. > Toolkit maintainers and authors argue very convincingly that the > problematic behaviors regarding pointer grabs are NOT bugs. > One advantage of being a distro is that we can override those decisions and apply our own patches. Our core developers are getting quite clued in on accessibility needs now, so I don't see a problem in getting this through on the Ubuntu side for each case where there is a problem (we are addressing several similar issues already, like the screen grab by the admin app password window). If the patches are well made and can be activated via gconf-settings or flags (ie optional) then I see no reason why upstream would not take them. > After years of dealing intimately with these problems I am 100% > convinced that any OSK technology that doesn't use some alternative > means of avoiding these pointer grabs is doomed to fail for these users. > OK, I'm less convinced :) Our plan is to go ahead with the new technology and deal with the problems as they arise. We are already getting input from several OSK users and hope that will continue so we can fix problems as they occur. In the meantime we hope we are providing a system with better general usability. > For a pointing-only user (who cannot perform a mouse click), these are > lockout scenarios which effectively hang their desktop sessions, so > these problems are very serious indeed. > Right, so SOK does not have dwell support ATM, but I think we should work to get dwell selection in as an option in the default X mouse drivers so that it can be useful everywhere. I guess KmouseTool does that, but I'm not sure if it works in Gnome. > I like this idea. Making AT-SPI load dynamically is theoretically > possible but there are some real feasibility issues; > What are the real feasibility issues? Are they mention in the RFE entry perhaps (link?). Perhaps we can do some brain-storming on them and look for solutions? - Henrik _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
