On Thu, 1 Mar 2018 at 20:48, Samuel Thibault <samuel.thiba...@ens-lyon.org> wrote:
> Hello, > > Emmanuele Bassi, on jeu. 01 mars 2018 14:42:27 +0700, wrote: > > On 26 February 2018 at 17:49, Samuel Thibault > > <samuel.thiba...@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 > -- https://www.bassi.io [@] ebassi [@gmail.com]
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
