NVDAObjects/UIA: recognize UWP tooltips#8124
Conversation
|
@josephsl commented on 25 mrt. 2018 19:44 CEST:
What UIA control type do these have? It would be nice if we could also support WPF tooltips this way, though I have no idea where to find these for testing purposes. |
|
Hi, haven’t investigated that far, but I assume they’re regular tooltips.
|
|
Hi, The tooltips are recognized as tooltips. Thanks. |
|
@josephsl commented on 26 mrt. 2018 09:21 CEST:
In that case, why not just treat every UIA tooltip as tooltip? |
|
Hi, not yet, as one of them is volume slider tooltip, which is annoying. Thanks.
|
|
@josephsl commented on 26 mrt. 2018 16:48 CEST:
Could you please elaborate? |
|
Hi, when you change audio volume, a tooltip comes up and fires tooltip open event. Although the framework is different, it is still annoying. Thus, I’ve intentionally limited tooltip announcement to XAML tooltips for now. Thanks.
|
|
@josephsl commented on 26 Mar 2018, 17:44 CEST:
I think many people consider tool tips to be annoying. I prefer consistency over subjective decisions about what is considered annoying and what is not. @michaelDCurran: Thoughts? |
|
I tend to agree with @LeonarddeR. If a choose to have tooltips reported, then I want to hear all tooltips. Obviously this can get annoying, thus why it is disabled by default in NVDA. |
|
Hi, Testing shows that I had incomplete assumptions: tooltip for volume slider is fired infrequently, thus I'll follow above recommendations. Thanks. |
|
Hi, Note that new UIA tool tip handling works properly on Windows 8 and later. An additional benefit is that NVDA will now also announce volume changes (if that is announced, that is). Thanks. |
|
Hi It is especially annoying if you adjust the volume during say all. It is not very user-friendly if the possible decision for tool tips is
|
|
@Robert-J-H commented on 21 Apr 2018, 08:45 CEST:
May be this is more a general problem of reporting tooltips during say all, not specifically to the volume tool tip.
What do you suggest otherwise? I don't think it is user friendly either to distinguish between several tool tips the user does not know about. |
|
Hi, this is due to the fact that the object in question fires tool tip opened event infrequently. I had similar objections due to this being not quite consistent, but ultimately it is up to users to decide. Thanks.
|
|
Yes, the user should be able to decide but the choices are like those of a political election with only one candidate.
MSDN gives a similar description, perhaps even narrower as they refer mainly to the mouse pointer. I think the best we can do is adding filter capability to the tooltip class such that add-ons can profit from it. This is the perfect occasion to use the extensionPoints.Filter class. |
|
Hi, Any additional comments? The filter mechanism is useful for text processing, not really a way to let overlay classes change things here and there. To do that, one must be willing to add conditions in the class itself, or let global plugins and app modules take ownership of this class (inheritance and overriding). Thanks. |
|
I haven't the extensionPoints code at my fingertips right now but I
think there's also the Decider class.
Registered functions would be notified about the tooltip source and
the text to be spoken.
They can then return either True or False to allow or prevent the
speaking of it. Thx
…On 17/06/2018, Joseph Lee ***@***.***> wrote:
Hi,
Any additional comments?
The filter mechanism is useful for text processing, not really a way to let
overlay classes change things here and there. To do that, one must be
willing to add conditions in the class itself, or let global plugins and app
modules take ownership of this class (inheritance and overriding).
Thanks.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#8124 (comment)
|
|
Hello, what is a status of this pr? |
|
Hi, Regarding deciders: this means extension points must be willing to deal with cases where tooltips are not announced because someone said "no" while the decider was running. I think this might not be what we want. For now, I'd treat tooltips from UIA as just tooltips. If there are no major objections, I propose that this be ready for master branch soon. Thanks. |
|
Hello, What is the status of this PR? It looks like it has been incubating for a while now. |
|
Hi, some small things here and there, and apart from that, and once it is approved, it should be ready for master branch. In case review comments are posted for this one, I’ll address them in November. Thanks.
|
|
Hi, Actually, it is ready to go - I think it's just the matter of when it'll be included in master branch, and I can address review comments in October. Thanks. |
|
Hello, what is the status of this PR now? I recently looked at the approved PRs and found that most of them did not merge. My idea is that I hope that the official can solve all the approved PRs and solve all the approved PRs, so that you can concentrate on developing and fixing problems and functions. The recommendations are for developers and maintainers only. Thank you |
|
I removed the incubating label from this as we're no longer using that label. Having said that, the fact that this has been incubating for a while suggest that the code is of enough quality and has been approved in the past. |
|
Hi, just a few things here and there and should be ready for another round of reviews – at least I heard no major reports about this in Windows 10 App Essentials, so it could serve as a basis for a review next week. Thanks.
|
|
Hi, Let me merge in master first. Thanks. |
|
Hi, Regarding review bits: yes, approved, but it won't hurt to let another pair of eyes/ears/hands take a look at this one before making this out to master. Thanks. |
|
Hm, I still see a lot of issues (see my remarks above).
The tooltip behaviour is somewhat erratic (not necessarily related to
UIA alone). For instance:
The tool tip for the last focused task bar icon is often announced
between focus changes within an application. In general, this doesn't
produce anything valuable.
Tool tips for desktop icons with focus (e.g. shortcut target) are
often wrong as they can come from the mouse object, rather than the
focused object.
I see this behaviour also in Reaper.
…On 18/05/2019, Joseph Lee ***@***.***> wrote:
Hi,
Regarding review bits: yes, approved, but it won't hurt to let another pair
of eyes/ears/hands take a look at this one before making this out to
master.
Thanks.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#8124 (comment)
|
|
This PR has the following error in the build: |
|
Hi. Likely caused by the old code, which will be fixed once master branch is merged. Thanks.
|
|
How can I test changes in this PR? @josephsl do you have files I can use to patch NVDA 2019.1.1? I can install any other version, too, if that would make it easier for you to share the fix. I'd like to verify whether this addresses issue where XAML tooltips are not announced in Visual Studio (VS is a Win32 app using WPF\XAML, not an Universal Windows app) |
|
Hi, I have suspended development of this PR for now. Thanks.
|
|
that's fine, I realized that NVDA does read some tooltips in VS, so this PR wouldn't have helped my case. Thank you! |
|
Hi, I'll make sure this PR passes checks. Thanks. |
Tooltips from universal apps are powered by XAML and has a specific class name (for now). Thus recognize them as proper tool tips.
…here this is coming from. Re nvaccess#8118
…g ones from volume slider and other controls. Re nvaccess#8118. Commented by Mick Curran (NV Access) and others: wrong assumption from my part - volume slider does not raise tool tip open event frequently, so this is safe to be called out. This is done by just checking for control type (same one as Windows 8.x toasts).
906c22f to
de33c30
Compare
|
Hi, I’ll rebase it on master unless there is no conflict merging this into master. Thanks.
From: Reef Turner <notifications@github.com>
Sent: Friday, July 26, 2019 6:42 AM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Joseph Lee <joseph.lee22590@gmail.com>; Mention <mention@noreply.github.com>
Subject: Re: [nvaccess/nvda] NVDAObjects/UIA: recognize UWP tooltips (#8124)
@feerrenrut approved this pull request.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#8124?email_source=notifications&email_token=AB4AXEBHZQEFJ53KQ7R7QB3QBL5JTA5CNFSM4EXI5RMKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB7WQYMY#pullrequestreview-267193395> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AB4AXEDBMX235UT4ZYPD7E3QBL5JTANCNFSM4EXI5RMA> .
|
Link to issue number:
Fixes #8118
Summary of the issue:
Recognize UWP/XAML tooltips such as ones from Microsoft Edge as proper tooltips.
Description of how this pull request fixes the issue:
Tooltips from universal apps are powered by XAML and has a specific class name (for now). Prior to this, these tooltips were not announced by NVDA. Cases include Edge's Settings button tooltip, which displays hotkey information (Alt+X) in Insider Preview builds. Thus recognize them as proper tooltips through an overlay class powered by NVDAObjects.behaviors.ToolTip.
Testing performed:
Tested Edge on Windows 10 Versions 1703 (Creators Update), 1709 (Fall Creators Update) and 1803 preview (Spring Creators Update).
Known issues with pull request:
None at this time.
Change log entry:
Bug fixes: In Windows 10, NVDA will announce tooltips from universal apps if NVDA is configured to report tooltips in object presentation dialog.