ATK API change suggestion/request (oops)
- From: Bill Haneman <bill haneman sun com>
- To: gtk-devel-list gnome org, gnome-2 0-list gnome org
- Cc: gnome-accessibility-devel gnome org
- Subject: ATK API change suggestion/request (oops)
- Date: Mon, 04 Feb 2002 20:28:13 +0000
In reviewing ATK I see that we have defined a bit of API in a somewhat
daft way. The current API is functional, but inconsistent, and
according to LXR and my own poking about we (Accessibility team, at-spi
in fact) are the only people using the existing API.
The API in question is:
AtkLayer atk_object_get_layer (AtkObject *object);
gint atk_object_get_mdi_zorder (AtkObject *object);
The purpose of this API is to give some indication of whether an
onscreen component is painted on top of, beneath, etc. with respect to
The other API in ATK which concerns itself with screen coordinates and
an object's allocation on screen is AtkComponent, and in fact no UI
component which doesn't appear on screen implements AtkComponent. In
theory (and practice) there are AtkObject which don't occupy screen real
estate, though this is a bit of an edge case. So truthfully the
layer/zorder APIs belong in AtkComponent, and in fact they *are* in the
component interfaces in at-spi; somehow they ended up in AtkObject
however, which appears to have been a goof. We'd like to move this from
AtkObject to AtkComponent where I believe it has always belonged.
If we are ever going to fix this we of course had better do it now. We
could live with the current API but it is clearly inconsistent and makes
it hard to explain our intention when we discuss the AtkComponent
interface with respect to AtkObject... the best we can say to the
reader/user is, "we goofed!".
If/when we fix this it will create a binary incompatibility in
AtkObjectClass. One possibility that would preserve API compat for one
release, just to ease rebuilding pains for GNOME 2 testers, would be to
add atk_component_get_layer (AtkComponent *c) and
atk_component_get_mdi_zorder (AtkComponent *c) and deprecate the
AtkObject equivalents, with the intent of removing the deprecated API in
the next weekly release.
Go/No-go comments solicited...
] [Thread Prev