Re: GTK+ canvas?

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,


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]