GtkStatusbar inherits from GtkHBox, so I don't see why using a HBox would make a difference... Maybe it's a bug in the acessibility stack?

Gedit statusbar is a Statusbar so modelling it with inheritance is a good solution for us and I would prefer not to change it: it allows us to do stuff like
gtk_statusbar_push_message (GTK_STATUSBAR(gedit_sbar), "foo") and we avoid aving to wrap all the GtkStatusbar api.

I'd say this is a bug in gail, since it reports no children for a statusbar.

static gint
gail_statusbar_get_n_children (AtkObject          *obj)
{
  /*
   * We report a GailStatusbar as having no children
   */
  return 0;
}

Wow!  Thanks for finding that.  I completely missed it - I'm guessing that the GAIL author didn't expect people to subclass the status bar and stuff children in it.  But, since even buttons can have children, I guess it's perfectly acceptable for status bars to have children and this does look like a gail bug.  I'll reassign this to AT-SPI/GAIL.

> In digging through the code, it looks as though the status bar is a custom
> status bar that keeps a couple standard GTK status bars in a private data
> structure.  Since I don't really understand the semantics behind a status bar,
> I'm not sure I can recommend a great solution here.  But, perhaps instead of a
> custom status bar, GEdit could provide a panel that has the standard GTK status
> bars as children?

Bill - do you have any insight you can provide here?  What should the hierarchy look like for a status bar that has multiple children that display content?  The current gail implementation seems to assume that a statusbar has one label that displays content.  It exposes the statusbar as a childless object that implements the accessible text interface, where the accessible text information comes from the label.

GEdit's custom status bar is a container composed of a hierarchy that looks like the following.  These are just the visible components:

      +-name=None role='statusbar'
        +-name=None role='panel'
          +-name=None role='label'
        +-name='  Ln 1, Col 1' role='statusbar'
          +-name=None role='panel'
            +-name='  Ln 1, Col 1' role='label'
        +-name='  INS' role='statusbar'
          +-name=None role='panel'
            +-name='  INS' role='label'

More components are in there, depending up the status of various things.

I think the simplest and best solution would be to modify GailStatusBar's getChildren implementation to return the actual widget children of the Hbox.

It would then be up the the AT to traverse into the children (or traverse up, i.e. "am I in a statusbar?") in its heuristics, when deciding if/how to present the data.

Patrick, you can have a look at this bug if you like. Should be relatively easy to fix. Maybe just removing the gail_statusbar_get_n_children() function would fix it.

Harry - OK, thanks.

(In reply to comment #7)
> Harry - OK, thanks.
> 

Patrick -- thanks for looking at this.  It's one of our more nagging problems with GEdit.  Do you have an idea when you might take a look at it?

Created attachment 88627 [details] [review]
Patch to hopefully fix the problem.

I've attached a patch that hopefully will be close to the required fix.
This seems to work nicely with Orca with the gedit status bar. My concern
is whether it does the right thing for a status bar that doesn't have
any children. 

If somebody can suggest such an application, I'll give this more testing.

Patrick could you please review?

Thanks.

PS: This is a diff against gail v1.18.0