I bet the screen readers use event buffer to accumulate events before processing them, and it must be timeout based, that's something you supposedly should also do. But, sure, it's worth to ask Orca developers about that, or read Orca sources.
On Thu, Dec 4, 2014 at 10:30 PM, Michael Pozhidaev <m...@altlinux.ru> wrote: > I just want to get a tiny screen reading utility which could allow > using Firefox, Skype or something else without GNOME and Orca, wich looks > to me rather big and heavy. Coming events describe the changes really > well but I am not sure when a particular change is describe > completely. For example, if I get text-caret-move it may mean the cursor > position change or may be a part of the text content change (which > evidently implies the cursor > position change as well). What it is depends on the events which will > come next. If we get after that the text-change event, well, it is the > text changing > and we should announce that as a text changing. Meantime, if we > get nothing after that, we should announce just the cursor move. > > The question is how I can be sure that nothing will come after a > particular event? The announcement to the user depends on the _*entire*_ > set of events but currently I don't know any way to be clearly sure what > kind of user action I should announce. > > Thank you! :)) > > Alexander Surkov <surkov.alexan...@gmail.com> writes: > > > Accessible events are just describe the change within accessible tree. > They are > > not really about user action, i.e. single user action may result in > several of > > accessible events. What is your use case? > > > > On Thu, Dec 4, 2014 at 8:43 PM, Michael Pozhidaev <m...@altlinux.ru> > wrote: > > > > Hello all, > > > > I got a question regarding choosing the most relevant event for the > > particular user action. When the user does something (presses the > key or > > anything else) his/her action usually yields the several events > which go > > through registryd and are transmitted to AT. The problem is how to > > choose among them the most preferable one? We can collect them and do > > the selection but for that we should be sure that know them all and > for > > the last user action there will no events any more. This require a > some > > sort of transactions or packets and I am wondering is there any way > to > > ensure that we got everything for the last user action? Maybe my > > approach is wrong and I would be thankful if somebody can help me to > > understand what I should do with that. > > > > Speaking "the most preferable event" I mean the most relevant event > to > > construct a user feedback. For example, when the user presses keys in > > the editable text, the events reflecting caret move and text changing > > arrive. > > Among them we need the text changing one while caret move is very > > confusing because it could be caused just by pressing the arrows. > > > > Thank you in advance! > > > > -- > > Michael Pozhidaev. Tomsk, Russia. > > Russian info page: http://www.marigostra.ru/ > > English info page: http://www.marigostra.com/ > > _______________________________________________ > > gnome-accessibility-devel mailing list > > gnome-accessibility-devel@gnome.org > > https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel > > > > > > -- > Michael Pozhidaev. Tomsk, Russia. > Russian info page: http://www.marigostra.ru/ > English info page: http://www.marigostra.com/ >
_______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
