GNOME Bugzilla – Bug 128970
no indication of tab creation
Last modified: 2004-12-22 21:47:04 UTC
using a gnome-2.5 build from 08/12/2003 -launch gnopernicus -launch a gnome-terminal -<shift><ctrl><t> to open a new tab expected: -gnopernicus reports "create tab, <terminal name>, <initial prompt>" actual: -gnopernicus reports "<terminal name>, <initial prompt>"
There is no event from at-spi for this scenario. Transffering bug to at-spi/gail to emmit an event for this case.
This is a consequence of bug #58674.
*** Bug 136761 has been marked as a duplicate of this bug. ***
I have looked at this again. Although the bug 58674 has not been fixed I think that I can figure out when a new tab is created as it is usually selected. I expect that I will emit a children-changed::add signal on the notebook. It would then be up to gnopernicus to emit "create tab".
I have a patch which causes children-changed::add and children_changed::remove signals to be emitted when tabs are added or removed. It will then be up to gnopernicus to determine what to do with that data. I have removed the dependency on bug #58674 as I did not need it.
Created attachment 25555 [details] [review] gail patch
Transferring to gnopernicus for remaining work.
Is there any more progress on this?
I applied Padraig's patch but I don't see "object:children-changed:add"/"object:children-changed:remove" at-spi events beeing emitted when a new terminal tab is added/removed.
Created attachment 27392 [details] a standalone tester The source file is a modified file from at-spi/test directory. It register a listener for "object:children-changed:add" and "object:children-changed:remove" events.
I suspect that the accessible object is not been created for the object with role PAGE_TAB_LIST. If this object does not exist then the signals will not be emitted.
That was my suspicion also; in order to receive these events, the client (gnopernicus or the test program) must have "visited" the tab list object once before.
I managed to receive these events (with the previous tester), but in a "strange" scenario: * In order to receive these events, the terminal must have at least two tab created. So I cannot receive an "object:children-changed:add" event for the second tab added. * To receive these events I have to click on the last added tab (if there is two tabs and I click to the first one I wont receive these events...). Only after I click on the last added tab I will see these events. Are these events emitted for the children (the added tab) or for its parent ?
The events are emitted on the parent, i.e. the object with role page-tab-list. The problem seems to be that this object has not created when Ctrl+Shift+T is used to create a new tab so the events are not emitted. Perhaps when gnopernicus receives notification that an object has focus it could traverse back up the hierarchy to ensure than the object with role page-tab-list is created.
If the object which emits focus is ROLE_PAGE_TAB or can otherwise be identified as a notebook page, then I'd suggest doing the traversal Padraig suggests, but only for objects of ROLE_PAGE_TAB. I am not sure we should do a lot of traversal for _all_ focus events, if we can't detect that the object is a GtkNotebook page when it gives focus, then it might make more sense to search newly-discovered toplevel windows instead, since this traversal (from the top down) would only need to happen once for each toplevel window, instead of happenning on each focus event.
looking at gnome-terminal with at-poke, it appears that we can limit this traversal to focus: events from SPI_ROLE_PAGE_TAB objects.
I made the traversal Padraig suggests in order to receive "object:children-changed:add" and "object:children-changed:remove" events. It seems to be a problem: "object:children-changed:remove" is emitted on the parent, i.e. the object with SPI_ROLE_PAGE_TAB_LIST, (wich is correct) but "object:children-changed:add" is emitted on the SPI_ROLE_PAGE_TAB object. I will attach a standalone tester.
Created attachment 27829 [details] a new standalone tester
I will transfer this bug to atk/gail to evaluate this problem.
Created attachment 27836 [details] [review] Updated gail patch Sorry about the bad patch. I think that this patch is correct.
Yes, I applied the new patch and both events are now emitted for SPI_ROLE_PAGE_TAB_LIST object.
I will commit the gail patch to CVS HEAD.
Created attachment 27899 [details] [review] proposed patch When a new terminal tab is added, gnopernicus will report: 'create tab, <tab name>' Whwn a terminal tab is removed, gnopernicus will report: 'closing tab, <tab name>'
Please check if this patch works OK.
Would it be possible to implement a 'switch tab, <tab name>' function? I didn't mention this in the bug report, but it would make the feature complete.
Works for me.
The current description when a page tab is focused is: '<tab name>, Page tab, <shortcut (if exists)>' I will change it to: 'switch tab, <tab name>, <shortcut (if exists)>'
Created attachment 27967 [details] [review] updated patch New proposed patch, updated to provide the presentation described on comments #24 and #28.
Patch applied to CVS.
The behaviour is still not correct as of gnopernicus/gail from CVS HEAD 01/06/04. It would appear that the behaviour in comment #14 is still present. i.e. - I have to have at least 2 tabs open to have 'create tab' reported. - When closing the last added tab, there is no 'closing tab' reported. - Switching tabs (pressing alt-1, alt-2 etc) does not report 'switch tab', only the tab name and inital prompt is reported. I believe Padraig is investigating this.
Item 3 mentioned by David in last comment, i.e. 'switch tab' is not spoken, is a gnopernicus issue. Item 2: When last added tab was closed 'closing tab' is spoken followed by 'create tab'. This is a bug in gail for which I have a patch. I do not see item 1.
Created attachment 28263 [details] [review] Proposed gail patch for item 2
Using gail an gnopernicus from CVS HEAD, June 2nd: Item 1: I don't see this behavior. (Does anybody see it, except David ?) Item 2: I applied the gail patch and the behavior when I close the last added tab is the desired one. (i.e. without 'create tab ...'). Padraig, I believe this patch should be applied in CVS. Item 3: I'm investigating this problem.
I have committed ny patch to CVS HEAD.
I'll reassesss the bug when I build from HEAD with Padraig's gail patch this evening.
'switch tab <tab_name>' is spoken when the page-tab is focused(this presentation was added for 'focus:' event for 'page-tab' role). I assumed that if I switch between tabs (using Alt+<tab_no>), the focus will be moved on the current tab. So gnopernicus is waiting for a 'focus:' event for 'page-tab' role to output 'switch tab...'. But there are two situations (and, unfortunatelly, I have checked gnopernicus behavior only in the second one): 1) create some tabs, then press Alt+<no> to switch between them : there is no 'focus:' event for the current tab. 2) create some tabs, click on one tab then press Alt+<no> to switch tabs: there is a 'focus:' event for the current tab. Can this event be fired for both situation ? Or should I present 'switch tab...' for another at-spi event ?
When Alt+<no> is pressed to switch between tabs a "selection-changed" event is emitted on the parent and the tab which is switched from and the tab which is switched to both emit a "state-change:selected" event.
Padraig: in this situation (comment #38), it appears to me that "focus" is changing (since previous to Alt-<#> there was presumably focus somewhere on the initial page, and after the switch, that object no longer has keyboard focus). So I would expect some sort of "focus:" event to be emitted in this case.
Yes, "focus:" events are emitted for objects with role "terminal" when obe switches page tabs.
I get the 'switch tab' output when switching tabs in nautilus' preferences. It seems that this is gnome-terminal specific.
Why does gnome-terminal's page-tab have a different behavior ? In other applications, when I switch between tabs, I get the three at-spi events described in comment #38 _AND_ a 'focus:' event for the current page-tab. We need a uniform behavior here. If not, even if I manage to present 'switch tab...' for 'state-changed:selected', we will have a double output: one for 'focus:' and one for 'state-changed:selected' (because focus is always presented). Can we have a 'focus:' event for the current page-tab ?
I have checked with David and the 'switch tab' output occurs when the tab has focus. In gnome-terminal the tab does not receive focus. Focus changes from an object with role terminal in one tab to a similar object in another tab. As the page tab does not receive focus we cannot have a 'focus:' event for it. Is it posible to emit the 'switch tab' event for 'state-change:selected:' event instead of the 'focus:' event?
I don't believe this is a good solution, we will have a double output then (see comment #42). Why if I click firs on a tab and then I switch between tabs using Alt+<no> the current tab _can_ receive focus? This should be a general behavior.
If 'switch tab...' is outputed for 'object:state-changed:selected', this description will be 'overwritten' by the presentation for the 'focus:' event. Because this 'focus:' event is emitted for all page tabs (except a particular situation in gnome-terminal...). So the behavior in gnome-terminal is a very particular one and I believe we should not change the current behavior in gnopernicus (which works right for all other page tabs). Is it possible to emit the 'focus:' event for these page tabs ?
It is not possible to emit focus events for the tabs in gnome-terminal as they do not receive focus. I think that the problem which occur in gnome-terminal, i.e. that a tab can be switched to without the tab itself becoming focused, is a general problem and could occur in other applications.
I believe the best compromise in order to cover both situations is to ignore (to not present) the "focus:" event for a page-tab. Because this event (if) occurs always in conjunction with a "object:state-changed:selected" event, the second event can be presented instead of "focus:".
I made some investigations and ignoring the 'focus:' event for a page-tab is not the best solution: in same scenarios, only the focus event for a page-tab occurs, and it should be presented (if user switches between widgets inside a page-tab...). So I chose the following solution: the "object:state-changed:selected" events are converted into "focus:" events (to avoid the double output in case that both events are fired). In case of gnome-terminal page tabs, the desired information ('switch tab...') is sent to speech (corresponding to the 'false' focus ), but a focus event for 'terminal' is fired after that and the user will hear the output for this last focus event. I believe this is the correct output, because the rule is to "present last focus event" !
Created attachment 29550 [details] [review] proposed patch
This patch solves this problem on my machine.
Fixies in CVS.