Re: AtkText attributes

[Brian Cameron <Brian Cameron sun com>]

Bill & Others:

> We've had a couple of conversations about removing our current Pango
> dependency from ATK.  Though we think Pango is great and will of
> course depend on it heavily in GAIL, the only pango dependency that I
> know of in ATK is the use of PangoAttributeSet as the means of
> indicating text attributes.

That is correct.
 
> In point of fact, it's not clear that this is the "best" way to expose
> text attributes, certainly it's not the way to expose them to adaptive
> technologies in the general-case SPI.  In that latter case it seems
> almost certain that exposing them as "String" name-value pairs is the
> best and most extensible approach... in most cases the AT will present
> these attributes, if at all, in readable form (if they are strings
> they even can be localized readily).  Since the presentation format
> will ultimately be strings, it makes sense to move towards a string
> N-V pair representation in ATK.  That's of course trivial extensible,
> and we are unlikely to be able to make semantic use of the information
> in the first place.  It also eases implementation for HTML and XML
> markup, etc.
> 
> I asked Brian to look into GTK N-V pair support.  Since we are not
> using semantic info and are storing only strings, existing things like
> ghash might not be the best implementation, we may be better off
> creating a trivial N-V pair structure ourselves.  I expect that since
> the strings will not be consts in the general case, we should inherit
> our N-V pair from GObject so that we can do ref counts and finalizers,
> to free up the string memory , manage NV pair lifecycles, etc.  I
> think this is also important since the attribute-getting API will
> almost certainly return transient attribute sets rather than
> persistent objects (the API now allows you to ask for the set of
> attributes which is the same over a range of text).

I'm not sure it is necessary to build our own name-value structure.
It seems like the "Keyed Data Lists" object might do the trick.  It
has a g_datalist_foreach() function to loop over the data you put in.
You can also get the data out if you know the key value.  If you don't
know the key values, you would have to use the foreach function to get
the values.  This seems like it would be pefect.  Otherwise we
can create our own NameValue object.  
 
> I think that we also probably need a new boundary enumeration type,
> ATTRIBUTES, so that we can easily get a range of text over which the
> attributes are unchanged.
> 
> After a little more discussion, maybe, I'd like to make these changes
> to AtkText, after which I think we can remove the pango dependency.

Brian