On Fri, Mar 11, 2016 at 02:13:03PM +0800, Jonas Ådahl wrote: > Hi, > > On Fri, Mar 11, 2016 at 06:51:35AM +0100, Timofonic wrote: > > Please consider mandatory high contrast option with custom colors. I prefer > > black background and green foreground, it's a lie better for Mr eyes > > because clear colors really tire me. > > There is no way for a compositor to enforce this, and it has been a > design decision so far to not let Wayland become some kind of settings > broadcaster. I'm not aware of the current situation of cross desktop > settings system except XSettings that obviously can't be used. > > > > > Text-To-Speech and braille devices should be very seriously very taken in > > consideration too, please. I know many people work degenerative vision > > issues that will eventually very totally blind, some of them are Linux > > enthusiasts. > > Yes these are very important things that we must support. Text-to-speech > I assume could be implemented in a similar way as input methods (like > pinyin or on-screen-keyboard). Braille keyboard support I suspect would > be implemented in libinput or something similar, and use the same > Wayland protocol as input methods (the text input protocol that is being > worked on).
braille keyboards could be implemented through libinput with a keysym event (instead of the current keycode + xkb layout approach), but I don't have access to one and dont' have a good description yet on how it all should look like on the lower levels of the stack. Cheers, Peter > > As for braille output, this is part of the screen recorder system (for > example Orca), which currently is done without any interaction using > Wayland. > > > > > Let the the client side decide isn't a good option at all! Not homogeneous > > behavior and many lazy efforts would make accessibility broken very often. > > I've seen that lots of times! > > > > And please consider to involve developers having related disabilities:They > > would know how to implement an usable accessibility, because they use it > > all time and as users know what's right or wrong on many software. > > > > Thanks for all. > > > Jonas > > > > > On March 10, 2016 7:43:13 PM CET, Matthias Clasen > > <matthias.cla...@gmail.com> wrote: > > >Hi, > > > > > >I would like to discuss strategies for implementing accessibility > > >features in Wayland that will be needed for a fully featured desktop. > > >There's a whole list of individual items, but for now I'd like to > > >focus on keyboard accessibility features, ie roughly the feature that > > >traditionally labeled AccessX: > > > > > >- slow keys (only accept key presses after a delay) > > >- sticky keys (support one-key-at-a-time operation by latching and > > >locking modifiers) > > >- bounce keys (reject quick key presses of the same key) > > >- toggle keys (special key bindings to enable the aforementioned > > >features: hold-shift-for-8-seconds for slow keys, > > >shift-5-times-in-a-row for sticky keys) > > > > > >The following two are not technically AccessX, but are close enough to > > >include them: > > >- key repeat > > >- visual bell (all of the AccessX features have configurable bells; > > >the visual bell can be configured to be per-window or global) > > > > > >Under X, all of these features are implemented in the XKB code in the > > >server (the visual bell gets handled by a client that selects for for > > >XkbBellNotify. In GNOME, that is mutter). > > > > > >Wayland uses libxkbcommon to implement xkb-like keyboard handling, but > > >as far as I know, no Wayland compositor currently implements any of > > >the features I listed above. xwayland inherited the X server > > >implementation and thus, X clients do get AccessX features, but > > >Wayland clients don't. Not an ideal situation. > > > > > >In GNOME, we have a client-side implementation of key repeat, which > > >has some issues that we recently worked around by introducing an extra > > >roundtrip before synthesizing repeat presses. I recently spent an > > >evening trying to see how far I can get in implementing AccessX > > >client-side (see > > >https://git.gnome.org/browse/gtk+/log/?h=matthiasc/wayland/slowkeys). > > >The results were mixed, I would say. While I have mostly working code > > >for all of the AccessX features, there are some limitations: > > > > > >- For 'true' slow keys, the modifier keys should be delayed as well. > > >My client-side implementation does not do that, since the modifier > > >processing happens compositor-side, and I can only delay the events > > >that already have modifiers applied. > > > > > >- I did not attempt to implement the visual bell client-side; flashing > > >the screen by mapping a fullscreen window temporarily would just be > > >too much of a hack. More recently, Jonas added a bell request to the > > >private gtk_shell interface between gtk+ and mutter, so we can now > > >reuse the existing (visual and audible) bell handling code in mutter. > > > > > >- Handling the toggle keys client-side means that you can only enable > > >AccessX features if a client has focus; this needs to be handled in > > >the compositor so using one of these shortcuts can be the first thing > > >you do after stepping up to the computer, regardless if a client has > > >focus or not. We also loose a feature compared to the X session: under > > >X, we show a notification asking for confirmation ("Did you mean to > > >turn on SlowKeys?") when the toggle keys features are triggered from > > >the keyboard, to keep users from accidentally 'breaking' their > > >keyboard by resting their finger on the shift key. We can really send > > >notifications from deep inside a GDK backend. > > > > > >- Doing this client-side implementation in GTK+ does not help one bit > > >for SDL or Qt or E or toytoolkit clients. > > > > > >I know that one of the guiding principles of the Wayland architecure > > >is 'client-side', but I think the limitations listed > > >here are significant enough to argue for a compositor side > > >implementation of keyboard a11y. I don't think that this needs (a lot > > >of) new protocol, except for maybe a way to query and monitor state > > >related to these features. > > > > > >One small complication with implementing AccessX compositor-side is > > >that we have one client that currently does it client-side: xwayland. > > >It would need a patch to force-disable AccessX there. This is also why > > >I think there should be project-wide agreement on whether these > > >features belong in the compositor or not. It would be really > > >unfortunate and bad for interoperability if we end up in a future > > >where these features are implemented server-side in GNOME, but > > >client-side in KDE or the other way around. > > > > > >For the implementation itself, I guess it really belongs into > > >libxkbcommon, although that means it needs timers (or hooking up to a > > >mainloop). I find it intriguing that libxkbcommon/src/state.c has this > > >comment: > > > > > >/* > > >* This is a bastardised version of xkbActions.c from the X server which > > > * does not support, for the moment: > > > * - AccessX sticky/debounce/etc (will come later) > > >... > > > > > >Daniel, do you still have plans in this area, or did 'later' turn out > > >to be 'never' ? > > >If not, any pointers for where somebody else would start digging into > > >this ? > > > > > >Anyway, I'd like to hear people's thoughts about this topic. > > > > > > > > >Matthias > > >_______________________________________________ > > >wayland-devel mailing list > > >wayland-devel@lists.freedesktop.org > > >https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > -- > > Enviado desde mi dispositivo Android con K-9 Mail. Por favor disculpa mi > > brevedad. > > > _______________________________________________ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
