The conversation about the future of Speakup is important as witnessed by the flurry of mail here this past few hours. However, we've also strayed into the usual range of related issues. I'd like to put in a place holder for a fundamental question: What are our console screen reader requirements? We should, imo, have community consensus on our requirements, probably backed by use cases, than we can clearly communicate. Had we had such back in the mid 2000's, pulse might have been designed better. I say this about pulse, because I don't believe it meets one key requirement we have, low-latency response, char by typed char, word by word, etc. To my mind we'd be better served by jack where latency and high priority execution are core values. So, what are our requirements? 1.) Latency. Very low, and highly responsive feedback in the consumption of keyborad input, whether into the system or as screen review. 2.) Access to on screen messages as early and late as possible, as close to boot, and as late in shutdown as possible. Then, if we have to move to console. What we we like that we have not had since Kirk first published his kernel patch back 20 years ago? Here's my top ask: A. Context aware profiles. DOS had this in spades. You could know what application had focus and adjust the screen reader behavior accordingly. ASAP and Vocal-Eyes were brilliant at responding to WordPerfect, Commo, etc., etc. If we're going to console space, let's make sure we can be app focus aware. What else? Janina John G. Heim writes: > I've never seen a server without a serial port. > > > > On 10/08/14 14:43, Kyle wrote: > >It does appear to me that something like this will force more of Speakup > >into userspace. However, unlike others, I'm not entirely opposed to the > >idea of Speakup leaving the kernel, and I think it can only be a good > >thing, especially on newer machines, where dedicated serial ports are > >all but obsolete, and software in userspace can take better advantage of > >things like Pulseaudio and libusb, meaning more extensive software and > >hardware speech support. For example, there would no longer be a need > >for kernel modules to control speech synthesizers, and there would no > >longer be a need to have external userspace connectors such as Espeakup, > >as the entire Speakup screen reader could be moved into userspace, and > >anything that interfaces with a speech synthesizer could be either > >internal or could be a library that interfaces with a speech API like > >speech-dispatcher or others. Even better, if Speakup is moved entirely > >into userspace, it could give rise to far better access to consoles on > >*BSD and other Unix operating systems, as the code could be far more > >portable between operating systems when it doesn't have to be tied into > >a specific kernel. Just my $0.02 BSD. That's Bahamian dollars lol. > >~Kyle > >http://kyle.tk/ > > > _______________________________________________ > Speakup mailing list > Speakup@xxxxxxxxxxxxxxxxx > http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@xxxxxxxxxxxxxxxxxxxx Email: janina@xxxxxxxxxxx Linux Foundation Fellow Executive Chair, Accessibility Workgroup: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Protocols & Formats http://www.w3.org/wai/pf Indie UI http://www.w3.org/WAI/IndieUI/ _______________________________________________ Speakup mailing list Speakup@xxxxxxxxxxxxxxxxx http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
