I agree with Carlos about this. The magnification service is best provided separately from the window manager.
If we had a plugin architecture for post-processing/compositing, then possibly the magnification service could be provided via such plugins to a WM-based compositor, but in the absence of such a plugin architecture, I don't think putting the gnome-mag functionality into the WM makes sense; gnome-mag already provides more API and more functions than a WM is likely to consider appropriate to integrate. Bill Carlos Eduardo Rodrigues Diógenes wrote: > On Thu, 2006-11-30 at 18:14 -0800, Peter Korn wrote: > >> Hi Carlos, >> >> I think the right answer is for the composite windowing managers to >> implement the gnome-mag API (or likely better still, some new API that >> we work out that doesn't depending upon CORBA). Starting with gnome-mag >> now (vs. waiting until we define a new API) would I think be the fastest >> way to significant magnification improvements. >> > > Okay, we really could have magnification improvements with this, but the > magnifier code stay very dependent, what is not good IMO, what do you > think about this? Do you think that have the magnifier so attached to > the window manager is a good idea? > > Really, I think these questions are dummy, since it's clear in your > answears that the magnifier must go inside the window manager and this > appear to be a community consensus, but I still find that leaving the > magnifier appart from the window manager is good. Maybe I'm the only > dumb guy that find that we must go in other direction. The reasons to > not embbed the magnifier in the window manager are so clear in my mind > that I can't move toward this direction. > > I really think that we must make applications easy to use, but we can't > make then inflexible and this is a direction to make the magnifier > inflexible. > > >> Regards, >> >> Peter Korn >> Accessibility Architect, >> Sun Microsystems, Inc. >> >>> Hi, >>> >>> When the window composite managers be all around how gnome-mag will >>> play? >>> >>> David Reveman give me the advice to write a compiz plugin and make >>> gnome-mag communicate with it when compiz is running. This is reasonable >>> for me, but we must have some kind of specification here, something that >>> I think that fit into the EWMH. >>> >>> First we must be able to know if the window manager running is a >>> composite manager (if not, gnome-mag use it's own composite code). >>> >>> Second, hints (I don't think that hints is a good way, since it must be >>> granted) for change the built-in window manager magnifier options must >>> be added, this way when gnome-mag receives a call to change the zoom >>> factor it will be sended to the window composite manager. >>> >>> I still want a functional magnifier if I don't want to use a specific >>> window manager. This is the only way that I see to make the magnifier >>> portable enough between different window composite managers without >>> having to make major modifications to the Xserver. >>> >>> Comments about this are really appreciated. >>> >>> _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
