Re: Gedit focus issue (was, Re: Serious accessibility issue in Gnome 2.15.)
Yep and Thanks! I'm surprised there's not a object:state-changed:focused event in the Edgy version. I'm seeing that on my box. :-( Will On Tue, 2006-08-15 at 16:53 -0400, Joanmarie Diggs wrote: > Hi Will. I'll take a stab at it. > > In Dapper: > [...] > window:maximize > object:state-changed:iconified > focus: > object:property-change:accessible-value (8x) > [...] > > In Edgy: > [...] > window:maximize > object:state-changed:iconified > object:property-change:accessible-value (8x) > object:state-changed:showing > object:state-changed:visible > object:state-changed:iconified > [...] > > Is that what you're looking for? > > Take care. > Joanie > > > If someone has some time on their hands they might try seeing if there > > are different event orderings between GNOME 2.14 and GNOME 2.15/16 for > > this gedit maximize/unmaximize scenario. The events of interest > > probably include: "focus:" "window:activate" "window:deactivate" and > > "object:state-changed:focused". > > > -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Gedit focus issue (was, Re: Serious accessibility issue in Gnome 2.15.)
Hi Will. I'll take a stab at it. In Dapper: [...] window:maximize object:state-changed:iconified focus: object:property-change:accessible-value (8x) [...] In Edgy: [...] window:maximize object:state-changed:iconified object:property-change:accessible-value (8x) object:state-changed:showing object:state-changed:visible object:state-changed:iconified [...] Is that what you're looking for? Take care. Joanie > If someone has some time on their hands they might try seeing if there > are different event orderings between GNOME 2.14 and GNOME 2.15/16 for > this gedit maximize/unmaximize scenario. The events of interest > probably include: "focus:" "window:activate" "window:deactivate" and > "object:state-changed:focused". -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Gedit focus issue (was, Re: Serious accessibility issue in Gnome 2.15.)
Hi All: Just to follow up... I'm not sure of the exact cause of the differences here (e.g., metacity, gedit?), but we put a workaround in Orca to handle the differences between GNOME 2.14 and GNOME 2.15/16. Thanks for reporting this problem! If someone has some time on their hands they might try seeing if there are different event orderings between GNOME 2.14 and GNOME 2.15/16 for this gedit maximize/unmaximize scenario. The events of interest probably include: "focus:" "window:activate" "window:deactivate" and "object:state-changed:focused". Will On Wed, 2006-08-09 at 12:46 -0400, Joanmarie Diggs wrote: > Hi all. I just gave this a try. I can confirm Al's findings. And it > seems to occur any time you resize the window (e.g. if it's maximized > and you unmaximize it, the problem also occurs). > > In answer to Will's questions/suggestions: > > > This sounds like a separate problem. Do you have someone that can > > eyeball gedit for you to make sure keyboard focus is really back in the > > gedit text area after you've maximized the window? That is, is the > > cursor really moving when you press the arrow keys? > > Focus is really back in the gedit text area. I arrow around but Orca > says nothing. > > > In addition, once you've maximized the window, can you try pressing F10 > > and then Escape (e.g., bring up an app menu and then dismiss it)? This > > might force a focus event on the gedit window and get the cursor routing > > working again. > > This does get it working again! > > > Finally, did you verify that you don't see the problem on GNOME 2.14 > > using the same exact Orca bits? > > Yep! On my Dapper machine this does not occur. And to be sure I had the > same exact Orca bits, I just built from CVS on each machine. > > Hope this helps! Take care. > Joanie > > -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Gedit focus issue (was, Re: Serious accessibility issue in Gnome 2.15.)
On Thu, 2006-08-10 at 18:05 +0800, Li Yuan wrote: > I cannot reproduce this with gnopernicus. Gedit works fine after I > maximize it. Thanks Li! This is a good data point - I suspect focus events might be coming in a different order with metacity/gedit in GNOME 2.15 than they are in GNOME 2.14. We'll investigate this more and try to come up with a fix that works both ways. Will -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Gedit focus issue (was, Re: Serious accessibility issue in Gnome 2.15.)
I cannot reproduce this with gnopernicus. Gedit works fine after I maximize it. Orca doesn't work on my edgy. I download it form "http://archive.ubuntu.com/ubuntu/ edgy". But it hangs when setup dialog shows up. -Li On Wed, 2006-08-09 at 12:46 -0400, Joanmarie Diggs wrote: > Hi all. I just gave this a try. I can confirm Al's findings. And it > seems to occur any time you resize the window (e.g. if it's maximized > and you unmaximize it, the problem also occurs). > > In answer to Will's questions/suggestions: > > > This sounds like a separate problem. Do you have someone that can > > eyeball gedit for you to make sure keyboard focus is really back in the > > gedit text area after you've maximized the window? That is, is the > > cursor really moving when you press the arrow keys? > > Focus is really back in the gedit text area. I arrow around but Orca > says nothing. > > > In addition, once you've maximized the window, can you try pressing F10 > > and then Escape (e.g., bring up an app menu and then dismiss it)? This > > might force a focus event on the gedit window and get the cursor routing > > working again. > > This does get it working again! > > > Finally, did you verify that you don't see the problem on GNOME 2.14 > > using the same exact Orca bits? > > Yep! On my Dapper machine this does not occur. And to be sure I had the > same exact Orca bits, I just built from CVS on each machine. > > Hope this helps! Take care. > Joanie > > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Gedit focus issue (was, Re: Serious accessibility issue in Gnome 2.15.)
Hi all. I just gave this a try. I can confirm Al's findings. And it seems to occur any time you resize the window (e.g. if it's maximized and you unmaximize it, the problem also occurs). In answer to Will's questions/suggestions: > This sounds like a separate problem. Do you have someone that can > eyeball gedit for you to make sure keyboard focus is really back in the > gedit text area after you've maximized the window? That is, is the > cursor really moving when you press the arrow keys? Focus is really back in the gedit text area. I arrow around but Orca says nothing. > In addition, once you've maximized the window, can you try pressing F10 > and then Escape (e.g., bring up an app menu and then dismiss it)? This > might force a focus event on the gedit window and get the cursor routing > working again. This does get it working again! > Finally, did you verify that you don't see the problem on GNOME 2.14 > using the same exact Orca bits? Yep! On my Dapper machine this does not occur. And to be sure I had the same exact Orca bits, I just built from CVS on each machine. Hope this helps! Take care. Joanie -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Gedit focus issue (was, Re: Serious accessibility issue in Gnome 2.15.)
Hi Al: Thanks very much for testing this out! This sounds like a separate problem. Do you have someone that can eyeball gedit for you to make sure keyboard focus is really back in the gedit text area after you've maximized the window? That is, is the cursor really moving when you press the arrow keys? In addition, once you've maximized the window, can you try pressing F10 and then Escape (e.g., bring up an app menu and then dismiss it)? This might force a focus event on the gedit window and get the cursor routing working again. Finally, did you verify that you don't see the problem on GNOME 2.14 using the same exact Orca bits? We introduced some window activate/deactivate handling code prior to Orca 0.2.8 that might have had a negative impact in this space, and I want to make sure this isn't an Orca regression. Thanks! Will On Tue, 2006-08-08 at 22:00 -0400, Al Puzzuoli wrote: > Hi all, > > I've come across another weird focus issue which hopefully, can serve as > another piece of the puzzle if nothing else. This again, is on my Edgy > system running the latest updates as of the evening of Tuesday august 8. > To reproduce, try the following: > 1. Open any document in gedit, and attempt to navigate said document using > the arrow keys. Doing so should work just fine. > 2. Now, maximize the gedit window using alt-space x, or via the menu bar, > and then Arrow around the document once more. On my system, as soon as I > maximize the window, Orca no longer seems to be able to track the caret. > > --Al > > > > - Original Message - > From: "Willie Walker" <[EMAIL PROTECTED]> > To: "Henrik Nilsen Omma" <[EMAIL PROTECTED]> > Cc: "Al Puzzuoli" <[EMAIL PROTECTED]>; "Ubuntu Accessibility Mailing List" > ; "Gnome accessibility" > > Sent: Monday, August 07, 2006 12:06 PM > Subject: Re: Serious accessibility issue in Gnome 2.15. > > > > Hi All: > > > > I was finally able to do some testing with this. I'll confirm that none > > of these are Orca bugs. We do care, however, about the overall > > accessibility of the platform. So, we'll dig into these problems more > > and follow up with the appropriate teams. > > > >> > 1. Focus in gaim seems to be messed up. I was able to create one > >> > account, > >> > a freenode irc account. But now, after doing that, I can never seem to > >> > bring focus back to the main buddy list window, as for whatever reason, > >> > it > >> > doesn't seem to appear in the alt tab order. > > > > My experiences show that GAIM will come up without the buddy list and > > you need to press the gaim icon in the panel to show it. I've tried > > various ways to get to the icon from the keyboard, but I cannot seem to > > do so (BAD for people who cannot use the mouse). So...I resorted to > > clicking on it, which brings up a menu allowing me to show the buddy > > list. > > > > Once I was able to make the buddy list visible, I found that Orca seemed > > to do just fine with it. > > > > Note that this seems to be only with GAIM 2.0.0beta versus GAIM 1.5.1. > > > >> > 2. Very strange things are happening in gnome terminal. Orca tracks > >> > live > >> > events well enough, but if I attempt to use flat review, it's all over > >> > the > >> > place. The read current line command seems to start at the top of the > >> > window, rather than at the last location of the cursor. Another oddity > >> > is > >> > that not all of the window is accessible via flat review. in other > >> > words, > >> > if my screen fills up with data, flat review stops before actually > >> > reaching > >> > the last line on the screen. > > > > I found that something broke with gnome-terminal's implementation of > > getTextAtOffset: it's giving us very wrong and very incorrect values for > > GNOME 2.15.90 versus GNOME 2.14. As such, it's difficult to know where > > text is on the screen as well as getting the text for the line where the > > cursor is. We will dig into this more this week and file a bug with the > > appropriate component (gnome-terminal, vte, ...) when we learn more. > > > >> > 3. Open office writer is completely inaccessible. Orca won't even > >> > read the > >> > menu bar or the help dialog. If I attempt flat review, all I get is > >> > "panel". > > > > I dug into this some more, and there appears to be some binary > > incompatibility between the AT-SPI implementation used by OOo and what > > is in GNOME 2.15.90. We've brought this to the OOo team's attention and > > will be following up more with them this week. Note that this may or > > may not be an OOo problem (e.g., it could be an inadvertent AT-SPI > > incompatibility). > > > > Thanks! > > > > Will > > > > > > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubunt
Gedit focus issue (was, Re: Serious accessibility issue in Gnome 2.15.)
Hi all, I've come across another weird focus issue which hopefully, can serve as another piece of the puzzle if nothing else. This again, is on my Edgy system running the latest updates as of the evening of Tuesday august 8. To reproduce, try the following: 1. Open any document in gedit, and attempt to navigate said document using the arrow keys. Doing so should work just fine. 2. Now, maximize the gedit window using alt-space x, or via the menu bar, and then Arrow around the document once more. On my system, as soon as I maximize the window, Orca no longer seems to be able to track the caret. --Al - Original Message - From: "Willie Walker" <[EMAIL PROTECTED]> To: "Henrik Nilsen Omma" <[EMAIL PROTECTED]> Cc: "Al Puzzuoli" <[EMAIL PROTECTED]>; "Ubuntu Accessibility Mailing List" ; "Gnome accessibility" Sent: Monday, August 07, 2006 12:06 PM Subject: Re: Serious accessibility issue in Gnome 2.15. > Hi All: > > I was finally able to do some testing with this. I'll confirm that none > of these are Orca bugs. We do care, however, about the overall > accessibility of the platform. So, we'll dig into these problems more > and follow up with the appropriate teams. > >> > 1. Focus in gaim seems to be messed up. I was able to create one >> > account, >> > a freenode irc account. But now, after doing that, I can never seem to >> > bring focus back to the main buddy list window, as for whatever reason, >> > it >> > doesn't seem to appear in the alt tab order. > > My experiences show that GAIM will come up without the buddy list and > you need to press the gaim icon in the panel to show it. I've tried > various ways to get to the icon from the keyboard, but I cannot seem to > do so (BAD for people who cannot use the mouse). So...I resorted to > clicking on it, which brings up a menu allowing me to show the buddy > list. > > Once I was able to make the buddy list visible, I found that Orca seemed > to do just fine with it. > > Note that this seems to be only with GAIM 2.0.0beta versus GAIM 1.5.1. > >> > 2. Very strange things are happening in gnome terminal. Orca tracks >> > live >> > events well enough, but if I attempt to use flat review, it's all over >> > the >> > place. The read current line command seems to start at the top of the >> > window, rather than at the last location of the cursor. Another oddity >> > is >> > that not all of the window is accessible via flat review. in other >> > words, >> > if my screen fills up with data, flat review stops before actually >> > reaching >> > the last line on the screen. > > I found that something broke with gnome-terminal's implementation of > getTextAtOffset: it's giving us very wrong and very incorrect values for > GNOME 2.15.90 versus GNOME 2.14. As such, it's difficult to know where > text is on the screen as well as getting the text for the line where the > cursor is. We will dig into this more this week and file a bug with the > appropriate component (gnome-terminal, vte, ...) when we learn more. > >> > 3. Open office writer is completely inaccessible. Orca won't even >> > read the >> > menu bar or the help dialog. If I attempt flat review, all I get is >> > "panel". > > I dug into this some more, and there appears to be some binary > incompatibility between the AT-SPI implementation used by OOo and what > is in GNOME 2.15.90. We've brought this to the OOo team's attention and > will be following up more with them this week. Note that this may or > may not be an OOo problem (e.g., it could be an inadvertent AT-SPI > incompatibility). > > Thanks! > > Will > > -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
