GNOME Bugzilla – Bug 620977
Default script instead of specific cally toolkit one is used
Last modified: 2010-06-10 12:28:16 UTC
Created attachment 163069 [details] Orca debug log, shows that it is being used the default script STEPS TO REPRODUCE 1. Compile cally with examples, set a11y environment, run orca 2. Execute ./cally-atkcomponent-example 2.1 Here the key focus is always on the Stage (top-level window, just below CallyRoot, the one with role ATK_ROLE_APPLICATION) 3. Press a printable key like 'd' 4. Press a non printable key like left control EXPECTED OUTCOME It is speeched out 'd' and 'Left Control' REAL OUTCOME It is speeched out just 'd' ADDITIONAL INFORMATION: You can find extra background in the original cally bug reported : http://bugzilla.o-hand.com/show_bug.cgi?id=2147 After add some extra debug flags like this: diff --git a/src/orca/input_event.py b/src/orca/input_event.py index d36c8a3..bc5d982 100644 --- a/src/orca/input_event.py +++ b/src/orca/input_event.py @@ -85,6 +85,7 @@ class KeyboardEvent(InputEvent): # script = orca_state.activeScript if (script): + debug.println(debug.LEVEL_FINE, "Using script %s" % script.name) script.checkKeyboardEventData(self) # Control characters come through as control characters, so we orca debug log (attached) shows that it is wrongly using the default script instead of the specific cally one. The log also shows that orca found without problem cally script (in the same way, if you use one of the text examples and focus on a text object, it starts to work fine). Taking into account that in GS in depends on the object being focused, so you can focus in a different object, and then go back to the main window (so the focus goes back to the stage), it seems that it is failing the process to set the active script, when the stage is being focused.
From a Joanmarie private mail: "What is noticeably absent here is a window:activate event. Visually a window is activated for your test example, even if the "window" is officially a canvas. If you look at focus_tracking_presenter._processObjectEvent(), you'll see: state = event.source.getState() if not state.contains(pyatspi.STATE_ICONIFIED): eType = event.type setNewActiveScript = eType == "window:activate" So if Clutter/Cally emitted a signal telling us that a window had been activated when the stage gets focus, I *think* that might solve the problem without any changes to Orca." I started to review that in order to refresh all related to "window:xxx" events. And I was able to remind the little nightmare here. Well, at this moment these signals are not implemented at all. The main reason is because Clutter lacked a object with exactly the same purpose that GtkWindow. ClutterStage is a good candidate, share some of the functionality, but not exactly the same. As in other cases, I was waiting to a clutter-based toolkit implemented a window (full window meaning). A good candidate here would be the no documented at all MxWindow. In the same way I always thought that how this "window:xxx" events are implemented is odd. Gail emit this signals, and at-spi expect that, resending them to at apps as at-spi events. *But* they are not ATK signals. No ATK interface define this signals, and although defined in the Window interface at at-spi (check event.didl), there isn't any documentation about it. So although ATK it is supposed to be an abstract implementation, and at-spi talks with apps using that, in the end in depends in a specific toolkit sugar in order to have some signals, as you can see in the method gail_util_add_global_event_listener, where you can connect to "normal atk signals" and then to specific window ones. IMHO, this is somewhat a hack in order to avoid to define on AtkObject some signals that has only sense if the role is ATK_ROLE_WINDOW, or to define a AtkWindow interface. Well, sorry for the (offtopic?) rant. The ideal solution would be start to emit this signals from the stage, implementing that, but before do the full implementation I would like to make a little hack in order to confirm that this is the problem. Thanks for the help.
(In reply to comment #1) > IMHO, this is somewhat a hack in order to avoid to define on AtkObject some > signals that has only sense if the role is ATK_ROLE_WINDOW, or to define a > AtkWindow interface. Once we get past bonobo deprecation and friends, I really want to sit down and think of all the things that aren't quite right or could otherwise be improved w.r.t. Atk. Sounds like this situation needs to go on that list. > Well, sorry for the (offtopic?) rant. As well you should be. After all, I never ever rant. ;-) ;-) > The ideal solution would be start to emit > this signals from the stage, implementing that, but before do the full > implementation I would like to make a little hack in order to confirm that this > is the problem. Awesome. Thanks! And like I said, if for some reason that doesn't work out we can tackle this on the Orca side of things. If you don't mind, I'm going to assign this to you.
(In reply to comment #1) > Well, sorry for the (offtopic?) rant. The ideal solution would be start to emit > this signals from the stage, implementing that, but before do the full > implementation I would like to make a little hack in order to confirm that this > is the problem. Well, finally I will implement that on Cally, and use ClutterStage as the equivalent Window class. I have test to add this functions, and in that case it works. In the end, as Im using this class as the one with the state ACTIVE, I should implement it. I will also use this moment to implement "create" and "destroy" BTW: this makes me wonder if it would have sense to change ClutterStage role from canvas to window. BTW2: although solved the problem in the examples, GS doesn't speech out "Ctrl" as explaine in the original CB#2147 bug description. So although the symptoms were equivalent, it seems that not the reason. Closing the bug as RESOLVED:NOTGNOME. Bad luck we can't cross-reassign bugs.
(In reply to comment #3) > BTW: this makes me wonder if it would have sense to change ClutterStage role > from canvas to window. What do you think we should do? Personally, I'm not bothered if it's of ROLE_CANVAS. We get window:(de)activate events from ROLE_FRAME and ROLE_DIALOG. > BTW2: although solved the problem in the examples, GS doesn't speech out "Ctrl" > as explaine in the original CB#2147 bug description. So although the symptoms > were equivalent, it seems that not the reason. Bah. I'll take a look. Thanks!
(In reply to comment #4) > (In reply to comment #3) > > > BTW: this makes me wonder if it would have sense to change ClutterStage role > > from canvas to window. > > What do you think we should do? > > Personally, I'm not bothered if it's of ROLE_CANVAS. We get window:(de)activate > events from ROLE_FRAME and ROLE_DIALOG. Ok, fine, so as it works rigth now, and express what ClutterStage is, I will maintain this role. > > BTW2: although solved the problem in the examples, GS doesn't speech out "Ctrl" > > as explaine in the original CB#2147 bug description. So although the symptoms > > were equivalent, it seems that not the reason. > > Bah. I'll take a look. But beware, I didn't commit the changes on cally to emit "window:activate" (right now I have some hackish things that I need to clear). So if you test it, there are some possibilities that it keep failing because of this. Using Murphy Laws probably GS is failing due the missing emission and "something more". I need to find out this "something more" Thanks for your help.