Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

From https://notepad-plus-plus.org/

..., Notepad++ is written in C++ and uses pure Win32 API and STL which ensures a higher execution speed and smaller program size.

And which lets it piggy-back on Windows' accessibility features, which seem to be quite good.

I guess Sublime Text and Atom draw their own GUIs to get more control over the look-and-feel, but don't add the necessary hints to make screen readers work.



You're right about the advantage of using standard Win32 controls. But you omitted an important part of that sentence you quoted from the website: "Based on the powerful editing component Scintilla". Scintilla is indeed a custom control, and it doesn't implement either of the Windows accessibility APIs (UI Automation or Microsoft Active Accessibility, let alone MSAA's unofficial extension IAccessible2). So why does it work with a screen reader?

First of all, Scintilla doesn't work with all screen readers. I know for sure that it doesn't work with Narrator. So why does it work with NVDA, the OP's choice of screen reader?

The answer is basically an accident of Windows's history. Going back to the very beginning, the main way that an application queried or manipulated a Windows control was by sending it window messages. Because early versions of Windows had cooperative multitasking and no security, any application could send messages to any other application's windows. Presumably for backward compatibility, or perhaps because nobody thought to do it differently in the 90s, this openness was carried forward into Win32, including Windows NT. Some limitations have been added for security, particularly in Vista, but basically, if any two apps are running under the same user account, they can send window messages to each other.

It turns out that this capability is very useful for screen readers and other assistive technologies. Even after Microsoft introduced the Active Accessibility API sometime between Windows 95 and Windows 98, that API had some gaps, particularly when it came to working with editable text controls and multi-column list views. Screen readers worked around these deficiencies by using the window messages provided by these standard controls.

So, Scintilla exposes its own window messages, and NVDA uses those to make it accessible. I do wonder why Scintilla took this route, especially since it's multi-platform. It could have simply exposed a C API. In that case, it would be much less accessible (completely inaccessible if it uses something newer than GDI to render its text), unless it implemented UI Automation or IAccessible2. So, really, screen reader users just got lucky in this case.


This is correct. By sticking to pure Win32 controls it allows screen readers to do their job properly. While making your own controls or using third party UI libraries will give you a nicer looking UI it makes the screen readers job much harder if not impossible.


There must be an API for it though, right... That being my first reaction, after thinking about it again, well, a custom UI that is accessible and cross-platform... Maybe a semantic web site IS the holy-grail in that regard? ARIA[1] seems more detailed than Qt-quick[2], at least.

[1]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [2]: http://doc.qt.io/qt-5/qml-qtquick-accessible.html



Wouldn't a proper structured editor be more suitable for blind coding? The market isn't large but I can't imagine blindly navigating through a sea of characters. Sounds terrifying.


People once coded in ed and it is kinda like coding blind. You don't have a display, instead you can move to specific line numbers and print or replace them. It sounds impossible at first but you get used to it if you only use ed.


I've been thinking that doing a "30 day command-line challenge" might be cool, idea being that you'd be limited to command-line based tools only. No fancy visual editors or ncurses browsers. Just pure line-oriented bliss (or more likely, hell). ex would be likely candidate for text editor in such experiment.


What options even exist outside of ex in that case?


If you want something even more bare-bones than ex or ed, you could use cat as a write-only editor. In combination with head and tail, replacing parts of a file would be possible as well.


I suppose you could also use TECO: http://almy.us/teco.html


Or sed, which for many editing purposes is probably easier to use.


Sure, but sed is basically just ed in non-interactive mode, so not very different from ex. And ex on my system is basically just vim without instant redraw after each change. And then you're back in terminal-GUI land.

It's interesting how the ancestors of modern editors are still around as living fossils ...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: