Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Improve accessibility of Find dialog (+small stuff) #1221
These commits improve accessibility of Find dialog by setting accessibility
While I was at it, I improved a little bit in the same spirit old code for
I am not sure with
Also there is one issue - the Find/Replace history menu is in a new window
I release these patches into public domain.
The button for showing results count in find dialog is meant to quickly provide the user just with the information about number of search results. Unlike with full search, where the resulting information is very large and has to be presented in a table, this information the user is requesting is very short ("%d occurences of \"%s\"") so can be, for better VoiceOver user experience, presented directly to the user without requiring them to leave the Show Results Count button. Without this addition, in order to learn this short information, VoiceOver user would have to move to the status string below the results table after pressing the button to learn this short information. Due to technical reasons, the implementation is not strict: - it requires the user to stay on the Show Results Count button until the results count gets displayed (issue for searches longer than 1-2 seconds where user might move away from the button), otherwise the user is not notified of the result and has to move to the status string to learn it - any changes to the status string not related to results count (e.g. if the user has launched a full-fledged search reporting each directory searched) are being reported while the user is on the Show Results Count button (which should happen really seldom in such a case - Voiceover user would probably not "park" their VoiceOver cursor on this button when doing a full fledged search)
Thanks as always! Merged as 9f177d3...25b3a5f.
There are also command results which may show (custom) tool tips which should also be announced, although here I could associate them with the text view (as I did for 5f94f46), though in practice the user can invoke commands without a text view.
Something else related to announcements: TextMate uses a few menu delegates where it implements
It looks to me that the API does not actually allow Apple to announce the selected menu item, since the delegate method return target and action, not any actual menu item found. Do you know anything about this?
Something else, is ec491a4 the best way to get an
As for the history pop-ups, I would like to retire these custom (modal) windows. I think the main problem with using an
Unfortunately I don't have a better suggestion as I think there is no API to announce something globally. I tried specifying
I tried it (⌘G) and this is great! Also I will look into how to make document statistics (⌃⇧N) accessible via an announcement.
I noticed that issue.
Unfortunately no. But it seems the menu item (or its deepest visible ancestor - "Go" top-level item) gets highlighted when pressing ⌘1-⌘3 in file chooser and that should IMHO be enough for VO to announce it. Probably again a good topic for Apple's accessibility mailing list, I will ask that question there after making a minimal repro.
I noticed this commit, thanks for this work to clean the status bar. I submitted 4ec184a in #1224 with something I consider "better". I bet there could be discussions and fights which approach is better, just like the legendary which one of Emacs vs. vim is better (it's TextMate 2 :-P). But in general,
Yeah, when I saw the interface, I was thinking that it is, by the real meaning of the UI, a combo box (editable text field with value changeable either by editing the text or by choosing a value from menu). Making it into