On Thu, Mar 27, 2008 at 8:36 PM, Willie Walker <[EMAIL PROTECTED]> wrote: > Having said all that, we have a task for "GNOME Outreach Program: > Accessibility" for someone to get paid to help take the magnification > solution beyond where we are now. If someone is interested in this, > please let us know!
I'm unsure of what the plans forward for gnome-mag is. It has been my understanding that it is mostly in maintenance mode? Before I go further into this, I'd like to sum up my understanding of the magnification-related technologies involved (only listing magnification-related tasks). Orca: - Collects data on what's going on. Mouse movement. Window focus. Cursor movement, etc. - Controls Gnome-mag (soon to be over DBus?) Gnome-mag: - Just does magnification. - Can be composite manager, but doesn't require it. - Uses XRender - Conflicts with other composite managers (like Compiz). - Has performance issues in may situations. Compiz: - Must be a composite manager. - Provides various plugins for accessibility, including "magnifier" and "ezoom" - Currently requires OpenGL, plans exist for other rendering engines (including XRender). * - NOT the default Gnome window manager - Flexible; adapting plugins or even the core for a11y is easily accomplished. - The hardware (driver) requirements seem to be the major blocker for this to really take off. Metacity: - Default Gnome window manager and also composite manager With regards to Compiz, there is working going on which will make Compiz less hardware dependant and generally better all around, including for a11y. This is a long term effort though. That leaves us with a gnome-mag which, in it's current state, would be by and large useless due to performance issues. I've read Carlo's idea about having the composite manager draw into an off screen window belonging to an other application, but I'm not sure I'm buying it. Might as well just tell the composite manager to magnify to the right place to begin with. However, making textures/window content available between applications is also something that I know there is a lot of interest in. And some work exist (Compatible video players can give Compiz direct access to their textures through the Video plugin). Depending on Compiz entirely is going to be hard to sell. I am also unfamiliar with Metacity code. I still believe that the integration between Orca and eZoom should be finished similar to how it was discussed during the Accessibility Summit, but that still leaves Gnome-mag and metacity. I'm honestly not sure what should be done about gnome-mag. Obviously the compositor in Metacity also complicates things, as metacity does not currently offer any magnification, thus it basically just kills performance for gnome-mag without giving much back. Having gnome-mag interact with Compiz isn't really had, but then I believe we might as well just skip Gnome-mag all together. It's straight forward to make or adjust a Compiz plugin or two to act exactly like Gnome-mag. This introduces some code duplication though, which I see as the major selling point for gnome-mag staying alive. So let's look at what exactly Gnome-mag does, help me fill in the blanks as I have very limited gnome-mag experience. - Allow external control (from orca?) - One area zoomed, an other not zoomed. - Mark the position of the mouse Having gnome-mag control these functions but the compositor actually performing them seems feasable to me. This would allow gnome-mag to retain a lot of it's logic, but the compositor to do the actual work. This way, gnome-mag could also fall back to it's own xrender method without a significant code duplication, and the experience should be consistent across different composited window managers. I'm still not quite convinced this is the way to go though.... It seems too much like we're just striving to keep gnome-mag alive. It would, with a composite manager, basically just filter and relay messages from Orca or other controlling programs. If significant work is to be done on gnome-mag, I believe we need to rethink it's place. And what to do with Metacity. There obviously needs to be SOME sort of interaction between a composite manager and whatever is responsible for triggering or controlling magnification. I'm not sure how much magnification-code would be acceptable in metacity either, or if it's even suited for it at all. So I guess I'm not any closer to answering my own question: What exactly should be done with magnification? - Kristian _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
