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 - [EMAIL PROTECTED] > msn - [EMAIL PROTECTED] > _______________________________________________ > gnome-accessibility-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
