GNOME Bugzilla – Bug 108164
Want an indication that GOK is busy
Last modified: 2011-10-14 10:59:03 UTC
A number of operations can take a while for GOK to complete (e.g. GOK walking through the UI heirarchy of StarOffice to build a menu or toolbar keyboard). During this time there is no indication that GOK is busy processing, and a user is strongly tempted to interact with GOK thinking it might be wedged in some way. Sometimes this new interaction overrides the thing it was processing (e.g. the 'back' command), other times it simply queues up a new action (e.g. activating apps) which then gets done too. Perhaps turning the mouse into a special hourglass cursor? Perhaps making some kind of indication on the GOK keyboard overall?
In my view this is a performance bug against SO, etc., not really a GOK issue. So far SO is the only such case for GOK where a busy cursor would be useful. However GOK does have its own cursor code for the XInput case, we could change the 'GOK cursor' in such cases.
priority of this depends on what happens with SO, etc. If performance stays like it is now then, yes, we might need this.
After looking into what GOK is/was going with its event processing, I think the current fix for 88033 should largely fix the observed behavior that led to this RFE. I don't think GOK should ever block for this long; if there are operations this expensive thay can be handled in an idle handler and it's not clear that a busy cursor is that important.
Bill, unfortunately I think pruning the tree search is the only thing that will help here, and that is not yet implemented.
I agree that pruning will help (but only searching when a new window is focussed will help too - there will be a lot less event processing under the new model). There are other things I'm suggesting, some of which you already do: * do the tree traversal at idle; * break the tree traversal into stages so GOK doesn't go 'dead' during the search; etc. The pruning needs to happen anyhow; it shouldn't be hard to implement.
Good ideas. And I new you would agree regarding the pruning, since you suggested it yesterday ;-) aside: For the first time ever my linux partition has become badly corrupted (maybe my laptop got too cold in transit home last night). fsk fails etc. This will severly slow me down [sigh]
Just a note that pruning is there. Interrogating the app in the idle handler is also there. The sequence is that idle looks at the queue, if there is a new application, then a callback in main is called, and ultimately the current keyboard is updated if necessary (using gok-spy to interrogate). As we know, this can still be noticeably long. I don't know how to implement a wait cursor globally... Do you think we should branch to a waiting.kbd with a button that says "please wait"?
Oh and interrogation also happens when branching to a keyboard with dynamic branch keys (e.g. menu, UIGrab). Perhaps branching to such a keyboard should push an event on the queue so that the interrogation can happen in the idle handler? Not sure what this gains us.
I wouldn't branch to a 'wait' keyboard, that would introduce new slowdowns in many cases. There's no way to set a global cursor, at least for the corepointer, unless you do a mouse grab (which we don't want to do IMO). But we can change the cursor while over GOK to a wait cursor, and can change the GOK XInput cursor to a wait cursor. However I still don't think this is a cost-effective measure for us now, in terms of the time it would take. Perhaps for 2.4.1, if such a user-visible feature can be allowed into the 2.4.X stream; otherwise for 2.6. Another option, already discussed, would be to add a statusbar to GOK; this would take up precious screen real-estate though. Lastly, we could have GOK post its status via an icon in the notification area, which would be a reasonable way to go also. Certainly post-2.4 in that case however. - Bill
I wouldn't put any branches into idle handlers at this time however - I think this would multiply our bugs massively. In general in GOK, if we do anything in an idle handler we have to synchronously invalidate/revalidate the _current_ keyboard anyhow, otherwise we can get activations on dead objects, etc. So I would argue for keeping as much of the GOK presentation/validation code synchronous as possible, at least until/unless we do a major code refactor of all GOK logic.
adding accessibility keyword
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
gok (GNOME on-screen keyboard) development has been stalled and it has been replaced by caribou [1]. Maintainers don't have future development plan so i am closing all the bugs as WONTFIX. [1] https://mail.gnome.org/archives/gnome-bugsquad/2011-October/msg00001.html