Re: [g-a-devel]Extended events

["Padraig O'Briain" <Padraig Obriain sun com>]

Bill,

I have attempted to respond to your questions.

I have removed extraneous detail from the message.

> 
> [wph]
> Maybe off-topic, but are we not emitting any kind of row/column
> reordered events in at-spi yet?
> 

The ATK interface may emit a row-reordered or column-reordered signal. The 
bridge does listent for thoise signals and should emit the corresponding at-psi 
events.


> > +  else if (strcmp (prop_name, "accessible-table-caption-object") == 0)
> > +    {
> > +      ao = atk_table_get_caption (ATK_TABLE (gobject));
> > +      sp = atk_object_get_name (ao);
> 
> [wph]
> Do we leak 'ao' here?

I do not think so. The function atk_table_get-caption() should not add a 
reference.

> > +        }
> > +      else if (signal_query.signal_id == atk_signal_text_selection_changed)
> > +        {
> > +          text = ATK_TEXT (gobject);
> > + 
> > +          if (atk_text_get_n_selections (text) == 1)
> > +            {
> > +              sp = atk_text_get_selection (text, 0, &detail1, &detail2);
> > +              if (abs (detail2 - detail1) < max_selection_string)
> > +                {
> > +                  spi_init_any_string (&any, &sp);
> > +                }
> > +              else
> > +                {
> > +	          spi_init_any_nil (&any);
> [wph] 
> Hmm, I would emit an event with a string max_selection_string chars
> long.  The question then is exposing that length to clients; perhaps we
> need a public SPI_MAX_EVENT_STRING_LEN #define, so clients know that 
> if strlen == MAX, it's likely to be truncated.
> 

I have no clear view of how these events will be used so I am not certain what 
the best approach is.

If you think it is best, we can define SPI_MAX_EVENT_STRING_LEN. Any suggestion 
for an appropriate value? My reason for not supplying any string when a large 
amount of text is selected was to reduce the overhead in that case.



> > +                }
> > +            }
> > +          else
> > +            {
> > +	      spi_init_any_nil (&any);
> 
> [wph] I would have thought the desired behavior was "emit the selection
> 'delta' as a string", but we are ignoring the multi-select case here.
> Is there a way we can detect (at least within the bridge) which
> subselection has changed?  If so, we can emit the change string if the
> change is associated with the 'last' selection (seems to me we'd get
> better coverage that way).  If we can think of a way for clients to know
> which substring has changed then we could do even better of course.
> 
> Also, an awkward question; how does the at client distinguish between
> selection "insert" and selection "delete" ?  Perhaps detail2 < detail1
> in such cases?
> 
> I am not sure we are giving enough information here.  
> 

The ATK text-selection-changed signal does not provide any information about how 
the selection has changed so as things stand I am not sure that we can provide 
the information you require.

One of my reasons for ignoring the multi-select case is that I did not have a 
test case for that.

At present it seems to me that the client would need to cache the current number 
of selections and start and end of each selection to determine whether a 
selection changed was an insertion or a deletion.