On 11/22/2013 02:56 PM, Matthias Clasen wrote: > Hey Magdalen, > > thanks for bringing this discussion to the lists. I tried to read it > all, but failed somewhere in the middle... but I think what I've read > so far is enough to reply meaningfully.
Hi Matthias, thanks for your quick answer. > > As I've said to Joanie and API in Montreal, we probably need a > privileged Wayland interface for ATs to obtain global information like > the pointer position and the surface under the pointer. This will be > needed to support some of orcas functionality. And I don't think it > makes sense to fold the screenreader into the compositor. Could you elaborate "fold the screenreader into the compositor"? The thread that forwarded Magdalen got somewhat messy after several answers, but as far as I understood, we never proposed to move the screenreader to the compositor. We were just debating about some functionality/info that we got from X, and that now we need to get from somewhere else (Wayland or the compositor). > > > Reimplementing mousetweaks in gnome-shell would have a lot of > advantages. It would be easy to get mouse-events and the > click-selection > window could be integrated directly into the chrome. It's currently > impossible to drag things around in the Activites overview, > because you > can't change the hover-click type from within the overview. Another > advantage would be that we save a lot of code. Probably 90% of > mousetweaks only deals with being a daemon and getting various events, > the actual hover-click logic is only a tiny part > > > I agree that the story is different for mousetweaks and other > input-focused accessibility features. It makes much more sense to do > this directly in the compositor, who is already responsible for > multiplexing input events. Adding a roundtrip through some api to an > external process only makes things less efficient, more fragile, and > much more complex. Just do it in the compositor. Ok. > > There is however one problem, if all the features move into > gnome-shell > then mousetweaks becomes a GNOME-only solution. At the moment > mousetweaks works fine on Unity, lxde and even KDE. It can also be > used > as a service. For example the default on-screen keyboard on Ubuntu > (onboard) integrates mousetweaks into its interface. You can activate > hover-click and select the different click-types directly with the > keyboard. > > > mousetweaks will still be available for other desktops that don't have > mouse accessibilty builtin. I think that Magdalen was talking about the wayland case. > > I find it a bit ominous that GNOME accessibility tools have > integration with the Ubuntu onscreen keyboard but lack the same > integration with GNOME's builtin OSK. Caribou has been during a long period basically maintainer-less. Daiki has been his maintainer during relatively a short period, and in spite of that, he was already working on some accessibility features (on top of non-accessibility tasks for caribou). During GUADEC he showed us some accessibility improvements (pending to be merged) to GNOME's builtin OSK, like scanning modes. In the same way he has Wayland on his roadmap (drafts here [2]). Better integration with mousetweaks would be good, but there were other priorities, imho, taking into account that mousetweaks and the OSK were properly working together, although not integrated. BR [1] https://wiki.gnome.org/DaikiUeno/Caribou/Wayland -- ---- Alejandro Piñeiro
_______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
