Hello,
Emmanuele Bassi, on jeu. 01 mars 2018 14:42:27 +0700, wrote:
> On 26 February 2018 at 17:49, Samuel Thibault
> <samuel thibault ens-lyon org> wrote:
> > Hello,
> >
> > So, I also saw the removal of generic modules.
> >
> > Unfortunately we currently need it for implementing perfect zoom feature
> > :)
>
> I don't know what a "perfect zoom feature" is —
Please compare the two attached examples :)
zoom-gimp.png is the kind of zoom you can get with state-of-the-art
zooming heuristics. zoom-perfect.png is simply obtained by getting gtk
to redraw the window into a bigger pixmap.
> but zooming on a window should be part of the display server.
The display server can not invent information, at best it could
achieve the zoom-gimp.png result, which is really not enough for
visually-impaired people. Here I have only magnified a couple of times,
people quite often request for 10x-30x magnification.
The compositor can say to the toolkit to render with a different scaling factor - we do that for hidpi so toolkits already know how to deal with it. No need to do vector rendering; after all, things are rendered to pixmaps anyway, not using vector based API.
Also, the control on zooming should really not implemented in the
server. Usually you'll also want color inversion or mangling, adding
position hints etc. I don't think freedesktop people will be happy to
see that added to the display server, so an external solution is needed,
currently implemented in Compiz (but lacking access to re-rendering on a
bigger pixmap).
Don’t really agree at all. Considering that Compiz is mostly dead, and that the current GNOME Shell already has logic for zoom, color inversion, and other effects, it’s perfectly capable of dealing with these requirements. Targeting an obsolete graphics stack is not going to get you anywhere - especially for a new major version of the toolkit, where we don’t have legacy code.
Ciao,
Emmanuele.
> Having said that, we do have a magnifier inside GTK, used by the
> Inspector. We could make that feature public, and improve it.
Interesting. Having mentioned adding the feature to AT-SPI, I'm
however interested in putting the interface there, so that not only GTK
application can benefit from it, but also Qt, etc. and GTK can just plug
its support into AT-SPI.
> We definitely do not want to let people inject code into running applications.
Ok :)
Samuel
