Re: States in GailLabel

[Brian Cameron <Brian Cameron sun com>]

Bill:

> Brian Cameron wrote:
> > 
> > Bill:
> > 
> > > On reflection, since our labels implement AtkText, I think this
> > > probably would be useful, since it would be better to know in advance
> > > whether there are multiple lines rather than attempt multiline
> > > navigation and get "fail" type of result.
> > 
> > So are we saying we want to implement this state as synamic for
> > labels?
> 
> As I understand it, it would only be dynamic if/when the label is
> replaced.  We already must listen for such programmatic label changes,
> so I think the GailLabel state should reflect this.

Technically we can make the state change if we want.  We just have ot
decide if we want.  :)

> However if
> resizeable labels do auto-word wrapping of some sort then we might
> reconsider... I didn't think this was a situation that arose in GTK+
> (resizeable labels + wordwrap).

Labels can do wordwrap.  They support the property PROP_WRAP and 
access functions gtk_label_set_line_wrap() and
gtk_label_get_line_wrap().
  
> > > Brian, what is the behavior of the Gail AtkText implementors if one
> > > attempts to navigate past the end of the text buffer?
> > 
> > I'm not sure what you mean by "navigating past the end".  Do you
> > mean by moving the "virtual caret"?
> 
> After a moment's thought I don't think 'navigating past the end' is
> possible via the atk_text_get_text_[at,after,before]_offset functions
> unless an invalid offset is passed.  What is the result if the offset
> is invalid?

I'll have to check with Lucy to be sure, but I believe they return
an empty string back if the offset is invalid.
 
> I notice that the ATK API docs on developer.gnome.org are considerably
> out of date, they do not include the "end_offset" out-parameters for
> atk_text_get_text_*.

I believe there is a current incompatibility with gtk-docs and gtk+.
They turned off rebuilding the docs completely on developer.gnome.org,
even though other projects (like ATK) build okay.  I was told this
by Owen Taylor on June 27th on the gtk-devel mail alias.  In his
email (see attached) he said it would be fixed soon, but I don't
believe it has been fixed.

Brian

--- Begin Message ---

• From: Owen Taylor <otaylor redhat com>
• To: Brian Cameron <Brian Cameron sun com>
• Cc: chookij thestork eng sun com, gtk-i18n-list gnome org, gnome-accessibility-list gnome org
• Subject: Re: atk and Pango
• Date: 27 Jun 2001 11:16:29 -0400

Brian Cameron <Brian Cameron Sun COM> writes:

> Chookij & Owen:
> 
> ATK's dependency on Pango has already been removed in the CVS head.
> Actually if you check the docs at the developer.gnome.org website:
> 
>    http://developer.gnome.org/doc/API/2.0/atk/atk-atktext.html
> 
> The functions "atk_text_ref_run_attributes" already uses an
> AtkAttributeSet structure and no longer uses a PangoAttrList.
> 
> Also the AtkEditableText function "atkeditable_set_run_attributes"
> has been likewise changed in the CVS head.  Although this hasn't
> been reflected on the developer.gnome.org API pages.  How frequently
> do they get updated?  This change was made over a week ago.

The build of the 2.0 platform docs has been broken for a while - it's
a mini-tinderbox and needs some manual care. After Saturday, hopefully
I'll have time to fix it.

Regards,
                                        Owen

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

--- End Message ---