Closed
Bug 383095
Opened 17 years ago
Closed 17 years ago
implement IAccessibleApplication
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: surkov, Assigned: surkov)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
5.51 KB,
patch
|
neil
:
superreview+
|
Details | Diff | Splinter Review |
Assignee | ||
Comment 1•17 years ago
|
||
Aaron, any idea what these methods should return for firefox/seamonkey/tbird/xul runner application? /** @brief Returns the application name. [propget] HRESULT appName /** @brief Returns the application version. [propget] HRESULT appVersion /** @brief Returns the toolkit/bridge name. [propget] HRESULT toolkitName /** @brief Returns the toolkit/bridge version. [propget] HRESULT toolkitVersion
Comment 2•17 years ago
|
||
For example: appName = Firefox appVersion = 3.0 toolkitName = Mozilla toolkitVersion = 1.9
Assignee | ||
Comment 3•17 years ago
|
||
Attachment #269422 -
Flags: review?(aaronleventhal)
Assignee | ||
Updated•17 years ago
|
Status: NEW → ASSIGNED
Comment 4•17 years ago
|
||
Will/Joanie/Scott -- look at comment 2 and see if you need this info somehow in AT-SPI ... perhaps via object attributes?
Comment 5•17 years ago
|
||
toolkitName will probably be needed. It was needed in LSR to branch when the Gecko toolkit deviated from GTK apps. This property along with appName have been available via IAccessible. Has this changed? I don't see a need for the other properties at the moment.
Comment 6•17 years ago
|
||
I see we still have code to provide the toolkit name and version in accessible/src/atk/nsAppRootAccessible.cpp atk_class->get_toolkit_name = mai_util_get_toolkit_name; atk_class->get_toolkit_version = mai_util_get_toolkit_version; Alexander, does that provide the same results as what you're doing here?
Assignee | ||
Comment 7•17 years ago
|
||
(In reply to comment #6) > I see we still have code to provide the toolkit name and version in > accessible/src/atk/nsAppRootAccessible.cpp > > atk_class->get_toolkit_name = mai_util_get_toolkit_name; > atk_class->get_toolkit_version = mai_util_get_toolkit_version; > > Alexander, does that provide the same results as what you're doing here? > mai_util_get_toolkit_name is "Gecko", I suggested to use "XULRunner". Probably "Gecko" is more correct. mai_util_get_toolkit_version and nsIXULAppInfo::platformVersion looks like the same, both they provide gecko version. Though technically they are defined by different constants. I'm not sure what is more right I just found nsIXULAppInfo interface and thought it looks right to use here :)
Comment 8•17 years ago
|
||
Comment on attachment 269422 [details] [diff] [review] patch It's fine. Are you sure ::SysReAllocStringLen is the right allocation function. Why is reallocation when aName is null. If there is a SysAllocStringLen maybe use that.
Attachment #269422 -
Flags: review?(aaronleventhal) → review+
Assignee | ||
Comment 9•17 years ago
|
||
(In reply to comment #8) > (From update of attachment 269422 [details] [diff] [review]) > It's fine. Are you sure ::SysReAllocStringLen is the right allocation > function. Why is reallocation when aName is null. If there is a > SysAllocStringLen maybe use that. > I shouldn't use ReAlloc if I NULLize the given string. It looks more correct if I will use SysFreeString() and in the end SysAllocString. Right?
Comment 10•17 years ago
|
||
I don't know, but you could ask Neil if you're not sure what the right way is. Otherwise if you're sure you know, just check in.
Assignee | ||
Updated•17 years ago
|
Attachment #269422 -
Flags: superreview?(neil)
Assignee | ||
Comment 11•17 years ago
|
||
Neil, please look at comment #9.
Comment 12•17 years ago
|
||
We decided to use "Gecko" for toolkit name for ATK 1 year ago. Can we use the same name for MSAA ?
Assignee | ||
Comment 13•17 years ago
|
||
(In reply to comment #12) > We decided to use "Gecko" for toolkit name for ATK 1 year ago. > Can we use the same name for MSAA ? > I think we can. I called it "XULRunner" because iirc in future all applications will be built on top of XULRunner. But we can hold "Gecko" since it is historical.
Comment 14•17 years ago
|
||
> in future all applications will be built on top of XULRunner
Actually, that's not assured at this point. I've heard that it's not happening. It seems to go back and forth.
I agree "Gecko" is best.
Comment 15•17 years ago
|
||
Comment on attachment 269422 [details] [diff] [review] patch > STDMETHODIMP > nsApplicationAccessibleWrap::get_appName(BSTR *aName) > { >- return E_NOTIMPL; >+ aName = NULL; These (you do this twice) are wrong; aName is really an OLECHAR** in out parameter. You can just remove them. > STDMETHODIMP > nsApplicationAccessibleWrap::get_toolkitName(BSTR *aName) > { >- return E_NOTIMPL; >+ *aName = ::SysAllocString("XULRunner"); >+ return S_OK; > } Again, it's an in out parameter, so you need to use ::SysReallocString. sr=me with these fixed.
Attachment #269422 -
Flags: superreview?(neil) → superreview+
Assignee | ||
Comment 16•17 years ago
|
||
(In reply to comment #9) > It looks more correct if > I will use SysFreeString() and in the end SysAllocString. Right? > Neil, probably is it better because I need to truncate string if method fails?
Comment 17•17 years ago
|
||
(In reply to comment #16) >Neil, probably is it better because I need to truncate string if method fails? Sorry, I don't know COM that well... personally I wouldn't bother.
Assignee | ||
Comment 18•17 years ago
|
||
Neil, please look one more time on patch
Attachment #269422 -
Attachment is obsolete: true
Attachment #271034 -
Flags: superreview?(neil)
Comment 19•17 years ago
|
||
Comment on attachment 271034 [details] [diff] [review] patch2 >+ if (!sAppInfo) >+ return S_OK; Is that the correct return code? >+ nsAutoString name = NS_ConvertUTF8toUTF16(cname); NS_ConvertUTF8toUTF16 name(cname); sr=me with this nit fixed in each method.
Attachment #271034 -
Flags: superreview?(neil) → superreview+
Assignee | ||
Comment 20•17 years ago
|
||
checked in with Neil's comments.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•