I agree with David's sentiment. Kristian, do you have what you need to develop a proposal?
Will On Apr 11, 2008, at 3:06 PM, David Bolter wrote: > Kristian Lyngstøl wrote: >> 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? >> > > My 2 cents: > > I say move forward with composite magnification. Create dbus api for > compiz if that makes the most sense. Let's move forward. > > cheers, > D _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
