Re: [orca-list] Position of state vs. label for checkboxes (was Re:progress of progress bars is not reported., is it a known thing?)

["Michael Whapples" <mwhapples aim com>]

I don't quite know why you would want orca to check the actual position of 
the label relative to the control, so long as the label is certainly 
corresponds to the control. As already mentioned, in braille <control state> 
label makes more sense than the other way round with limited number of 
braille cells, so I would have thought this is the way round it should 
always be done (unless the user prefers the other way, in which case they 
surely would want them all the other way).

As for the amount of configuration options in the GUI for orca, I suppose 
who you are really wanting to aim it at. If it is for those moving from 
windows where configuration files aren't common place, then careful design 
of the GUI to separate things sufficiently, while making it clear how to get 
to the setting, whereas if you expect linux users (possibly moving from the 
command line, I fall into this category) then there probably is a greater 
readiness to edit configuration files (where options could be optional in 
the user file).

From
Michael Whapples
----- Original Message ----- 
From: "Willie Walker" <William Walker Sun COM>
To: "Halim Sahin" <halim sahin t-online de>
Cc: <orca-list gnome org>
Sent: Monday, May 07, 2007 4:22 PM
Subject: [orca-list] Position of state vs. label for checkboxes (was 
Re:progress of progress bars is not reported., is it a known thing?)


> > But thats allmost the case in all apps.
> > label <x>
> > but it should be
> > <x> label.
>
> Thanks.  That helps.  This is definitely the way braillegenerator.py
> does it and is how things are spec'd out.  We could potentially provide
> an option to specify where the state should go with respect to the
> label, but I'll defer to Mike on this.  One thing I would like to avoid
> is a humongous bunch of user configurable settings -- interfaces to such
> things can become somewhat difficult to use.
>
> As an aside, when I was first working on the speech and braille
> generators, I started developing a grammar to express the presence and
> order of things such as the object label, role, and state.  The idea was
> that the generators would use this grammar and users could customize the
> grammar to their heart's content.  I decided I was overgeneralizing too
> soon and ended up just hard coding things until we learned more.  When
> the time comes (perhaps now?), maybe we can revisit this notion.
>
> > It seems that you do not check the possition of labels and controls in
> > braillegenerator.py.
>
> I'm not sure we can actually check the position in a straightforward
> manner.  That is, I don't think there's a direct method in AT-SPI to
> tell us this information, and the label and state of a control tend to
> not be separate objects for things like checkboxes in GTK+.  That is,
> the graphical indicator for a checkbox and its label tend to be just one
> object as exposed by the AT-SPI.
>
> As a possible solution, one might get the extents of the accessible text
> for the checkbox and compare them to the extents of the checkbox itself.
> > From there, one might be able to infer the left/right/top/bottom
> position of the checkbox.  We're working pretty hard on other stuff
> right now, though, and probably won't be able to dedicate time to this
> right now.  Is this something you'd like to work on?
>
> Thanks!
>
> Will