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

[Piñeiro <apinheiro igalia com>]

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