On Friday 04 July 2003 05:35 pm, you wrote: > Hi Maks! > > Thank you very much for your work on Klaviatura. My pleasure. > I didn't have time to > look at your code, but getting QAccessible working is very high on our > agenda right now. I am really impressed that menus and toolbars are > working. > > Gunnar will give a speech on accessibility at the KDE developers meeting. > I think that showing your program at the conference would be a very good > way to illustrate what getting QAccessible to work is about. Well, may be I should make it more complete by then :-). Anyway, I've put it into kdenonbeta, which makes updating things easier, and fixed some bugs.. Still, there are quite a few major gaps and issues.. The #1 is that it occasionally locks up, but that's not very reproducible, making it hard to deal with Other than that, the big thing is the lack of support of toolbuttons with drop downs; I think this probably needs a new QAccessible plugin to handle KToolBarButtons, which do drop downs quite differently from their Qt counterpart. Other things are just more a matter of a lack of completeness. (i.e. it doesn't draw separators other than empty buttons now, only handles one keyboard layout, although backend just loads it from a file, etc.). > So please have a look at http://accessibility.kde.org/developer/ > > If you have any ideas or suggestions or improvements concerning these > documents, please let us know. One major concern of mine is an apparent (correct me if I am wrong) lack of plans for a native API. I think past experiences with projects like aRts show that systems that have their own way of doing things, which is not consistent with the rest of KDE tend to stagnate severely, as few people are willing to deal with them. Permanent requirements on ATK or AT-SPI also seem undesirable, although quite less severe than the API issue. > Your idea to use DCOP as a way to provide information to an external > application is interesting. We had also discussed this possibility, but I must also add that DCOP offers a very easy to use programming environment, requiring close to 0 code to support. > then thought that full interoperability with GNOME would be of larger > benefit for us, since there are already very good assistive technologies > for which it would be great to have them compatible with KDE. Are there any more other than GOK and Gnopernicus? BTW, I have not been able to get anything but the vanilla input mode in GOK to work; which is not very impressive since just sending keystrokes doesn't require an accessibility infrastructure. > > We will look at your code soon, if my impression is right, your hacks > would fit very fell to our plans to bridge to AT-SPI, as we hadn't > dreamed of having QAccessible already usable. Some of them may be of use, but in general the code that takes a somewhat restricted view of UIs (and it often bypasses QAccessible, when it's easier to work with the widgets). What does worry me is that the technique used to bypass mouse grabs (crucial when dealing with popups) does not seem like it'd generalize easily [currently, the plugin intercepts mouse clicks to popup menus (it inserts an event filter on accessibility events), and checks whether it falls on top of a window with an appropriate WM_CLASS, if so, it tells it over DCOP to simulate a mouse event, and squashes it locally). -Maksim _______________________________________________ kde-accessibility mailing list kde-accessibility@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-accessibility