[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: GTK+ canvas?
From:       Bill Haneman <Bill.Haneman () Sun ! COM>
Date:       2006-08-31 10:02:40
Message-ID: 44F6B3C0.5010407 () sun ! com
[Download RAW message or body]

One of the big challenges for a gtk+ canvas has to do with 
accessibility.  If we build a gtkcanvas that is nice to use (and 
therefore gets widely adopted), it also has to expose all the 
appropriate ATK information.  Otherwise, we'll be eroding gtk+ 
accessibility, and creating obstacles to deployment of gtk+ and gnome 
apps.  (There are already statutory accessibility requirements for 
deployment in some environments, notably US education and government, 
and those requirements are expected to become more widespread in the 
future.  They also tend to be of the "all or nothing" variety, so even 
one or two inaccessible applications in a desktop environment can become 
an issue).

>>Thoughts since last "canvas notes"
>>===
>>
>>- I think an important thing to keep in mind is that a canvas is just an 
>>alternate widget system.
>>    
>>
>
>  Yeah, kind of agree.
>
To the extent that this is true, the accessibility requirements are 
fairly clear - widget-like things inside the canvas must follow the ATK 
accessibility principles, exposing fairly rich queryable interfaces.  
Textual content must expose AtkText/AtkEditableText, and onscreen 
objects must expose AtkComponent (bounds, z-order, position, focus).  
Also the objects must somehow have a keyboard navigation model so that 
the canvas can be used without the mouse.

If we anticipate using a canvas for something other than plain vector or 
graphics primitive drawing, then a good deal of thought needs to go in 
to how the canvas' object model hooks in to ATK.  Even in a simple 
graphics primitive canvas, we need an object model so that the parts of 
the resulting drawing can be organized in a hierarchical model and 
queried for bounds and attributes such as color, 
names/labels/descriptions, etc.    The need to make a canvas-based 
application accessible also means that some facility for making the 
content accessible to blind users needs to be available in the main 
canvas API (in the manner of web page "alt text", at minimum) so that 
the application developer can provide the appropriate info when building 
the app.

The danger in canvases is that an attractively "simple" API, with only 
low-level primitives, will in the long run work against application 
consistency and accessibility.  Any canvas needs an object model and I 
think ours needs one that incorporates accessibility from the outset.

For historical reasons the ATK support for GTK+ widgets has been 
provided by the (external) gail library.  This causes some headaches 
because it means everything required by ATK must be available via public 
widget API.  In the case of gtkcanvas I think the ATK support would be 
more effectively written into the gtk+ codebase itself, so that 
private/internal structs and APIs are available, and so that changes to 
implementation details are more easily kept in sync with the ATK 
implementation.

best regards,

Bill




_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]