.

target 3.1

No time left to fix this for OOo 3.1 because of other issues.

Fixed in CWS swa11y32.

Files changed:
svx:
M      source\accessibility\AccessibleEditableTextPara.cxx
M      source\accessibility\AccessibleEditableTextPara.hxx
M      source\accessibility\AccessibleEmptyEditSource.cxx
M      source\accessibility\AccessibleStaticTextBase.cxx
M      source\editeng\impedit.hxx
M      source\editeng\editeng.cxx
M      source\editeng\impedit2.cxx
M      source\table\celleditsource.hxx
M      source\unoedit\unofored.cxx
M      source\unoedit\unoedprx.cxx
M      source\unoedit\unotext.cxx
M      source\unoedit\unoviwou.cxx
M      source\unoedit\unoforou.cxx
M      source\inc\unoedprx.hxx
M      inc\svx\unotext.hxx
M      inc\svx\unofored.hxx
M      inc\svx\unoshtxt.hxx
M      inc\svx\unoforou.hxx
M      inc\svx\editeng.hxx
M      inc\svx\unoedsrc.hxx
M      inc\AccessibleStaticTextBase.hxx

starmath:
- M      source\accessibility.cxx
- M      source\accessibility.hxx

.

tl->williewalker: Since I was told you will probably the one to verify this
implementation I'm adding you to CC.

tl->williewalker: Since I was told you will probably be the one to verify this
implementation I'm adding you to CC.

williewalker->tl: sure thing. :-) I just need a pointer to an OOo build
containing the fix.  I also assume you want me to test this from the standpoint
of http://bugzilla.gnome.org/show_bug.cgi?id=508846.  Is that correct?

tl->williewalker: About http://bugzilla.gnome.org/show_bug.cgi?id=508846.

Basically, from the point of our UNO API I would think 'no', because there is a
dedicated function call for that. Which is getTextAtLineWithCaret in the
XAccessibleMultiLineText interface.

tl->mt: What do you think?

obr->tl: getTextAtLineWithCaret got introduced exactly to be able to support
http://bugzilla.gnome.org/show_bug.cgi?id=508846, the mapping between magic
index and dedicated API takes place in the UNO <-> ATK bridge.

tl->obr: That is the XAccessibleText and XAccessibleMultiLineText in sw and svx
does NOT need to take care of the -2 thingie?

yes, exactly.

williewalker->tl: so, I'm kind of confused about what this specific
implementation exposes to the AT-SPI.  It seems like this might be for the Mac
OS X implementation, which is currently out of my domain.  :-(

The GNOME '-2' index problem is one purpose of this interface, the OS X
implementation is the other. 

So testing against the http://bugzilla.gnome.org/show_bug.cgi?id=508846 is the
right thing, even though there should be someone else testing the other part of
the interface (probably on OS X) as well.

What Will probably needs to know is where the "EditEngine" is used in the
office, so that he better knows where to look.

tl: Ok. The most obvious places where the EditEngine is used are:
- drawing objects in Writer
- the table cells in Calc
- Impress and Drawing applications
- the window where you enter the formula text in starmath
- the controls within forms (see "File/New/XML Form Document") if(!) the control
  is set to multi-line.
Note this list is probably incomplete since I do not know all places where the
EditEngine is used myself.

If I'm not mistaken those controls that are making use of the TextEngine should
have already implemented the XAccessibleMultiLineText interface as well long
since. An example of such a control using the TextEngine should be the text
display of the Basic macro editor.

Also that interface is already available in Writer paragraphs.
Thus I would tend to say: Whenever you encounter a multi-line, editable text
control where that interface is not working a issues should be written.
Unfortunately there is no easy way to provide you with a complete list of such
controls.

Maybe you can do it indirectly on your own: I think it should be expected now
that every accessible object that implements the AccessibleRole of type
PARAGRAPH is supposed to have implemented the XAccessibleMultiLineText interface
now. Thus if you can modify your tool to check for this we may be able to find
any implementation that might be still missing.

tl->obr: do you have another idea how to find any still missing or not working
implementations?

> tl->obr: do you have another idea how to find any still missing or not working
implementations?

We could add assertions to the UNO <-> ATK bridge and do a full automated test
cycle with e.g. accerciser running.

mt->tl/obr, I think we can simply believe that everything is fine now.

We have exactly 3 implementations of text engines which can have paragraphs with
multiple lines _and_ can have a caret: Writer, EditEngine, TextEngine.
So if each of these is tested in one place, I don't see a reason why it
shouldn't work on other places.

There is also some multi-line text used in widgets, which is not implemented
with one of these engines (but using special drawtext features), but non of
these can have a caret so don't need this interface.

Malte.

tl->es: probably you want to reassign this one to williewalker. But since I'm
not completely sure about this I first hand it over to you. ^_-

This fix has been confirmed by the Orca team using the
swa11y32_2nd_en-US_SolarisIntel.tar file Thomas Lange made for me
(300m51(Build:9408)[CWS:swa11y32_2nd]).

Many thanks!

This fix has been confirmed by the Orca team using the
swa11y32_2nd_en-US_SolarisIntel.tar file Thomas Lange made for me
(300m51(Build:9408)[CWS:swa11y32_2nd]).

Many thanks!

Thanx for verifying!

Fixed and integrated => closing now..