Re: [Kde-accessibility] KDE Accessibility - sorry, off topic.

[Bill Haneman <Bill Haneman Sun COM>]

Hi Chris:

Zero-conf is of course the ideal, glad you've achieved it for SOK.

I am hoping that by using Xevie (via at-spi-registryd - since Xevie only
allows ONE client per session :-( and at-spi-registryd needs XEvie for
its own purposes), we can change GOK so that the default out-of-the-box
configuration "just works".  For some users we'll still want to allow
specialty configuration but I agree that at the moment it "acts broken"
in the default config for many distros.  Not good.

Grabbing the pointer after a key press is indeed ugly.  It will of
course cause other apps' pointer grabs to fail, which will result in
menus working oddly etc. as Chris notes.  We tried this with GOK a long
time ago and gave it up.  We then tried grabbing the pointer only when
it entered the GOK window and releasing the grab when it exited - this
worked a little better but still produced too many side-effects. 
Actually as I recall it seems as though we tried _everything_ with GOK
:-D before arriving at the current XInput-dependent situation which
requires manual reconfiguration of XOrg.conf in order to work (not
good).

To give a couple of other examples of typical onscreen keyboard problems
with pointers:

1) onscreen keyboards must reject focus, to keep the foreground app in
front.  That's not so hard, but it requires a bit of specialist X code.
2) if you use an onscreen keyboard to activate a menu, or a menu is
otherwise posted by an app, the app probably has grabbed the pointer, so
the next click will go to the app and not the keyboard.  This means that
the onscreen keyboard acts differently from the physical keyboard, and
means that it "goes dead" when certain things happen (modal dialogs,
menus posted, and many other common scenarios).  Besides being
inconsistent, it means that "point and click" style onscreen keyboards
are mostly useless for keyboard navigation.  For some users this is OK,
but if the user has trouble hitting small mouse targets it means the OSK
can't be used as a convenient way of making this job easier.

3) in 'dwell mode' (for users who cannot click, only point, i.e. some
head tracker users), the menu grabs above result in what seems like a
hang, while the grab client waits for a click that can never come.  This
is a lockout scenario, clearly bad.

4) for users who can 'click' but not accurately point (for instance,
users of wheelchair mounted switches, etc.), mouse grabs mean that the
clicks don't reach the OSK, so you have a problem similar to #3 (though
at least the whole desktop doesn't appear to hang).

There are other oddities, like the fact that a few apps behave strangely
if a click occurs while the pointer is outside their window, etc.

Olaf implied that there was a concern with XEvie "interfering" with the
core pointer.  I would suggest that a certain kind of "interference" is
desirable - i.e. don't let a grab client 'see' the pointer if it's
inside the OSK's window.  XEvie (and at-spi, via its keyboard listener
APIs) allows a client to do just this - clients can "consume" keyboard
and/or mouse events before they ever reach the normal XNextEvent loop,
or they can pass them through.  So for the typical default "point and
click" style of OSK interaction (what GOK calls "direct selection"),
pointer events would be passed through normally except when the pointer
was inside the OSK's window.  When the pointer is inside the OSK window,
the events are consumed by the OSK (even though it doesn't technically
'have focus'), and thus don't produce other visible side-effects.  If
anyone wants some suggestions/recommendations for using the existing
AT-SPI APIs for getting XEvie-based events, I'll be happy to help, just
ask.

By doing this, instead of using the normal "click" events from the host
toolkit's buttons, it allows another nice thing - you can 'average' the
pointer position to make it easier for someone with poor pointing
accuracy to click on a button (so that the 'wrong' OSK key isn't chosen
if your pointer slips at the last moment).  Since many people with
physical disabilities can find that clicking a trackball key causes the
pointer to "slip" a little, this feature would be very useful.

All the best,

Bill

On Thu, 2006-08-17 at 03:42, Chris Jones wrote:
> I'm the developer of SOK, which is now being rebranded to onBoard.
> 
> I have come across the issues that Bill has mentioned and I think he
> is right that XEvie is the only proper solution.
> 
> That said it is possible to work around the grabbing issues simply by
> grabbing the pointer for a while after every key press.  This is messy
> and breaks things like alt-tab and alt-f for the file menu etc.  For a
> lot of users this is not a major flaw.
> 
> With SOK I have been following a zero configuration policy.  A user
> should be able to fire up SOK and use it straight away.
> 
> I havn't yet examined XEvie in detail.  If it is not possible to use
> it with zero configuration it shall not be used in SOK.
> 
> A KDE port of SOK should be possible.   I know cairo can be used with
> qt.  I don't know if kde has a drop in replacement for gconf.  I would
> be happy to do some work post SoC to make SOK more desktop neutral.
> 
> -- 
> Chris Jones
> 
> jabber - skating tortoise gmail com
> msn - skating_tortoise dsl pipex com
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list