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.
> yeah I didn't see your mail until now. Sorry. Francesco and I haven't > really talked about the future of mousetweaks since your gsoc mails. > (congratulations by the way) > > I think porting mousetweaks in its current form to wayland is not going > to work. To implement hover-click we would need 2 things: a) get global > mouse-motion events and b) synthesize/fake mouse button events. A > regular application can do neither under wayland. I can think of 2 ways > to solve this, either move everything into gnome-shell as you suggest, > or keep mousetweaks as a standalone daemon and use at-spi. > > at-spi has API for global mouse-events (AtspiEventListener + "mouse:*" > events) and for faking mouse events (atspi_generate_mouse_event()), but > both operations don't work under wayland at the moment. Until those > things are implemented we can't start our port. > 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. > 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. 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 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. Matthias
_______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
