Re: [Fwd: Mousetweaks: integrate into GNOME Shell or keep in its current form?]

[Matthias Clasen <matthias clasen gmail com>]

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