Re: [g-a-devel]text Boundary enumerated types in at-spi

[Marc Mulcahy <marc mulcahy Sun COM>]

OK, so I went ahead and made the patch which I posted here based on at-spi 
cvs head, and it appears that the situation is as follows:

The way we get attributes and the corresponding attribute range information 
is consistent through the stack-- in ATK it's done through 
atk_text_get_run_attributes, and in libspi and cspi it's done through 
getAttributes.  getAttributes returns the start and end offset of the 
attribute range as well as the string describing the attributes.

The cursor_pos and text_attribute_range enumerated types, prior to my 
patch, are found only in spi.h, and not in the IDL.  In this case, suppport 
for text_attribute_range would have had to been implemented in the c 
bindings, and it provides no advantages over calling getAttributes, and in 
fact provides less information.

Marc

At 09:39 AM 2/7/2002 +0000, Bill Haneman wrote:
> Marc Mulcahy wrote:
> >
> > So, should we keep boundary_type_attribute_range and implement it all the
> > way through the stack or get rid of it?  A similar capability is not
> > present in atk, so we'd have to do some additional implementation in cspi
> > and libspi if we want to keep it.  I personally favor getting rid of it for
> > consistancy and removing redundancy.
> >
> > Marc
>
> The plan was to keep the existing IDL as-is.  The libspi implementation
> for boundary_type_attribute_range would use the ATK API for
> getAttributeRange which is functionally equivalent.  In turn, the cspi
> API would call libspi with the boundary_type_attribute enumerated type.
>
> I agree that this means that the at-spi IDL semantics for attribute
> ranges is a little different than from that of ATK and cspi.
>
> I don't really have a problem with that, and any departure would
> constitute an API change at this time - we'd have to add an
> attribute-range-specific method to Accessibility_Text.idl.  That change
> is not necessary using the existing IDL and enumerated types in libspi.
>
> So my proposal would be only to remove the attribute_range boundary enum
> from cspi (if we removed it at all), and use the existing libspi API to
> implement the explicit attribute range call in cspi.  I don't think it
> harmful to keep the enum around however even though it means that we
> have some redundant API in cspi.  A second possibility would be to
> remove the attribute range method from cspi and use the boundary range
> enum instead, consistent with libspi.
>
> -Bill
>
> > At 10:14 PM 2/6/2002 +0000, Bill Haneman wrote:
> > >Marc Mulcahy wrote:
> > > >
> > > > Hi All,
> > > >
> > > > There are some redundant enumerated types in the c bindings for the 
> at-spi
> > > > that I think should be removed.  They are cursor_pos and
> > > > attribute_range.  Can I remove them?
> > >
> > >CURSOR_POS certainly seems unnecessary.  ATTRIBUTE_RANGE is indeed
> > >redundant, so I suppose it can safely go as well (though an analogous
> > >value occurs in libspi and the at-spi IDL).
> > >
> > >-Bill
> > >
> > > > Also, I'll be implementing marshallers for the text boundary enumerated
> > > > types since there aren't any currently.
> > > >
> > > > Marc
> > > >
> > > > _______________________________________________
> > > > Gnome-accessibility-devel mailing list
> > > > Gnome-accessibility-devel gnome org
> > > > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> > >_______________________________________________
> > >Gnome-accessibility-devel mailing list
> > >Gnome-accessibility-devel gnome org
> > >http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> >
> > _______________________________________________
> > Gnome-accessibility-devel mailing list
> > Gnome-accessibility-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel