Re: GOPA: Magnification proposal

["Steve Lee" <steve fullmeasure co uk>]

Thanks Kristian, that gives a very clear picture of the situation and
issues. Good luck
My impression is that this will also act as a good basis for future
advanced and innovative mag features.

-- 
Steve Lee
--
Open Source Assistive Technology Software
web: fullmeasure.co.uk
blog: eduspaces.net/stevelee/weblog


2008/5/4 Kristian Lyngstøl <kristian bohemians org>:
> Reffering to various mail and IRC conversation, and the task page on
>  http://www.gnome.org/projects/outreach/a11y/tasks/magnification/ ,
>  here's my proposal as to how to move forward with magnification.
>
>  I know proposals are supposed to go to soc-mentors-list gnome org
>  according to the rules, but I figure it's a good idea to send it here
>  first.
>
>  Background
>  =======
>  Magnification under GNOME today is limited to the use of gnome-mag,
>  optionally enhanced by Orca. It is made difficult by conflicts with
>  composite window managers which are the new trend.
>
>  In addition to this, gnome-mag and Orca integration relies heavily on
>  ORBIT/Bonobo, which is on it's way out. While it was discussed at
>  GNOME Boston 2007 to keep ORBIT around for accessibility only, it was
>  concluded that this would require the accessibility community to
>  maintain ORBIT, which is not reasonable.
>
>  For these reasons, and the wish to generally improve magnification,
>  the "GNOME Outreach: Magnification" task has come to be.
>
>
>  Summary of Goals
>  ===========
>  1. Investigate exactly which features exist in gnome-mag and how they
>  differ from their equivalents in Compiz Fusion. Investigate what
>  information composite window managers could be interested in getting
>  from Orca that they currently are not requiring.
>  2. Create a D-Bus based communication protocol to accommodate
>  communication between Orca and a Composite Manager.
>  3. Give Orca the ability to directly configure accessibility parts of
>  a composite (window) manager with minimum visual changes to the
>  current UI.
>  4. Mirror the functionality that gnome-mag has into Compiz.
>  5. Create a hilight plugin in Compiz Fusion using the new D-Bus interface.
>
>
>  Details
>  ====
>  1.
>  We want an interface that can stay stable, simple yet powerful. The
>  point of the initial investigation is to break down what exactly the
>  communication protocol needs to accommodate. The goal is to make
>  information available from Orca without taking full control of the
>  composite manager.
>
>  This investigation will also be a requirement for being able to mirror
>  gnome-mag functionality in Compiz Fusion.
>
>  2.
>  Creating a D-Bus interface is the true core of this project. The idea
>  is to avoid locking ourself to a specific application, be it Orca,
>  Compiz or something else. It should be a fairly straight forward
>  process.
>
>  The interface should also allow for discovering what is available. A
>  composite manager might support magnification but not highlighting,
>  and allowing this to be discovered would enable us to gray out the
>  features in a configuration UI (or otherwise indicate that they are
>  not available).
>
>  3.
>  Orca has done a magnificent job uniting the different accessibility
>  features, and is able to control gnome-mag without requiring the user
>  to be aware that they are in fact two separate applications. Ideally,
>  a transition from gnome-mag to Compiz Fusion should not require the
>  user to configure Compiz using a second tool. Compiz Fusion already
>  allows for easy configuration through D-Bus, however, this is
>  application specific. There are a few different ways of solving this;
>
>  - Use the application-specific interface in Orca.
>  - Create a small plugin for Compiz Fusion to relay the necessary
>  configuration request from a generic bus.
>  - Something Else.
>
>  4.
>  Most of the features Gnome-mag has are already present in Compiz
>  Fusion in one way or an other, however, gnome-mag, unlike Compiz
>  Fusion, has had a significant amount of input from visually impaired
>  users to get where it is today. Mimicking the features of gnome-mag in
>  Compiz Fusion should not be tremendous amount of work; it is mostly in
>  the glue, with some exceptions like split-screen magnification and
>  cross hair functions.
>
>  5.
>  As simple as it sounds.
>
>  Concerns, limitations
>  ============
>  A very common concern is the hardware requirement involved when
>  dealing with Compiz. Compiz currently requires composite, but more
>  importantly, OpenGL to work. OpenGL in turn requires moderately recent
>  hardware, which does pose a problem. However, this project would not
>  make gnome-mag unusable, it would simply add features to those who
>  have the recent hardware and prepare for the future.
>
>  It can also be noted that there are plans to make Compiz less
>  dependent on OpenGL, and this can already be seen in the code base as
>  typical OpenGL commands are being switched for Compiz equivalents
>  (glTransform versus matrixTransform, etc), and it is a stated goal of
>  Compiz to someday be able to use different plugins for output. I.e:
>  XRender when OpenGL is unavailable.
>
>  An other concern is that Compiz Fusion is not a GNOME window manager,
>  and it is only one window manager. The goal of this project is mainly
>  to create an implementation that can easily be copied to other
>  composite managers. Metacity in it's current state can not easily
>  accommodate these needed changes, thus Compiz should make for a good
>  alternative, specially as it is gaining ground and maturing.
>
>  I've been asked where I see Compiz in the future, and I honestly don't
>  know. There are very ambitious plans for Compiz at the moment. These
>  plans would make Compiz more flexible with regards to hardware, and
>  hopefully more robust and mature. At any rate, it is an application
>  very much alive.
>
>  Project schedule
>  ==========
>  Most of this work would be done during summer, as I am a student. And
>  this schedule is quite likely to change.
>
>  Some of these tasks overlap naturally, specially tasks where I expect
>  I will need assistance, which is mainly when it comes to Orca.
>
>  June:
>   - Initial definition of what the protocol needs to accommodate based
>  on gnome-mag and community discussion
>   - Write basic highlight plugin, possibly without remote control.
>  (Easily done at the side while waiting for feedback, etc)
>   - Determine more specific plans for Orca integration.
>
>  July:
>   - Write and publish a specification draft for the API / Protocol.
>   - Start working on basic Orca integration.
>   - Determine how to go ahead with split screen zoom in ezoom and
>  cursor cross hair.
>   - Implement cursor cross hair.
>   - Decide on how to allow easy configuration.
>
>  August 1-15:
>   - Working Orca / Compiz integration at a level worthy of demonstration.
>   - Ability to configure Compiz accessibility features through the Orca
>  UI (without cluttering the UI).
>   - Split screen zoom in Compiz Fusion.
>
>  September 15th:
>   - Finish
>
>  Beyond this, it'll obviously be bug fixing, tweaking etc in august and
>  september.
>
>
>  Personal Experience
>  ============
>  I've already written Enhanced Zoom for Compiz (And several other
>  plugins and core code), and I don't expect I'll need any technical
>  assistance on that part of the project. I've also been interested in
>  magnification for about a year now, and already looked at Orca
>  integration on a very superficial level.
>
>  I'm used to working with others code and I like to believe I have a
>  high standard when it comes to quality.
>
>  I'm familiar with all the technologies involved in the project (some
>  more than others), the complexities and so on, partially from working
>  on magnification, partially from participating in discussions
>  regarding accessibility and magnification.
>
>  - Kristian
>  _______________________________________________
>  gnome-accessibility-list mailing list
>  gnome-accessibility-list gnome org
>  http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>