Re: Gedit focus issue (was, Re: Serious accessibility issue in Gnome 2.15.)

[Willie Walker <William Walker Sun COM>]

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" <William Walker Sun COM>
> To: "Henrik Nilsen Omma" <henrik ubuntu com>
> Cc: "Al Puzzuoli" <alpuzz gmail com>; "Ubuntu Accessibility Mailing List" 
> <ubuntu-accessibility lists ubuntu com>; "Gnome accessibility" 
> <gnome-accessibility-list gnome org>
> 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