It is a pity I was not aware of Xevie earlier in the project. It may have caused me to change my mind if I knew there was light at the end of the tunnel on the core pointer issue.
I understand completely why the dialog boxes are there and why they are necessary. They are symptoms of the actual problems. Simply suppressing them would do little. My project as I saw it was not to improve but to fix. Gnome is in need of a usable OSK. The main gripe with it being the configuration problems. Since at the time you refused to consider addressing the configuration problems I was left with no choice. - Hide quoted text - On 24/07/06, Bill Haneman <[EMAIL PROTECTED]> wrote: > On Mon, 2006-07-24 at 15:10, Chris Jones wrote: > ... > > It is possible to detect when pointer grabbing occurs so work arounds > > are quite possible I should think. > > Not as far as I can tell. X just doesn't allow it. > > > Since GOK can not be configured to work out of the box there seems > > little point installing it by default. > > I disagree - we went to a lot of trouble to make GOK work as well as > possible out of the box. That said, we felt we needed to warn end-users > of potential conflicts with the core pointer, thus the warning dialogs > (easily suppressed, as I have pointed out before). > > Bill > > > Bill Haneman wrote: > > >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. > > > > I'm not sure I understand. Is this something that could be solved by > > desktop wide dwell support? > > ?? > I don't think so, if I understand your question. > > > >The "new onscreen keyboard" does not meet the needs of many > > >mobility-impaired users. GOK should be bundled with the LiveCD - once > > >some configuration issues are dealt with. > > > > Are there plans afoot to deal with these configuration issues? > > Otherwise I think we need to explore alternative approaches. > > Imperfect though they may be, we need something that works. > > There is no point debating this on mailing lists. Please file bugs > where the technical issues can be discussed thoroughly. > > I plan to follow up with a more detailed email about the pointer > grab/core-pointer problems. But in short, because the trend for X > server configurations is to multiplex all pointing devices together into > core, and a number of problems with the way the current generation of > XInput works, I agree that a different solution seems necessary. I > think using Xevie (via AT-SPI, since there can only be one Xevie client > on a desktop) for all GOK's input is the best approach, but we've been > holding off on doing this since some distros have shipped with broken > Xevie support (FC4 for instance). Now that FC5 is out it seems like a > good time to require Xevie if that will break the logjam with regard to > input devices. This would also make GOK's configuration very simple and > allow it to work "out of the box" with all mouse-like or button-like > input devices. > > > >??? Because GOK uses GTK+ for its rendering it uses Cairo too. > > > > True. GOKs poor performance is a mystery to me, I have no idea why > > SOK seems faster. It does however. > > Have you or anyone filed a performance bug? > > > >By default GOK gets the physical keyboard's layout from the xserver and > > >displays that. However GOK also has alternate physical layouts that you > > >can use. They are XML files and straightforward to customize by editing > > >the XML. > > > > I am also hoping to go down this route. It is much easier to > > personalise these layouts with SOK which many will want to do since a > > physical keyboard layout is not necessarily good as an on-screen > > keyboard. > > > > >Henrik said: > > >> We haven't make any attempt get this into Gnome 2.16 as I could see that > > > >there would be strong opposition, but I think we can make a good case > > >> for Gnome 2.18. > > > > >Absolutely not. > > In the beginning we tried to give guidance, but I got the distinct > impression that it was going to /dev/null. This is why I am > frustrated - lots of behind-the-scenes vague griping, without GOK bugs > and seemingly without a willingness to engage cooperatively to improve > the existing Gnome onscreen keyboard suite, which was designed by > experts in the field of adaptive technologies. > > I would very much like to work cooperatively with you and with the rest > of the Ubuntu team, but in the context of improving our existing OSKs. > > Bill > > > It's this kind of attitude that discouraged me from asking you for > > advice. I can understand how my approach has riled you as a fair bit > > less work has gone in to SOK than GOK, and yet people talk of > > replacing it. However my program is more useful to some people. > > > > I hoped to bring new ideas to the area and you seemed determined to > > squash them from the start. > > > > I'm sorry to get personal about this, and your experience and > > knowledge would be very valuable to me only it seems impossible to > > enlist your help without this kind of prolonged heated debate breaking > > out. It needs to be accepted that there will be differences of > > opinion and to work together despite this. > > > > Chris Jones > > _______________________________________________ > > gnome-accessibility-list mailing list > > [email protected] > > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > > -- Chris Jones jabber - [EMAIL PROTECTED] msn - [EMAIL PROTECTED] _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
