On Sun, May 12, 2013 at 11:03:14AM -0400, Joanmarie Diggs wrote: > On 05/05/2013 09:37 PM, Trevor Saunders wrote: > > > I wonder if there is a reason you prefer this approach to the ia2 one in > > which after / before varients are kept, but only the actual contents of > > the word / line / whatever are returned not the word / line and the > > whitespace before or after depending? > > This approach seems simpler to me: > * One method rather than three
This is fair, but I'm not sure that its that hard to implement before / after with most of the same logic as at. > * A given block of text is neatly chopped up with no "scraps" left over, > thus the user is always in a defined text boundary. On the other hand now "words" contain whitespace, and sentences contain the whitespace between them which seems pretty odd to me. I imagine for example if you're writing a program that highlights text as it is read you do not want to include the whitespace in the current text. > Is there some reason why you want to implement three methods instead of in a green field not really. On the other hand if we assume I already have an implementation of the ia2 API wouldn't my life be easier if I could just use that as the atk impl too? > one? And given that there are four text boundaries (char, word, line, > sentence) that means handling 12 cases instead of four. I think the impl of the 3 methods for each boundary type can mostly be shared, and see above its 0 extra work if you're already implementing ia2 anyway. thanks! Trev > On a related note, there were very few instances in Orca of the END > boundary. And now there are none. Orca master is strictly relying upon > the AT flavor when getting text and is only getting text for the START > variant. the ATK and AT-SPI2 text simplification can safely begin now. > <smiles> > > --joanie > > _______________________________________________ > gnome-accessibility-devel mailing list > gnome-accessibility-devel@gnome.org > https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
