Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider presentationType for IAccessible.ContentGenericClient #2903

Closed
nvaccessAuto opened this issue Dec 28, 2012 · 10 comments
Closed

Reconsider presentationType for IAccessible.ContentGenericClient #2903

nvaccessAuto opened this issue Dec 28, 2012 · 10 comments
Labels
close/wontfix enhancement p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority

Comments

@nvaccessAuto
Copy link

Reported by jteh on 2012-12-28 22:20
In some applications (such as Sonar), there are a lot of !ContentGenericClient NVDAObjects. These are always forced to presType_content, which results in a lot of unknowns in simple review.

  1. It shouldn't override presType_unavailable.
    • For performance reasons, we may want to check for invisible and unavailable directly, rather than calling super.
  2. It might be worth considering making these layout if value is None, though I'm not sure about that.

Mick, thoughts?

@nvaccessAuto
Copy link
Author

Comment 1 by mdcurran on 2012-12-29 06:28
In theory the current code is wrong as it should not override unavailable. However, due to my fix for #2904, I'm struggling to think of a way presentationType on a contentGenericClient would ever be hit as now if the window is unavailable or invisible itself, simple object nav won't go in it to get to the ccontentGenericClient anyway. Unless perhaps there's another usage of presentationType I'm forgetting hear...

@nvaccessAuto
Copy link
Author

Comment 2 by jteh on 2012-12-29 06:36
The only thing I can think of is if accNavigate lands there, but I guess our correctAPIForRelation stuff should push us to the window anyway.

Your thoughts on the second point (layout instead of content in some cases)?

@nvaccessAuto
Copy link
Author

Comment 3 by mdcurran on 2012-12-29 06:41
Again, not too sure how much difference it would make. ContentGenericClient is only used if childCount is 0, therefore there'd be nothing for simple nav to jump down to inside.

@nvaccessAuto
Copy link
Author

Comment 4 by jteh on 2012-12-29 06:47
Err, but aren't layout objects skipped when going next/previous? I mean even when they aren't unavailable or invisible.

Right now, in Sonar, you get a whole lot of "unknown, unknown, unknown" when going previous from the Track pane.

@nvaccessAuto
Copy link
Author

Comment 5 by mdcurran on 2012-12-29 06:51
True. I guess it would be okay to do this, though things may appear and disappear randomly due to perhaps no redraw or display content. I'm not too bothered though, if it significantly helps... and I guess people can turn off simple review to get to them again if needed.

@nvaccessAuto
Copy link
Author

Comment 6 by jteh on 2012-12-29 06:58
Alternatively, if you don't believe this is suitable, I can just do it for Sonar. Maybe we should do that for now and revisit this bug later if we see it a lot elsewhere? Feel free to wontfix for now on those grounds.

@nvaccessAuto
Copy link
Author

Comment 7 by nvdakor on 2013-11-02 07:44
Hi guys,
Facing the same problem for Goldwave as well - I can verify that at least Goldwave's main window (without any track opened) does return contentGenericClient as object type, which is proving to be quite a challenging when writing appModule for Goldwave (although you cannot navigate to child objects, you can still view the contents of the window that NVDA should have caught when navigating via object navigation if you use screen review). Thanks.

@nvaccessAuto nvaccessAuto added this to the near-term milestone Nov 10, 2015
@jcsteh
Copy link
Contributor

jcsteh commented Jun 23, 2016

We decided to expose ContentGenericClient as layout if there is no value and it isn't focused.

@jcsteh jcsteh removed this from the near-term milestone Jun 24, 2016
@nvaccessAuto nvaccessAuto added the p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority label Jul 5, 2016
@Adriani90
Copy link
Collaborator

@jcsteh, @michaelDCurran could you please give a short update on this? Thank you.

@jcsteh
Copy link
Contributor

jcsteh commented Nov 25, 2018

The decision made concerning the implementation of this issue is explained in #2903 (comment). Having said that, I no longer personally care about this and I was the one driving it, so I'm going to close this. It can always be reopened should someone care in future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
close/wontfix enhancement p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
Projects
None yet
Development

No branches or pull requests

3 participants