Re: [g-a-devel] No module anymore & perfect zoom feature

[Samuel Thibault <samuel thibault ens-lyon org>]

Alejandro, on mar. 06 mars 2018 09:35:01 +0100, wrote:
> On 05/03/18 15:32, Samuel Thibault wrote:
> > Bastien Nocera, on lun. 05 mars 2018 15:21:47 +0100, wrote:
> > > Perhaps, but you'd be doing a disservice to your users trying to
> > > implement this as a "can run anywhere" solution. I don't think there's
> > > any way you can implement this generically so that there's no work
> > > needed on other desktops.
> > >
> > > Implementing this in GTK+ and gnome-shell gives you the opportunity to
> > > experiment with an interface that should hopefully be applicable to
> > > other compositors, and compositing window managers.
> > It looks like there is a misunderstanding.
> >
> > I'm not saying that it has to be completely external to gtk and its
> > compositor. I'm saying that it has to be not only internal to gtk and
> > its compositor. The gnome desktop can be a testbed, sure, I'm just
> > saying that we have to keep in mind to have a generic interface that can
> > be implemented by other widget libraries, and used by other compositors.
>
> And related to misunderstandings and generic interfaces:
>
> That generic interface is what I asked you, and you replied with a
> really Gtk-tied API.

Again misunderstanding, sorry.  When I wrote

Pixmap GtkComponent::render(int width, int height)

Gtk slipped in from my fingers due to my work on libreoffice widgets.
I meant at-spi's Component, I was talking about an AT-SPI interface,
not something else.  I only mentioned gtk-vector-screenshot to explain
how it already worked with a gtk-ish interface, which we could try to
transpose to AT-SPI.

If only the world was letting us time to properly explain what we are
thinking...

> Lets say that we have a zoom application. And a specific application
> that you want to get zoomed. You originally asked if it would be
> possible to add a generic API on at-spi to do that. So my question is:
> do you have an approximate idea of that generic API to be included on
> at-spi that any toolkit could implement?

That was

Pixmap Component::render(int width, int height)

Basically, ask an at-spi Component to render itself with a given
width/height, and return a Pixmap.  Of course, how to transmit the
pixmap to the screen magnifier remains to be defined, but that was the
idea.

I agree that rather putting it in the compositor makes a lot of
technical sense, however, and it's easier to put screen magnification
there, my concern is about sharing the implementation.  Perhaps we could
make this a library that various compositors could use, I'm just a bit
afraid of the interface, not for the library to tell the compositor
what to do, but for the library to get the input it needs.  Currently
compiz' ezoom uses the mouse position only, but the extensions we are
experimenting with use at-spi's components positions and sizes, so it'd
mean that the compositor would end up talking with at-spi through that
library?

> FWIW, I'm not saying that we should force ourselves for that case. Just
> saying that seems the best candidate to see how things should be done,
> in order to have a good idea of how it could be expressed in a generic way.

Our concern is that while gnome is in general the most accessible
desktop thanks to these features, the rest of gnome poses a lot of
issues to our customers with really low vision or even blind, thus we
are currently sticking with MATE, it's hard to work on something which
we'll likely not use :)

Samuel